5.5.3. На пути к адаптивным обучающим системам

Инструментом познания согласно концепции параграфа 5.4 можно считать и процесс проектирования структуры гипертекста. Ранее нами [Гаврилова, 1996-99] был предложен подход, трактующий структуру (граф) гипертекста (ГТ) как «скелет» поля знаний, то есть наиболее информационно-нагруженный элемент поля знаний. Именно этот граф отражает структуру знания, которую можно назвать гиперзнания. Усвоение этой структуры является важнейшим компонентом процесса обучения. Очевидно, чем более будет конкретная структура ГТ соответствовать индивидуальной когнитивной структуре, тем эффективнее будет идти процесс обучения. Фактически это означает, что обучение и тренинг будут организованы не через навязывание конкретных когнитивных структур обучаемому и ломку старых представлений, а через проекцию нового знания на каркас индивидуального опыта и наращивание уже имеющихся когнитивных структур. Такая адаптация к индивидуальным познавательным структурам может существенно повысить эффективность обучающих систем.

Предлагаемый подход позволяет представить поле знаний предметной области в виде релевантной гиперструктуры HS, узлами которой являются концепты А, выделяемые экспертами как «опорные», то есть принципиально значимые. Связи или отношения R используются для переходов между узлами. Такая трактовка является естественным развитием моделей представления знаний типа семантических сетей, которые на современном этапе считаются наиболее адекватными человеческой структуре памяти [Величковский, 1982; Шенк, Хантер, 1987]. Естественно, что такие концептуально-когнитивные структуры отличаются резкой индивидуальностью, связанной с личностными, интеллектуальными и профессиональными различиями носителей знаний. В некотором смысле такая структура является когнитивной моделью индивида.

Предлагаемый подход согласуется с концепцией мультидеревьев [Furna, Zacks, 1994], реализующей множественное представление ПО. Модель пользователя, сформированная по этому принципу, будет отражать «модель мира» данного конкретного пользователя в виде гиперграфа, узлы которого, в свою очередь, могут быть раскрыты в виде гиперструктур более низкого уровня. Фактически это соответствует субъективным концептуальным структурам в памяти. Часто в проблематике АОС используют понятие «сценария». Традиционно под сценарием понимается описание содержательного, логического и временного взаимодействия структурных единиц программы, с помощью которых реализуется авторская цель [Бойкачев, Конева, Новик, 1994].

Очевидно, что в гипермедиа учебных приложениях естественным представлением сценария является граф гипертекста. При этом важно добиваться, чтобы этот сценарий соответствовал (был релевантным) представлениям как учителей, так и учеников.

Релевантная ГТ-структура представляет стратифицированную сеть HS = A,R, отражающую иерархию понятий предметной области в форме, соответствующей профессиональным представлениям экспертов и не вызывающей когнитивного диссонанса у пользователя.

Для формирования стратифицированного множества вершин А можно использовать модификацию алгоритмов объектно-структурного анализа ОСА (параграф 3.4).

Алгоритм «ОСА-гипер»

1. Сформулировать цель и собрать от экспертов всю доступную информацию.

2. Определить количество страт N, подлежащих формированию.

3. Из информации, полученной от экспертов и из литературы, выбрать все значимые основные объекты и понятия {А} и разместить их по стратам, сформировав опорные метаузлы ГТ структуры.

4. Детализировать концепты, пользуясь нисходящей концепцией (top-down).

5. Образовать метапонятия по концепции (bottom-up).

6. Исключить повторы, избыточность и синонимию.

7. Обсудить понятия, не вошедшие в структуру ГТ с экспертом и включить их или исключить.

8. Выявить основные отношения {R} и спроектировать эскиз ГТ структуры.

9. Провести обследование потенциальных пользователей с целью выявления их когнитивных представлений о данной ПО, а также формирования модели пользователя.

10. Привести в соответствие эскиз ГТ и представления пользователя.

11. Сформировать ряд сценариев обхода ГТ с целью упрощения навигации и учета необходимых сценарных связей и включить их в структуру.

Данный алгоритм выявляет канонический или основной сценарий, альтернативные сценарии формируются на основании либо иного опыта преподавания, либо с учетом категории пользователей.

Последовательное применение данного подхода и визуальных методов проектирования позволило сформировать ГРАФИТ-технологию и реализовать ее в ряде программных продуктов ВИКОНТ (ВИзуальный Конструктор Онтологии), ПЕГАС (ПроЕктирование Гипер-Активных Схем) [Гаврилова и др., 1998-2000] (рис. 5.11).

При разработке гипермедиа-приложений необходимо также учитывать фактор сбалансированности звуковых и видеоузлов опорной ГТструктуры, то есть аудио- и видеофрагменты должны равномерно распределяться на сети. Для этого в технологию ГРАФИТ введено понятие «раскраски» узлов, что позволяет наглядно оценить сбалансированность сети по аудио- и видеонагрузке. Алгоритм «ОСА-гипер» учитывает необходимость анализа не только исходной информации, но и навигационных возможностей:

• перемещение на экран назад;

• возврат к началу;

• возврат к началу секции;

• просмотр структуры;

• озвучивание экрана;

• включение видео;

• помощь;

• перемещение на экран вперед.

Рис. 5.11. ГРАФИТ-технология визуального проектирования ГТ

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

Данный подход использован при создании ГТ АОС в области инженерии знаний для систем дистанционного обучения (Gavrilova, Stash, Udaltsov, 1998). Системы обучения в области ИИ имеют пока небольшую историю, хотя при отсутствии учебников по данным дисциплинам эти электронные учебники особенно необходимы. Известны лишь единичные работы в нашей стране и за рубежом — «База знаний для разработчиков ЭС» [Молокова, Уварова, 1992] и KARTT (Knowledge Acquisition Research and Teaching Tool) [Liebovitz, Bland, 1994].

При проектировании любой ГТ структуры нетривиальной задачей является выделение «опорных» концептов — вопрос, практически не освещенный в литературе. В работе [Гаврилова, Червинская, 1993] представлен обзор различных методов извлечения знаний, частично включающих и исследования по выявлению значимых концептов. Можно предложить использовать для этой цели методы многомерного шкалирования, позволяющие выявлять структуру индивидуальных ментальных пространств, анализируя попарные связи понятий предметной области (см. п. 5.1).

Эти методы использовались и ранее для изучения семантических пространств памяти [Терехина, 1988; Петренко, 1988; Cook, 1985], однако можно использовать новый подход, ориентированный на анализ не только осей ментальных пространств с выявлением соответствующих конструктов, но и точек сгущения понятий, называемых «аттракторами» для выявления метапонятий или концептов.

В дальнейшем эти концепты образуют узлы {А} релевантной ГТ структуры, которую можно фактически трактовать как модель пользователя UM (user model):

UM = {A, R}.

Более широкие исследования [Voinov, Gavrilova, 1993; Воинов, Гаврилова, 1994] показали, что психосемантические методики (см. п. 5.1), обогащенные новыми элементами (использование метафорических планов), могут способствовать выявлению имплицитных структур знаний, не поддающихся выявлению другими методами.

Использование UM как гиперструктуры в гипертекстовых АОС позволяет создавать «гибкие» релевантные сценарии, ориентированные на когнитивные особенности определенных групп пользователей. Последнее замечание можно также отнести к разработке систем гипермедиа. Очевидно, что глубокое и конструктивное изучение человеческого фактора в области computer science может существенно раздвинуть ограничения современных интеллектуальных и обучающих систем.

Программный инструментарий

разработки систем, основанных

на знаниях

 Технологии разработки программного обеспечения — цели, принципы, парадигмы

 Методологии создания и модели жизненного цикла интеллектуальных систем

 Языки программирования для ИИ и языки представления знаний

 Инструментальные пакеты для ИИ

 WorkBench-системы

6.1. Технологии разработки программного

обеспечения — цели, принципы, парадигмы

6.1.1. Основные понятия процесса

разработки программного обеспечения (ПО)

К

Под технологией программирования понимается [Брукс, 1979] совокупность знаний о способах и средствах достижения целей в области программного обеспечения ЭВМ, в том числе и таких, которые ранее никем не достигались.

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

Изменения являются постоянным фактором разработки ПО. Для того чтобы преодолеть их разрушающий эффект, в качестве целей технологии разработки ПО принимаются следующие четыре свойства программных систем [Ross et al., 1975]:

1. Модифицируемость. Необходимость модификации ПО обычно возникает по двум причинам: чтобы отразить в системе изменение требований или чтобы исправить ошибки, внесенные ранее в процессе разработки.

2. Эффективность системы подразумевает, что при функционировании оптимальным образом используются имеющиеся в ее распоряжении ресурсы: время и память.

3. Надежность системы ПО означает, что она должна предотвращать концептуальные ошибки, ошибки в проектировании и реализации, а также ошибки, возникающие при функционировании системы.

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

Цели технологии разработки ПО, рассмотренные выше, не могут лишь пассивно признаваться. Наоборот, по мере выполнения работ необходимо придерживаться определенного набора принципов, которые обеспечивают достижение этих целей. В качестве таких принципов обычно выделяют [Ross et al., 1975; Буч, 1992] абстракцию, сокрытие информации, модульность, локализацию, единообразие, полноту и подтверждаемостъ.

Абстракция является одним из основных средств для управления сложными системами ПО. Суть абстракции состоит в выделении существенных свойств с игнорированием несущественных деталей. По мере декомпозиции решения на отдельные компоненты каждая из них становится частью абстракции на соответствующем уровне. Абстрагирование применяется и к данным, и к алгоритмам. На любом уровне абстракции могут фиксироваться абстрактные типы данных, каждый из которых характеризуется множеством значений и множеством операций, применимых к любому объекту данного типа.

Сокрытие или упрятывание информации имеет целью сделать недоступными детали, которые могут повлиять на остальные, более существенные части системы. Упрятывание информации обычно скрывает реализацию объекта или операции и, таким образом, позволяет фиксировать внимание на более высоком уровне абстракции. Кроме того, сокрытие проектных решений нижнего уровня оберегает стратегию принятия решений верхнего уровня от влияния деталей.

Абстракция и сокрытие информации способствуют модифицируемости и пони-маемости систем ПО. На каждом уровне абстракции допускается применение лишь определенного набора операций и делается невозможным применение любых операций, нарушающих логическую концепцию данного уровня, за счет чего повышается надежность программной системы.

Модульность является следующим фундаментальным свойством, помогающим управлять сложностью систем ПО. Она реализуется целенаправленным конструированием. В самом общем плане модули могут быть функциональными (процедурно-ориентированными) или декларативными (объектно-ориентированными). Связность модулей определяется как мера их взаимной зависимости. В идеале должны разрабатываться слабо связанные модули. Другой мерой, применимой к модульности, является прочность, которая определяет, насколько сильно связаны элементы внутри модуля.

Локализация помогает создавать слабо связанные и весьма прочные модули. По отношению к целям технологии разработки ПО принципы модульности и локализации прямо способствуют достижению модифицируемости, надежности и понимаемости.

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

Принципы технологии разработки ПО не должны применяться случайно — необходимо выполнять структуризацию системы определенным образом и, что самое важное, поскольку происходит деление системы на модули, применять согласованные критерии декомпозиции. Можно выделить три основных подхода к разработке ПО, обеспечивающие такие критерии: нисходящее структурное проектирование [Йордан, 1979]; проектирование, структурированное по данным [Jackson, 1975], и объектно-ориентированное проектирование [Booch, 1986].

Нисходящее структурное проектирование определяет декомпозицию системы путем оформления каждого шага этого процесса в виде модуля. Это приводит к созданию функциональных программных модулей.

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

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

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

Такой подход получил название объектно-ориентированного [Booch, 1986]. Здесь учитывается важность трактовки объектов ПО как активных элементов, причем каждый объект наделен своим собственным набором допустимых операций. Легко убедиться, что объектно-ориентированная парадигма поддерживает основные принципы технологии разработки ПО.

6

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

В литературе существует множество нареканий на несовершенство данного разбиения [Липаев и др., 1983], но смысл его в целом достаточно ясен — борьба со сложностью процесса разработки программных продуктов за счет структуризации этапов и локализации на каждом из них только тех задач, которые могут и должны решаться именно здесь. Если перечисленные выше этапы укрупнить, останутся стадии проектирования, реализации и сопровождения.

Проектирование предполагает составление формальных и/или формализованных спецификаций.

Реализация — преобразование этих спецификаций в программный код (автоматическое и/или автоматизированное).

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

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

Существуют различные подходы к разработке таких моделей [Миллс, 1970]. Однако с точки зрения целей настоящей книги нас будут интересовать, в первую очередь, те из них, которые имеют непосредственное продолжение в инструментальных средствах и интегрированных инструментальных средах. Поэтому ниже основное внимание будет уделено моделям программ, которые используются в так называемых WorkBench-системах (наиболее близким по семантике к этому термину является словосочетание «станок для производства ПО»).

Одну из таких моделей предлагает W/0 (Warnier/Orr) методология [Orr et al., 1977]. Она объединяет методологию Warnier по использованию логических

структур данных и логических конструкции программ и систем и методологию DSSD (Data Structured System Development) Oppa, базисом которой является аксиома о логическом соответствии между эвристической структурой программ и данных, обрабатываемых этими программами. На практике такая методология предполагает, что в распоряжении проектировщика системы имеется представительный набор процедурных шаблонов для достаточно широкого класса программируемых задач.

В настоящее время DSSD-методология «переросла» из методологии разработки программ в методологию разработки систем. При этом выделены явно уровень программирования (programming level) и системный уровень (system level). Применяются в DSSD два концептуальных представления — диаграммы входов (Entity diagrams), обеспечивающие определение системного контекста, и модифицированные W/O-диаграммы (Assembly-line Diagrams), специфицирующие функциональное развитие системы [McClure, 1979].

Следующим подходом к созданию моделей программ (по идее достаточно близким к W/O-методологии) является логическое моделирование Гэйиа [Cane et al., 1979]. Сам метод ориентирован на создание систем обработки данных. Логическая модель системы проектируется в процессе последовательного применения следующих семи этапов: описание природы предметной области с помощью диаграмм потоков данных (Data Flow Diagram); выделение первичной модели данных (списка элементов данных в каждом информационном узле); проверка того, что DFD действительно отражает структуру данных, хранимых в системе; сведение полученной на предыдущем этапе информации в двумерные таблицы, которые в дальнейшем нормализуются; коррекция DFD с учетом результатов нормализации предыдущего этапа; разбиение полученной в результате выполнения предыдущих этапов модели на «процедурные единицы» (procedure units), а также определение деталей каждой процедурной единицы. После выполнения этих этапов принимается решение о необходимости прототипирования системы на целевом языке.

И наконец, третьим в ряду подходов к созданию модели проектируемой программы является метод Йордана (Yourdon) [Yourdon et al., 1979; Yourdon, 1989]. Он включает два компонента: инструментальные средства и методики. Ориентирована методология Йордана на проектирование систем обработки данных. Под инструментальными средствами здесь понимаются различные диаграммы, используемые при описании моделей требований и моделей архитектуры проектируемой информационной системы. Самые известные из таких диаграмм — диаграммы потоков данных DFD. Однако их недостатком является отсутствие средств описания отношений между данными и их «поведения» во времени. Вот почему в инструментальные средства метода Йордана на сегодняшний день кроме DFD включены ERD-диаграммы (Entity Relationship Diagrams) и STD-диа-граммы (State Transition Diagrams).

Методики в методе Йордана помогают перейти от бланка на бумаге и/или экранной формы к хорошо организованной системной модели. Первоначально эти методики базировались на традиционном top-down проектировании. В настоящее время здесь используется метод событийного разбиения (event partitioning). При этом сначала создается контекстная диаграмма верхнего уровня (top level context diagram), где определяются системные ограничения и интерфейсы с внешним «миром». Затем с помощью техники интервью формируется список событий из внешней среды, на которые система должна реагировать. Такой подход обеспечивает простой базис для формирования «сырой» DFD. Несколько DFD-реакций могут быть объединены в реакцию более высокого уровня. Критерием такого объединения является наличие узлов, связанных общими данными. По существу, событийное разбиение не что иное, как метод объектно-ориентированного проектирования.

Проблемы, возникающие при использовании метода ERD-диаграмм, связаны, прежде всего, с трудностями интеграции компонентов при разработке всей системы. Вот почему в последнее время этот метод был обобщен за счет введения интегрированной базы данных. При этом ERD-метод трансформируется в структурную методологию, основные этапы которой сводятся к разработке ERD (здесь выделяются как собственно сущности с их типами, так и связи, тоже с их типами); определению кардинальности (cardianality) — однозначности-многозначности типов связей; преобразованию ERD по определенным правилам в соответствующий файл и структуру БД. В процессе такого преобразования каждый тип сущности трансформируется в отношение, а тип связи —- в особое (stand alone) отношение или объединяется с другими отношениями в зависимости от кардинальности типа связи. Разработка прикладных программ на основе сформированного файла и структуры базы данных является заключительным этапом в этом подходе.

Последним методом, который кратко рассматривается в данном подразделе, является метод структурного проектирования (Structured Design) [Yourdon et al., 1979]. Структурное проектирование сделалось действительно мощным и активно используемым на практике подходом за счет того, что к моделям и методам были добавлены оценки результатов проектирования. Здесь предлагаются все проектные решения располагать в 3-мерном пространстве (содержание — сложность — связность). И утверждается, что хорошими проектными решениями будут лишь те, которые при заданном содержании имеют минимальную сложность и максимальную связность. По существу, этот критерий отражает уже обсуждавшиеся выше понятия абстрагируемости, модульности, сокрытия информации, связности и т. п. Конкретным примером воплощения структурного подхода является «водопадная» или «каскадная» (waterfall) модель разработки систем ПО [Balzer etal, 1983].

Технология программирования уже прошла достаточно долгий путь развития, и сейчас происходит переоценка ее фундаментальных исходных посылок. Первым кандидатом для такой переоценки стала традиционная точка зрения на процесс разработки ПО, как на процесс, основанный на понятии жизненного цикла. Растущее единодушие специалистов состоит в том, что данная точка зрения должна быть заменена такой, которая в большей степени соответствовала бы разработкам, поддерживаемым автоматизированными средами.

В качестве примера смены парадигм можно отметить спиральную модель процесса разработки МО (рис. 6.1), предложенную Боэмом [Boehm, 1986], суть которой состоит в том, что отдельные фазы процесса «прокручиваются» на постепенно повышающихся уровнях иерархии.

Рис. 6.1. Спиральная модель Боэма

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

В Европе это направление ассоциируется, прежде всего, с проектированием ПО на основе объектно-ориентированных методологий, среди которых наиболее популярными являются технология MERISE и методология Шлайера—Мэллора (Shlaer-Mellor) [Andre et al, 1994; Shlaer et al., 1992].

В рамках данного подхода проектирование рассматривается как процесс, протекающий в пространстве трех измерений: «статика»—«динамика»—«алгоритмы» (рис. 6.2).

Рис. 6.2. Проектирование в методологии Shlaer-Mellor

Жизненный цикл при этом похож на виток в спирали Боэма, но включает другие стадии. Первая из них связана с осью «Статика» и предполагает идентификацию и описание объектов, атрибутов и отношений, которые требуются для спецификации проектируемой системы. Вторая стадия служит для описания поведения каждого объекта в ответ на внешние запросы и дает в качестве результата совокупность жизненных циклов всех введенных объектов. Затем проектируются алгоритмы реализации действий, специфицированных на предыдущей стадии, и, наконец, на четвертой стадии осуществляется валидация спроектированной системы на полноту и функциональное соответствие исходной задаче. Последняя стадия может потребовать нового витка в модели жизненного цикла.

Таким образом, мы рассмотрели основные модели процессов разработки систем «традицониого» программного обеспечения и теперь переходим к анализу соответствующего инструментария.