Теоретические предпосылки

Стадия концептуального анализа или структурирования знаний традицион­но является (наряду со стадией извлечения) "узким местом" в жизнен­ном цикле разработки интеллектуальных систем [Adeli, 1994J. Методология структурирования близка к современной теории больших систем [Гиг, 1981] или сложных систем [Courtois, 1985], где традиционно акцент делается на процессе проектирования [Bertalanffy, 1950; Boulding, 1956]. Большой вклад в эту теорию внесли классики объектно-ориентированного анализа [Буч, 1992].

Разработку интеллектуальных систем с уверенностью можно отнести к дан­ному классу задач, поскольку они обладают основными признаками слож­ности (иерархия понятий, внутриэлементные и межэлементные связи и пр.). Аналогичные концепции, но связанные не с общесистемными исследова­ниями, а рассматривающие информационные процессы в системах, таких как связь и управление, положили начало кибернетике как самостоятельной науке [Винер, 1958; Эшби, 1959]. Позднее, в 1960-х гг. были получены но­вые результаты по развитию математической теории систем высокого уров­ня общности [Месарович, Такахара, 1978]. Существенный вклад в теорию систем и основы структурирования внесли отечественные исследователи [Моисеев, 1981; Глушков, 1964; Ивахненко, 1971; Поспелов, 1986] и др.

Системный анализ тесно переплетается с теорией систем и включает сово­купность методов, ориентированных на исследование и моделирование сложных систем — технических, экономических, экологических и т. п.

Проектирование сложных систем и методы структурирования информации традиционно использовали иерархический подход [Месарович, Такахара, 1978] как методологический прием расчленения формально описанной сис­темы на уровни (или блоки, или модули). На высших уровнях иерархии ис­пользуются наименее детализованные представления, отражающие только самые общие черты и особенности проектируемой системы. На следующих уровнях степень подробности возрастает, при этом система рассматривается не в целом, а отдельными блоками.

На каждом уровне вводятся свои представления о системе и элементах. Элемент k- гоуровня является системой для (k — 1) уровня. Продвижение от уровня к уровню имеет строгую направленность, определяемую стратегией проектирования — дедуктивную нисходящую "сверху вниз" (top-down) или индуктивную восходящую "снизу вверх" (bottom-up).

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

Рис. 2.21 иллюстрирует дуальную концепцию при проектировании Sf для ЭС помощи оператору энергетического блока

Рис. 2.21. Дуальная стратегия проектирования

Нисходящая концепция (top-down) декларирует движение от п => п + 1, где n — п-й уровень иерархии понятий ПО (предметной области) с последующей детализацией понятий, принадлежащих соответствующим уровням.

STR td: P_iⁿ, …, P_iⁿ⁺¹ => P_kiⁿ⁺¹

 

где:

Ø п — номер уровня порождающего концепта;

Ø i — номер порождающего концепта;

Ø k_i — число порождающих концептов, сумма всех k_i по i составляет общее число концептов на уровне п + 1.

Восходящая концепция (bottom-up) предписывает движение п => п — 1 с последовательным обобщением понятий.

STR _bu: P_iⁿ, …, P_kiⁿ⁺¹ => P_i^n-1

где:

Ø п — номер уровня порождающих концептов;

Ø i — номер порождаемого концепта;

Ø k_i — число порождающих концептов, сумма всех k_i по i составляет общее число концептов на уровне п.

Основанием для прекращения агрегирования и дезагрегирования является полное использование словаря терминов, которым пользуется эксперт, при этом число уровней является значимым фактором успешности структурирования.

В целом существующие подходы к проектированию сложных систем можно разделить на два больших класса:

Ø структурный (системный) подход или анализ, основанный на идее алго­ритмической декомпозиции, где каждый модуль системы выполняет один из важнейших этапов общего процесса;

Ø объектный подход, связанный с декомпозицией и выделением не процессов, а объектов, при этом каждый объект рассматривается как экземпляр определенного класса.

В структурном анализе [Yourdon, 1989] разработано большое число выразительных средств для проектирования, в том числе графических [Буч, 1991]:

Ø диаграммы потоков данных (DFD, data-flow diagrams), структурирован­ные словари (тезаурусы), языки спецификации систем, таблицы решений;

Ø стрелочные диаграммы "объект-связь" (ERD, entity-relationship diagrams), диаграммы переходов (состояний);

Ø деревья целей;

Ø блок-схемы алгоритмов (в нотации Насси— Шнейдермана, Фестля и др.);

Ø средства управления проектом (PERT-диаграммы, диаграммы Ганта и др.).

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

Объектный (объектно-ориентированный) подход (ООП) был разработан в 1979 году [Jones, 1979], а затем развит в работах [Peters, 1981; Shaw, 1984; Буч, 1993].

ООП, возникший как технология программирования больших программных продуктов, базируется на основных элементарных понятиях [Буч, 1993]:

Ø объекты и классы как объекты, связанные общностью структуры и свойств;

Ø классификации как средства упорядочения знаний;

Ø иерархии с наследованием свойств;

Ø инкапсуляции как средства ограничения доступа;

Ø методы и полиморфизм для определения функций и отношений.

ООП имеет систему условных обозначений и предлагает набор моделей для проектирования сложных систем. Широкое распространение объектно-ориентированных языков программирования C++, CLOS, Smalltalk и др. успешно демонстрируют жизнеспособность и перспективность этого подхода. В последнее время этот подход успешно применяется и в CASE-средствах не только для проектирования программ, но и для моделирования бизнес-процессов. Особенную популярность приобретает язык UML (Unified Modelling Language) [Буч, Рамбо, Джекобсон, 2000], и программный инстру­ментарий на нем основанный, например Rational Rosex [Боггс, 2001].