5.1 Классификация инструментальных средств.

Инструментальные средства подразделяются на следующие категории:

• Языки программирования

• Языки инженерии знаний

• Средства автоматизации разработки экспертных систем

• Оболочки экспертных систем

5.2 Языки программирования.[18]

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

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

• Оболочки экспертных систем (expert system shells). Системы этого типа создаются, как правило, на основе какой-нибудь экспертной системы, достаточно хорошо зарекомендовавшей себя на практике. При создании оболочки из системы-прототипа удаляются компоненты, слишком специфичные для области ее непосредственного применения, и оставляются те, которые не имеют узкой специализации. Примером может служить система EMYCIN, созданная на основе про-шедшей длительную "обкатку" системы MYCIN. В EMYCIN сохранен интерпрета-тор и все базовые структуры данных — таблицы знаний и связанный с ними меха-низм индексации. Оболочка дополнена специальным языком, улучшающим читабельность программ, и средствами поддержки библиотеки типовых случаев и заключений, выполненных по ним экспертной системой. Дальнейшим развитием оболочки EMYCIN явились системы S.1 и М.4, в которых механизм построения цепочки обратных рассуждений, заимствованный в EMYCIN, объединен с фреймоподобной структурой данных и дополнительными средствами управления ходом рассуждений.

• Языки программирования высокого уровня. Инструментальные средства этой категории избавляют разработчика от необходимости углубляться в детали реализации системы — способы эффективного распределения памяти, низкоуровневые процедуры доступа и манипулирования данными. Одним из наиболее известных представителей таких языков является OPS5. Этот язык прост в изучении и предоставляет программисту гораздо более широкие возможности, чем типичные специализированные оболочки. Следует отметить, что большинство подобных языков так и не было доведено до уровня коммерческого продукта и представляет собой скорее инструмент для исследователей.

• Среда программирования, поддерживающая несколько парадигм (multiple-paradigm programming environment). Средства этой категории включают несколько программных модулей, что позволяет пользователю комбинировать в процессе разработки экспертной системы разные стили программирования. Среди первых проектов такого рода была исследовательская программа LOOP, которая допускала использование двух типов представления знаний: базирующегося на системе правил и объектно-ориентированного. На основе этой архитектуры во второй половине 1980-х годов было разработано несколько коммерческих программных продуктов, из которых наибольшую известность получили KEE, KnowledgeCraft и ART. Эти программы предоставляют в распоряжение квалифицированного пользователя множество опций и для последующих разработок, таких как КАРРА и CLIPS, и стали своего рода стандартом. Однако освоить эти языки программистам далеко не так просто, как языки, отнесенные нами к предыдущей категории

• Дополнительные модули. Средства этой категории представляют собой автономные программные модули, предназначенные для выполнения специфических задач в рамках выбранной архитектуры системы решения проблем. Хорошим примером здесь может служить модуль работы с семантической сетью, использованный в системе VT. Этот модуль позволяет отслеживать связи между значениями ранее установленных и новых параметров проектирования в процессе работы над проектом. Подобные модули управления семантической сетью можно использовать для распространения внесенных изменений на все компоненты системы.

   Объектно-ориентированные языки

     Формат правил хорошо согласуется с представлением знаний в форме "при выполнении условий Сь ..., С„ выполнить действие А", но менее подходит для описания сложных объектов и отношений между ними. Языки объектно-ориентированного программирования предоставляют в распоряжение программиста альтернативную программную среду для организации знаний в терминах декларативного представления объектов предметной области. Все, связанное с процедурной стороной решения проблем, распределяется между этими объектами, которые в таком случае располагают собственными процедурами и могут общаться друг с другом посредством протоколов передачи сообщений.      Другим приятным аспектом объектно-ориентированного программирования является возможность использования таких стилей представления знаний, которые не встречаются в исчислении предикатов и в порождающих правилах. Вместо "размывания" знаний об объекте предметной области между множеством правил или аксиом, на которые они ссылаются, эти знания концентрируются в едином месте — в программном описании объекта. Эта концентрация является виртуальной в том смысле, что нет необходимости, чтобы вся информация об объекте предметной области хранилась в соответствующем ему программном объекте, но любая команда или запрос к этому объекту может быть реализована только через посылку сообщения этому объекту      В реальном мире вещей существует множество систем, в которых обмен информацией может быть представлен через обмен сообщениями между их компьютерными представлениями, и такая связь с технологией моделирования является очень важным достоинством данного подхода. Не вызывает сомнений, что моделирование является одним из мощнейших средств решения проблем и что, рассматривая процесс логических рассуждений в контексте сложной системы, его иногда понять значительно легче, чем в контексте применения правил. Объектно-ориентированное программирование интегрирует символические вычисления в операционную среду, базирующуюся на средствах графического интерфейса, — меню, пиктограммы и т.п. Хотя само по себе оснащение экспертной системы этими средствами и не решает проблему ее прозрачности для пользователя, в руках умелого программиста они позволяют лучше представить пользователю процессы, происходящие в системе.      Основная сложность в использовании средств объектно-ориентированного программирования — уяснить для себя, что именно должен представлять программный объект по отношению к предметной области. В ранних версиях объектно-ориентированных языков, которые были предназначены в основном для разработки программ моделирования, такая проблема не возникала — программные объекты представляли объекты моделируемой системы. Например, при моделировании производственной линии отдельные программные объекты представляли те или иные механизмы этой линии, а сообщения между программными объектами — информационные, энергетические и материальные потоки. Задача программиста серьезно облегчалась тем, что существовало достаточно очевидное соответствие между программными и реальными объектами.      Но для того чтобы внедрить объектно-ориентированный стиль в проектирование экспертных систем, нужно задуматься над тем, как соотнести программные объекты с абстрактными понятиями и категориями предметной области. Объекты должны представлять факты и цели, наборы правил или отдельные гипотезы. Поэтому далеко не очевидно, какими сообщениями должны обмениваться такие объекты и какой смысл должен вкладываться в эти сообщения.      Многое зависит от того, на каком уровне абстракции будет использоваться объектно-ориентированный механизм. Если объекты представляют собой низкоуровневую реализацию определенной схемы формирования суждений, то отпадает необходимость в использовании каких бы то ни было эпистемологических последовательностей. Если же объекты будут видимы и для эксперта в процессе разработки и совершенствования системы, и для пользователя во время эксплуатации системы, то схема отображения понятий и категорий на программные объекты должна быть тщательно продумана.      Пример:

• Smalltalk[19] — объектно-ориентированный язык программирования с динамической типизацией, разработанный в Xerox PARC Аланом Кэйем, Дэном Ингаллсом, Тедом Кэглером, Адель Голдберг, и другими в 1970-х годах. Язык был представлен как Smalltalk-80 и с тех пор широко используется. Smalltalk продолжает активно развиваться и собирает вокруг себя преданное сообщество пользователей.       Smalltalk оказал большое влияние на развитие многих других языков, таких как: Objective-C, Actor, Java и Ruby. Многие идеи 1980-х и 1990-х по написанию программ появились в сообществе Smalltalk. К ним можно отнести рефакторинг, шаблоны проектирования (применительно к ПО), карты Класс-Обязанности-Взаимодействие и экстремальное программирование в целом. Основатель концепции WikiWiki, Вард Каннингем, также входит в сообщество Smalltalk.       Основные идеи Smalltalk’а Основными идеями Smalltalk’а являются:

  • «Всё — объекты». Строки, целые числа, логические значения, определения классов, блоки кода, стеки, память — всё представляется в виде объектов. Выполнение программы состоит из посылок сообщений между объектами. Любое сообщение может быть послано любому объекту; объект-получатель определяет, является ли это сообщение правильным, и что надо сделать, чтобы его обработать.

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

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

  • Model-view-controller (MVC) шаблон структуры пользовательского интерфейса. (В последнее время используют и другие концепции реализации пользовательского интерфейса — например, Morphic в Squeak и Pollock в VisualWorks).

  • Dynamic translation: современные коммерческие виртуальные машины компилируют байткоды в машинные коды для быстрого выполнения.

Smalltalk также использует другие современные идеи:

• Сборка мусора встроена в язык и незаметна разработчику

• Программы Smalltalk’а обычно компилируются в байткоды и выполняются виртуальной машиной (ВМ), что позволяет выполнять их на любом оборудовании, для которого существует ВМ.

    Одной из неожиданных особенностей Smalltalk’а является то, что традиционные конструкции: if-then-else, for, while, и т. д. не являются частью языка. Все они реализованы с помощью объектов. Например, решение принимается с помощью посылки сообщения ifTrue: логическому объекту, и передаёт управление фрагменту кода если логическое значение истинно. Есть всего три конструкции:

• посылка сообщения объекту;

• присваивание объекта переменной;

• возвращение объекта из метода;

и несколько синтаксических конструкций для определения литеральных объектов и временных переменных.      Чтобы лучше понять, как работает механизм обмена сообщениями, можно представить каждый объект как веб-сервер, отвечающий на запросы. При этом, на запросы можно просто выдавать заранее предопределённый ответ, аналог этому — выдача веб-страницы, расположенной по определённому пути; можно перенаправить запрос-сообщение другому объекту, аналог — прокси-сервер; изменить запрос по определённым правилам, аналог — техника url rewriting. Если для реакции на сообщение нет предопределённого метода, то вызывается метод #doesNotUnderstand:, так же, как веб-сервер открывает страницу с сообщением об ошибке, если задан несуществующий путь к веб-странице.      Следующий пример показывающий нахождение гласных в строке иллюстрирует стиль Smalltalk’а. Символ ( | определяет переменные, : определяет параметры, а символы [ и ] можно, для начала, воспринимать, как аналог фигурных скобок { и } в С-подобных языках:  | aString vowels |  aString := 'This is a string'.  vowels := aString select: [:aCharacter | aCharacter isVowel].      В последней строке посылается сообщение select: с аргументом в виде блока кода. Дальше идёт код в суперклассе Collection который выполняет работу:  | newCollection |  newCollection := self species new.  self do: [:each |  (aBlock value: each)  ifTrue: [newCollection add: each]].  ^newCollection      Он отвечает на сообщение путём перебора своих элементов (это метод do:) выполняя код aBlock для каждой буквы; когда выполняется aBlock (aCharacter isVowel) он создаёт логическое значение, которому затем посылается ifTrue:. Если это значение true, буква добавляется в возвращаемую строку. Из за того что select определён в абстрактном классе Collection, мы также можем использовать его так:  | rectangles aPoint|  rectangles := OrderedCollection  with: (Rectangle left: 0 right: 10 top: 100 bottom: 200)  with: (Rectangle left: 10 right: 10 top: 110 bottom: 210).  aPoint := Point x: 20 y: 20.  collisions := rectangles select: [:aRect | aRect containsPoint: aPoint].      История      Smalltalk был создан группой исследователей возглавляемой Аланом Кэйем в исследовательском центре Xerox PARC. Первая реализация, известная как Smalltalk-71, была создана за несколько месяцев как результат спора о том, что язык программирования, основанный на идее посылки сообщений, подсказанной Симулой, должен реализовываться на «странице кода». Более поздняя версия, действительно использованная для исследовательской работы, известна сейчас как Smalltalk-72. Его синтаксис и модель исполнения сильно отличались от современного Smalltalk’а, настолько, что его надо рассматривать как другой язык. После существенных переработок которые зафиксировали несколько сторон семантики выполнения для увеличения эффективности, была создана версия известная как Smalltalk-76. В этой версии добавились наследование, синтаксис более близкий к Smalltalk-80, и среда разработки включающую большинство инструментов знакомых сейчас Smalltalk-ерам. В Smalltalk-80 были добавлены метаклассы, что делало фразу «всё объекты» истинной путём связывания с индивидуальными классами свойств и поведения (например, поддержки различных способов создания экземпляров). Smalltalk-80 был первой версией доступной за пределами PARC, сначала как Smalltalk-80 Version 1, розданной небольшому количеству компаний и университетов для «экспертной оценки». Позже (в 1983) общедоступная реализация, известная как Smalltalk-80 Version 2, стала доступна как образ (независимый от платформы файл содержащий объекты) и спецификации виртуальной машины. Сейчас существует две реализации Smalltalk, являющихся прямыми потомками Smalltalk-80. Это Squeak и VisualWorks. Как выглядел Smalltalk-80 можно увидеть на скриншоте. Образ Smalltalk-80 version 2 запущен на Hobbes, виртуальной машине ST-80 реализованной на VisualWorks.