Разработка структуры и алгоритмов взаимодействия программных блоков интеллектуальной системы для оценки сложных объектов

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

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

ВЫВОДЫ

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

Рис. 1. Иерархия моделей представления знаний

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

В соответствии с предложенной классификацией можно сказать, что, несмотря на различия, описанные модели не противоречат друг другу. Предложения логики предикатов, например, имеют много общего с продукционными правилами. По существу, интерпретируя правила продукции как предложение логики предикатов, можно без каких-либо затруднений заменить его на предикаты. При таких действиях выражение ОТЕЦ (ИВАН, ВАСИЛИЙ), которое описано предикатной формулой, соответствует отношению ИВАН - ОТЕЦ - ВАСИЛИЙ в семантической сети. В общем случае каждую дугу семантической сети можно задать предикатами как отношения между сущностями, которые описывают узлы на концах дуги.

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

Однако при этом каждая из известных моделей представления знаний обладает, как минимум тремя недостатками из списка, приведенного ниже:

- недостаточный универсализм;

- сложность получения новых знаний;

- возможность получения противоречивых знаний;

- сложность наращивания модели;

- значительная размерность модели;

- отсутствие наглядности в представлении знаний.

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

2. АРХИТЕКТУРА ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМ (ИС) ДЛЯ ОЦЕНКИ СЛОЖНЫХ ОБЪЕКТОВ

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

2.1 Постановка задачи оценки сложных объектов. Описание представления знаний.

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

В рамках реализуемой модели оцениваемые объекты представляются в виде множества S - свойств объектов. Заметим важную деталь - множество S является объединением непересекающихся множеств N и E - соответственно множеств численных и перечислимых свойств. Каждое перечислимое свойство Ei может принимать значение из определенного конечного множества значений. Каждое численное свойство Ni может принимать значения лежащие о области действительных чисел, ограниченной минимальным и максимальным пределами Nimin Nimax соответственно. Введением такого деления мы фактически даем возможность системе учесть как количественные (численные), так и качественные (перечислимые) характеристики объекта.

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

В рамках конкретной оценочной задачи к оцениваемым объектам предъявляются требования из множества T, а также устанавливаются соответствия F между свойствами и требованиями. При этом одно требование может ссылаться на несколько свойств. Например, в задаче оценки объекта недвижимости (например квартиры), требование “удобная квартира” ссылается на свойства “район”, “этаж”, “наличие телефона”, поскольку эти свойства и определяют удобство квартиры. Вообще, смысл введения требований, как инструмента, используемого для адекватной оценки объекта следующий: требования выражают цель субъекта оценки при решении конкретной оценочной задачи; свойства же, являясь описанием, представлением объекта оценки, вообще говоря существую достаточно независимо от решаемой задачи. Конкретную окраску свойства получают лишь с точки зрения системы требований, предъявленной субъектом оценки.

Кроме того в задаче классификации формируется множество C - множество классов. В задаче квалиметрии каждому требованию из множества T ставится в соответствие вес (значимость) этого требования. В задаче классификации каждому требованию ставятся в соответствие n весов, где n - количество классов. В этом случае Pij - это вес (значимость) i-го требования из множества T в j-ом классе из множества C. А все множество P - называется множеством весов (весовых коэффициентов). Кроме этого в задаче квалиметрии для каждого элемента из множества F - соответствий требования и зависимых от него свойств задается т.н. дуговой весовой коэффициент, значение которого определяет значимость конкретного свойства в рамках конкретного требования. Например, при оценке компьютеров требованию “быстродействие” соответствуют свойства - “тип процессора”, “тактовая частота”, “тип системной шины”. При этом тип процессора, например, вносит в быстродействие компьютера больший вклад, чем тип системной шины. Соответственно дуговой коэффициент свойства “тип процессора” в рамках требования “быстродействие” будет больше, чем коэффициент свойства “тип системной шины” в рамках того же требования, ввиду того, что тип процессора вносит больший вклад в быстродействие системы, чем тип системной шины. При решении задачи классификации в соответствие каждому элементу множества F ставятся в соответствие n коэффициентов, где n - количество классов, определяющих значимость свойства в пределах данного требования для данного класса из множества C. Полученное таким образом множество D - называется множеством дуговых весовых коэффициентов.

После формулировки множества требований можно говорить о формировании следующего множества E - множества эталонов. Эталон как идеал может в действительности не существовать, но для принятия решения он должен быть задан. Причем, в рамках описываемой модели эталон - это вовсе не эталон в общепринятом смысле этого слова. Эталон с точки зрения модели не только несет информацию об идеальном значении того или иного свойства, но и о том на сколько все остальные значения данного свойства “хороши” с точки зрения предъявленных требований к объекту оценки. Элементом Ei множества E - является функция V=fi(Si). Эта функция выражает то, насколько конкретное значение свойства Si удовлетворяет задаче (повышает оценку). Значения же этой функции лежат в пределах нуля и единицы. Если значение функции равно единице, то значение свойства полностью удовлетворяет задаче и повышает общую оценку объекта в соответствие с весом этого свойства в рамках требований и требований в рамках всей модели (т.е. с учетом дуговых коэффициентов и весовых коэффициентов). Напротив, если значение функции равно нулю, то данное значение не удовлетворяет данной задаче и свойство не вносит вклада в общую оценку объекта. Очевидно, что функция эта непрерывна, если свойство Si численное и имеет n значений, если свойство Si перечислимое (где n - количество исходов i-го свойства). Для повышения эффективности оценивания, в оценочную модель вводится т.н. бинарный вектор критичности K. Если значение элемента вектора критичности Kij равно 1 то j-е свойство критично в i-ом требовании. Это означает, что если значение j-го свойства конкретного объекта имеет в рамках задачи меру выраженности равную 0, то объект заведомо получает оценку равную 0 - низшую оценку. Вектор критичности вносит в модель элемент логики предикатов, поскольку позволяет отсечь объекты, заведомо не удовлетворяющие условиям задачи.

Таким образом, в задаче квалиметрии оценочная модель представляет собой кортеж:

M<S,T,P,D,E,F,K>

а в задаче классификации:

M<S,T,P,D,E,C,F,K>.

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

Исходя из вышеизложенного, задача выглядит следующим образом. Необходимо сформировать структуры данных, хранящие информацию о составных частях модели (множествах S, T, P, D, E, C и их составляющих). Структуры данных должны быть как внутренними (пригодными для использования другими программными модулями экспертной системы) так и внешними (пригодными для хранения на внешних носителях). Кроме того необходимо разработать механизмы формирования и модификации сформированных структур данных для настойки системы на решение конкретной оценочной задачи, а также механизмы, обеспечивающие получение информации другими программными модулями (например модулями оценки и принятия решения). Реализация механизмов управления данными должна быть представлена в виде программных модулей (подпрограмм, классов, ресурсов), реализующих сами структуры и алгоритмы и интерфейс этих структур (как программный так и пользовательский). Реализация должна быть выполнена на языке программирования C++ и ориентирована на операционную среду Microsoft Windows, что к началу выполнения дипломной работы было предписано техническим заданием на разработку универсальной экспертной системы.

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

2.2 Типовая структура ИС

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

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

Все вышесказанное обуславливает необходимость выделения в разработанной ИС следующих, относительно самостоятельных подсистем:

- подсистема настройки и адаптации;

- подсистема управления базами данных;

- подсистема принятия и анализа решений;

- подсистема обучения;

- подсистема управления сетью.

1. Подсистема настройки и адаптации предназначена для настройки системы для решения конкретной предметной задачи;

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

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

4. Подсистема принятия и анализа решений предназначена для непосредственного формирования оценки сложных объектов, а также анализа и обоснования вычисленных оценок;

5. Подсистема управления базами данных (БД)предназначена для ведения (ввод, удаление, редактирование, сортировка и т.д.) БД, содержащей оцениваемые объекты.

Описания подсистемы фактически являются АРМ-ами различных категорий пользователей. Так администратор системы должен пользоваться подсистемой настройки и адаптации, а также подсистемой управления сетью проектов и подсистемой управления БД.

Эксперты-специалисты в предметной области должны пользоваться подсистемами обучения и возможно подсистемами настройки и адаптации и подсистемами управления БД.

Лицо принимающее решение (руководитель) как правило пользуется только подсистемой принятия и анализа решений. Рядовые операторы обеспечивают внесение исходных данных в базу и являются основными пользователями подсистемы управления базой данных. На основании этого предлагается реализовать всю универсальную экспертную систему в виде следующих пяти АРМ-ов:

- АРМ настройки и адаптации (“Администратор”);

- АРМ подсистема управления базами данных;

- АРМ принятия и анализа решений;

- АРМ обучения;

- АРМ управления проектов сетью.

С целью придания гибкости разрабатываемой системе целесообразно предусмотреть возможность конфигурирования любого из АРМ-ов, с учетом потребностей в конкретной организации. Это означает, что несмотря на совпадение названий подсистем и АРМ-ов, конкретному АРМ-у могут быть приданы функции не только основной подсистемы, входящей в его состав, но и функции других подобных подсистем. Как было сказано ранее АРМ управления сетью проектов (администратор) кроме того может быть снабжен функциями настройки и адаптации системы управления БД и т.д. АРМ-обучение, является рабочим местом экспертов, иногда целесообразно расширять функциями настройки и адаптации, функциями управления БД и функциями принятия и анализа решений. Таким образом название каждому АРМ-у дано по основной подсистеме входящей в его состав, при этом не исключается возможность включения в отдельный АРМ дополнительных функций других подсистем.

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

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

-создание проекта не завершено;

-проект не обучен;

-обучение проекта завершено;

-обучение для задач классификации с уточнениями.

Этот механизм обеспечивает координацию действий отдельных АРМ-ов через данные, а не через управление (через блок сервера). В соответствии с этим механизмом отдельные АРМ-ы как бы передают эстафету друг другу при создании модификаций и использовании конкретных проектов.

Выбор средств разработки.

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

средства, реализующие блочно-функциональный подход к разработке программ(Windows SDK);

средства реализующие объектно-ориентированный подход(OLW, MFC);

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

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

3. ПРОЕКТИРОВАНИЕ СРЕДСТВ УПРАВЛЕНИЯ ДАННЫМИ В ИС

3.1 Описание основных структур данных

Исходя из основной цели, которую необходимо достичь при разработке структур данных - универсальности, следует прежде всего разделить весь объем перерабатываемой информации на информацию разделяемую несколькими оценочными задачами и информацию приватную (доступную только одной задаче). Ввиду того, что для одного и того же набора объектов (базы данных) может быть сформулировано несколько оценочных задач весь перечень объектов, подвергающихся оценке, является разделяемой информацией, т.е. объекты, оцениваемые в одной задаче, должны быть доступны также и другим задачам (например на базе данных объектов недвижимости может решаться как задача поиска оптимальной квартиры с точки зрения цены и района, так и задача поиска наилучшей квартиры с точки зрения площади и удобств). Назовем всю информацию (в виде физических структур данных) о конкретной оценочной задаче, решаемой универсальной экспертной системой - проектом, тогда перечень объектов, а следовательно и их описание, т.е. конкретная реализация множества S является информацией, доступной нескольким проектам. Ввиду того, что перечень объектов легко представляется в виде таблицы где столбцы соответствуют конкретным свойствам из множества S, а строки соответствуют объектам, примем решение использовать для хранения перечня объектов существующие инструментарии поддержки популярных форматов данных (поддержки СУБД). Это обеспечит нам, кроме того возможность подготовки данных вне оболочки экспертной системы, что в будущем может оказаться немаловажным.

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

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

Что касается перечня классов, то здесь нет смысла использовать форматы данных СУБД, во-первых, потому что этот перечень невелик, а во-вторых, потому что перечень содержит только наименования классов.

Далее представляется целесообразным объединить множества T, D, P, K и соответствий F в одну структуру данных, во-первых, потому что эти множества логически связаны между собой (существование множеств P и D вытекает из смысла и формулировки множества Т), во-вторых, появляется возможность совместить параметры P и F (таким образом, что если соответствия между i-ым требованием и j-ым свойством нет то вес Pij = 0).

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

Файл с расширением *.pjt. Этот файл хранит информацию о модели в целом. Файл имеет следующую структуру:

Таблица 3.1.

Смещение	Длина	Описание
0	1	Байт флагов - содержит информацию о задача, состоянии, статусе проекта
1	30	Имя файла STC связанного с проектом
31	80	Краткое наименование проекта
121	20	Пароль
141	1	Количество классов (только для задачи классификации)
142	n*41	Наименования классов

Файл с расширением *.stc. Этот файл хранит информацию о множестве свойств объектов. Файл имеет следующую структуру:

Таблица 3.2.

Смещение	Длина	Описание
0	2	Номер свойства
2	129	Наименование свойства
131	1	Тип свойства
132	30	Имя значения. (Только для перечислимых свойств)
164	4	Граничное значение. (Только для численных свойств)

Файлы с расширением *.db. Этих файлов в каждом проекте два. Один из них имеет имя, такое же как у вышеописанного stc-файла и хранит перечень объектов, подвергаемых оценке. Второй имеет имя, такое же как у pjt-файла и хранит оценки объектов, полученные в процессе решения оценочной задачи. Имена полей файлов формируются по принципу: первый символ - это буква обозначающая тип свойства, соответствующего данному полю R - для регистрационных и I для информационных (численных и перечислимых) полей; следующие символы представляют собой порядковый номер поля в символьном виде(причем нумерация информационных и регистрационных полей ведется раздельно).Оба файла связаны друг с другом по реляционному принципу. Файл имеет формат Paradox 3.5.

Файл с расширением *.tpt. Файл имеет имя, такое же как имя pjt-файла и хранит информацию о множествах T, P, D, К и соответствиях F. Файл имеет следующий формат:

Таблица 3.3.

Смещение	Длина	Описание
0	129	Имя требования
130	n*4	Вектор весов требования в каждом классе
-	n	Вектор критичностей требований в каждом классе
-	1	Количество свойств, относящихся к данному требованию
-	m	Вектор номеров свойств, относящихся к данному требованию
-	n*m*4	Матрица дуговых коэффициентов m свойств в n классах

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

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

3.2 Назначение, состав и описание блока управления данными

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

- создавать описание конкретной оценочной задачи и всех ее компонентов (создавать новый проект);

- настраиваться на решение ранее сформулированной задачи (открывать существующий проект);

- удалять информацию о задаче, если в ней отпала необходимость (удалять проект);

- модифицировать все составные части проекта, несущие информацию о компонентах оценочной модели, т.е. модифицировать представления множеств S, T, P, E, D, C, K и соответствий F.

- производить сохранение проведенных изменений с предоставлением возможности пользователю продублировать информацию.

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

С точки зрения программного интерфейса проектируемые алгоритмы должны:

- предоставлять информацию о всех компонентах модели другим программным модулям системы;

- хранить в памяти информацию об именах файлов-компонентов проекта для возможности их записи на диск и чтения с диска;

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

- оповещать остальные подсистемы об изменениях компонентов модели и состояния проекта.

Третий пункт требует пояснения. Будем различать следующие возможные состояния проекта:

- “проект не создан” - не сформировано множество требований к объектам - некорректен файл tpt;

- “проект не обучен” - не сформированы эталоны - некорректен файл эталонов;

- “проект обучен” в этом состоянии допускается проведение оценки объектов;

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

Исходя из вышеизложенных требований можно составить наиболее укрупненный перечень блоков по управлению данными:

- блок создания проекта;

- блок открытия проекта;

- блок закрытия проекта;

- блок удаления проекта;

- блок модификации проекта;

- блоки оповещения других подсистем об изменении состояния проекта;

- блоки реакции на ошибки и обработки исключительных ситуаций;

- блоки контроля действий пользователя.

Приведенный список весьма укрупнено отражает структуру подсистемы и требует дальнейшей детализации.

Блоки открытия проекта включают в себя:

- алгоритмы восстановления информации о составных частях проекта, именах файлов, информации о состоянии проекта;

- алгоритмы восстановления (чтения) составных частей проекта в зависимости от типа решаемой задачи и состояния проекта;

- алгоритмы анализа корректности восстановленной информации и принятия решения о возможности открытия проекта или об изменении состояния.

- алгоритмы запуска необходимых подпрограмм дальнейшей настройки системы.

Блоки создания проекта включают в себя:

- алгоритмы запроса и присвоения имен файлам-компонентам проекта;

- алгоритмы формирования составных частей проекта;

- алгоритмы записи сформированных компонентов проекта на диск;

- алгоритмы установки состояния проекта, в зависимости от количества и качества сформированных частей проекта;

блоки закрытия проекта включают в себя:

- алгоритмы записи компонентов проекта на диск;

- алгоритмы освобождения памяти;

- оповещение других подсистем о закрытии проекта;

- закрытие открытых файлов, баз данных и т.д.

Блоки модификации проекта и формирования компонентов проекта включают в себя:

- поддержку диалогов с пользователем при модификации конкретных частей проекта;

- алгоритмы анализа необходимости модификации других компонентов проекта;

- алгоритмы анализа необходимости изменения состояния проекта и необходимости переобучения;

- анализ необходимости и алгоритмы запуска механизмов модификации баз данных из подсистемы управления базами данных;

- алгоритмы сохранения изменений и возможности отказа от них.

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

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

Блоки удаления проекта включают в себя запрос имени проекта и верификацию запроса на удаление.

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

-реакцию на несоответствие фактически имеющимся данным состоянию проекта;

-реакцию на фатальные ошибки;

-реакцию на ошибки поиска файлов.

3.2.1 Функции первого уровня

OpenProject

Прототип: int OpenProject (void);

Назначение: Реакция на выбор пункта меню Проект|Открыть. Открывает проект, инициализирует переменные CurrentProject, Records, Demands, Table.

Параметры: нет

Возврат: 0 - в случае удачного выполнения; !0 - в противном случае

CreateProject

Прототип: BOOL CreateProject (void);

Назначение: Реакция на выбор пункта меню Проект|Создать. Создает новый проект, в диалоговом режиме инициализирует переменные CurrentProject, Records, Demands, Table.

Параметры: нет

Возврат: TRUE - в случае удачного выполнения; FALSE - в противном случае

CloseProjectChoice

Прототип: void CloseProjectChoice (void);

Назначение: Реакция на выбор пункта меню Проект|Закрыть. Закрывает открытый проект, очищает переменные CurrentProject, Records, Demands, Table, закрывает файлы.

Параметры: нет.

Возврат: нет.

SaveProject

Прототип: void SaveProject (char *)

Назначение: Сохраняет информацию о компонентах модели в соответствующих файлах.

Параметры: имя проекта

Возврат: нет

DeleteProject

Прототип: void DeleteProject (void)

Назначение: Удаляет файлы проекта.

Параметры: нет

Возврат: нет

ModifyDB

Прототип: void ModifyDB (void)

Назначение: В диалоговом режиме производит модификацию перечня свойств объектов и при необходимости запускает механизм модификации баз данных

Параметры: нет

Возврат: нет

ModifyDemands

Прототип: void ModifyDemands (void)

Назначение: В диалоговом режиме производит модификацию перечня требований к объектам.

Параметры: нет

Возврат: нет

ModifyClasses

Прототип: void ModifyClasses (void)

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

Параметры: нет

Возврат: нет

3.2.2 Описание функций нижних уровней

OpenProjectFunct

Прототип: int OpenProjectFunct (char *);

Назначение: Проверяет наличие и корректность файлов проекта и инициализирует необходимые переменные

Вызывающие функции: OpenProject

Параметры: имя проекта

Возврат: 0 - в случае успешного завершения, иначе - код ошибки

CreateDemandTemplate

Прототип: BOOL CreateDemandTemplate (void)

Назначение: на основе диалога с пользователем инициализирует переменную Demands (создает требования)

Вызывающие функции: CreateProject

Параметры: нет

Возврат: TRUE - в случае удачного выполнения; FALSE - в противном случае

CreateProjectClasses

Прототип: BOOL CreateProjectClasses (void)

Назначение: на основе диалога с пользователем создает множество классов

Вызывающие функции: CreateProject

Параметры: нет

Возврат: TRUE - в случае удачного выполнения; FALSE - в противном случае

CreateDBStructure

Прототип: BOOL CreateDBStructure (char *)

Назначение: на основе диалога с пользователем создает множество свойств (инициализирует переменные Records, Table).

Вызывающие функции: CreateProject

Параметры: имя файла STC

Возврат: TRUE - в случае удачного выполнения; FALSE - в противном случае

UseExistingTable

Прототип: BOOL UseExistingTable (char *);

Назначение: Инициализирует переменные
Records, Table на основе данных существующего файла STC.

Вызывающие функции: CreateProject.

Параметры: имя файла STC

Возврат: TRUE - в случае удачного выполнения; FALSE - в противном случае

CreateSTCDlgProc

Прототип: BOOL FAR PASCAL _export CreateSTCDlgProc
(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam)

Назначение: реализует диалог с пользователем по созданию множества свойств

Вызывающие функции: ModifyDB,
CreateDBStructure

Параметры: hDlg - дескриптор диалогового окна; msg - код сообщения; wParam, lParam - параметры сообщения

Возврат: код выхода из диалога

CreateTPTDlgProc

Прототип: BOOL FAR PASCAL _export CreateTPTDlgProc
(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam)

Назначение: реализует диалог с пользователем по созданию множества требований

Вызывающие функции: ModifyDemands,
CreateDemandTemplate

Параметры: hDlg - дескриптор диалогового окна; msg - код сообщения; wParam, lParam - параметры сообщения

Возврат: код выхода из диалога

ClassesDlgProc

Прототип: BOOL FAR PASCAL _export ClassesDlgProc
(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam)

Назначение: реализует диалог с пользователем по созданию множества классов в задаче классификации

Вызывающие функции: ModifyClasse

Параметры: hDlg - дескриптор диалогового окна; msg - код сообщения; wParam, lParam - параметры сообщения

Возврат: код выхода из диалога.

4. ОПИСАНИЕ ПРИМЕНЕНИЯ СРЕДСТВ УПРАВЛЕНИЯ ДАННЫМИ В ИС

4.1 Описание интерфейса пользователя (руководство пользователя)

4.1.1 Создание проекта

Создание проекта происходит в диалоговом режиме и включает следующие шаги:

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

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

Описание множества распознаваемых классов (только для задачи кассификации).

Для создания проекта выберите пункт меню "Проект|Создать." ("Project|Create."). После этого пройдите все шаги создания проекта.

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

Описание параметров проекта происходит в диалоговом окне, внешний вид и описание которого приведены ниже.



Рис 4.1.Окно установки параметров проекта

Строка ввода описания - "Описание" ("Description"). Служит для ввода краткого описания (или наименования) проекта (до 20 символов)

Кнопка одиночного выбора типа решаемой задачи - "Задача" ("Task"). Позволяет выбрать тип решаемой задачи из двух вариантов:

"Квалиметрия" ("Qualimetric"),

"Классификация" ("Classification").

Кнопка одиночного выбора способа доступа к используемой базе данных "Статус" ("Status"). Позволяет выбрать способ доступа к базе данных из двух вариантов:

"Общий" ("Public"),

"Частный" ("Private").

для задания коллективного или индивидуального способа использования базы данных соответственно.

Кнопка "OK". Служит для подтверждения описания проекта.

Кнопка "Отмена" ("Cancel"). Служит для отказа от введенных параметров и прерывания создания проекта.

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

В строке ввода описания проекта введите краткое наименование проекта.

Выберите тип задачи, которую будет решать создаваемый проект.

Выберите способ доступа к используемой базе данных:

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

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

Нажмите кнопку "OK".

Имя файла, содержащего описание свойств, должно отличатся от имени файла проекта.

Если Вы выбрали индивидуальный способ доступа к базе данных, система запросит пароль доступа к проекту в окне запроса пароля.

Установка пароля происходит в окне, внешний вид которого приведен ниже

Рис 4.2.Окно ввода пароля

Органы управления окна:

Строка ввода пароля. "Введите пароль" ("Enter password").

Строка повторного ввода пароля. "Еще раз" ("Retype password").

Кнопка "OK" - подтверждение установки пароля. Пароль установится при условии, что он введен одинаково в обеих строках ввода. В противном случае Вам будет предложено еще раз попытаться установить правильный пароль.

Кнопка "Отмена" ("Cancel") - отказ от установки пароля.

Для установки пароля доступа к проекту введите пароль в строке ввода пароля и повторите ввод в строке повторного ввода пароля. Затем нажмите кнопку "OK".

Если Вы откажетесь от ввода пароля и нажмете кнопку "Отмена" ("Cancel"), для базы данных будет установлен коллективный способ доступа.

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

В типовом окне запроса имени файла система запросит имя файла с описанием перечня свойств. В нем Вы должны выбрать существующий файл с описанием перечня свойств объектов или ввести имя нового файла.

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

Если файл с описанием перечня свойств не существует, система предложит сформировать перечень свойств объектов в редакторе свойств.

Система предложит сформировать множество классов (только для классификации).

Система предложит сформировать требования.

Вам будет предложено обучить систему.

Вы можете прервать создание проекта на любом из шагов, нажав кнопку "Отмена" ("Cancel") в любом из окон.

4.1.2 Открытие проекта

Если решаемая задача уже описана в рамках системы Expek Pro (проект создан), то для начала работы с ней необходимо подготовить систему к решению этой задачи - открыть проект.

Для открытия проекта выберите команду меню "Проект|Открыть." ("Project|Open."). Затем выберите имя нужного проекта в типовом окне открытия файла.

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

4.1.3 Закрытие проекта

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

Для этого нужно выбрать команду меню "Проект|Закрыть" ("Project|Close"). Система завершит работу с проектом с обязательным сохранением всей информации о текущем состоянии проекта в файлах, используемых проектом.

4.1.4 Сохранение копии проекта

Для сохранения копии проекта выберите команду меню "Проект|Сохранить как." ("Project|Save as."). Система запросит имя копии проекта и имя копии базы данных в типовом окне запроса имени сохраняемого файла. Имена проекта и базы данных не должны совпадать. Если Вы введете одинаковые имена проекта и базы данных, то в сохранении копии проекта будет отказано.

4.1.5 Удаление проекта

Для удаления проекта выберите команду меню "Проект|Удалить." ("Project|Delete."). Система запросит имя удаляемого проекта в типовом окне выбора имени файла и удалит файлы, относящиеся к проекту.

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

4.1.6 Формирование множества свойств

Описание множества свойств объектов происходит в экране, внешний вид которого показан ниже:

Рис.4.3. Окно редактора свойств.

Редактор свойств предназначен для описания и модификации множества свойств, описывающих объект в данной оценочной задаче.

Экран состоит из трех панелей:

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

Панель описания свойств численного типа. В этой панели отображается информация о выделенном свойстве численного типа.

Панель описания свойств перечислимого типа. В ней отображается информация о выделенном свойстве перечислимого типа.

Список имен свойств - "Список свойств" ("Characteristic list"). В зависимости от состояния свойства имя его в данном списке может быть отображено одним из следующих цветов:

синим - если свойство было модифицировано или добавлено в текущем сеансе редактирования;

черным - если свойство не модифицировалось в текущем сеансе редактирования;

красным - если свойство было удалено в текущем сеансе редактирования.

Строка ввода имени свойства - "Имя свойства" ("Characteristic name"). Отображает имя выделенного свойства. Также используется для ввода имени нового свойства или модификации имени выделенного.

Кнопка одиночного выбора типа свойства. "Тип свойства" ("Characteristic type"). Отображает тип выделенного свойства и позволяет ввести тип нового свойства. Возможен выбор из трех вариантов:

"Регистрационное" ("Registrational");

"Численное" ("Numeric");

"Перечислимое" ("Enumerated").

Кнопка "Добавить" ("Add"). Реализует функцию добавления нового свойства.

Кнопка "Удалить" ("Delete"). Реализует функцию удаления выделенного свойства.

Кнопка "Изменить" ("Modify"). Реализует функцию модификации описания выделенного свойства.

Панель содержит две строки ввода "Минимум" ("Min") и "Максимум" ("Max") для задания минимального и максимального значения численного свойства соответственно. Панель доступна, если текущее свойство имеет численный тип.

Панель содержит:

Список имен значений выделенного свойства "Список значений" ("List of values").

Имя вводимого значения "Имя значения" ("Value name").

Кнопка добавления значения "Новое" ("New").

Кнопка удаления значения "Удалить" ("Delete").

Панель доступна, если тип выделенного свойства - перечислимый.

Кроме органов управления, находящихся в вышеописанных панелях, в экране редактора свойств находятся следующие органы управления:

Кнопка "OK". Служит для завершения формирования с сохранением сделанных изменений.

Кнопка "Отмена" ("Cancel"). Служит для завершения формироания перечня свойств с отказом от сделанных изменений.

Для добавления регистрационного свойства необходимо:

В списке имен свойств выбрать свойство, перед которым необходимо вставить вводимое регистрационное свойство.

Ввести имя свойства в строке ввода имени свойства.

Выбрать тип свойства "Регистрационное" ("Registrational").

Нажать кнопку "Добавить" ("Add").

После выполнения этих действий свойство добавится в список (и будет отображаться синим цветом) при условии соблюдения следующих условий:

имя свойства уникально;

свойство добавляется первым либо непосредственно после регистрационного.

В противном случае добавления не произойдет, и появится соответствующее объясняющее сообщение.

Для добавления численного свойства необходимо:

В списке имен свойств выбрать свойство, перед которым необходимо вставить вводимое численное свойство.

Ввести имя свойства в строке ввода имени свойства.

Выбрать тип свойства "Численное" ("Numeric").

В панели численного свойства ввести минимальное и максимальное значения.

Нажать кнопку "Добавить" ("Add").

После выполнения этих действий свойство добавится в список (и будет отображаться синим цветом) при условии соблюдения следующих условий:

имя свойства уникально;

после добавляемого свойства не следует ни одного регистрационного свойства;

численные значения минимума и максимума введены корректно;

минимальное значение меньше максимального.

В противном случае добавления не произойдет, и появится соответствующее объясняющее сообщение.

Для добавления перечислимого свойства необходимо:

В списке имен свойств выбрать свойство, перед которым необходимо вставить вводимое свойство.

Ввести имя свойства в строке ввода имени.

Выбрать тип свойства "Перечислимое" ("Enumerated").

Сформировать множество значений в панели перечислимого свойства. При этом следует иметь ввиду, что количество значений должно быть не меньше двух.

Нажать кнопку "Добавить" ("Add").

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

Для изменения имени свойства необходимо:

В списке имен выбрать свойство, которое модифицируется.

Изменить его имя в строке ввода имени (при этом кнопка "Изменить" ("Modify") начнет мигать, указывая на необходимость нажатия на нее). Вновь введенное имя должно быть уникально.

Нажать кнопку "Изменить" ("Modify").

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

Для изменения границ численного свойства необходимо:

В списке имен выбрать свойство, которое модифицируется.

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

Нажать кнопку "Изменить" ("Modify").

Для изменения перечня значений перечислимого свойства необходимо:

1. В списке имен выбрать свойство, которое модифицируется.

2. Для добавления значения необходимо в списке выбрать значение, перед которым нужно вставить вводимое. Затем необходимо в строке ввода имени значения ввести имя. Затем - нажать кнопку "Новое" ("New"). Если введенное имя уникально, значение будет добавлено в список.

3. Для удаления значения необходимо выбрать в списке значений необходимое значение и нажать кнопку "Удалить" ("Delete").

4. Нажать кнопку "Изменить" ("Modify").

5. Если введенные данные корректны (число значений не меньше двух) будет выполнена модификация свойства и в списке имен свойство выделится синим цветом.

Любую модификацию свойства необходимо завершать нажатием кнопки "Изменить" ("Modify"). Если Вы этого не сделаете, при переходе к другому свойству в списке все изменения описания редактируемого свойства будут потеряны.

Для удаления свойства необходимо:

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

Нажать кнопку "Удалить" ("Delete"). Свойство будет помечено красным цветом в списке имен свойств. Вы можете восстановить удаленное в текущем сеансе редактирования свойство в первоначальном либо измененном по Вашему желанию виде

Для восстановления удаленного в текущем сеансе свойства необходимо:

Выбрать имя удаленного свойства.

Изменить параметры описания свойства (если необходимо).

Нажать кнопку "Добавить" ("Add").

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

Следующие изменения, сделанные в описаниях свойств, приводят к потере данных в базе данных проекта:

удаление свойства;