CC BY
35
жения и гипотезы на основе априорных сведений относительно документов коллекции, которые и определяют конкретную реализацию вероятностной модели поиска. Например, эта оценка может быть вычислена в соответствии с теоремой Байеса по некоторой функции вероятностей вхождения термов данного документа в релевантные и нерелевантные документы.
Векторные и вероятностные модели, основанные на статистической информации о встречаемости терма в отдельном документе или в коллекции документов, не обеспечивают необходимой точности для идентификации сущности.
Пусть согласно какому-либо методу высказывание Ук получило оценку релевантности выше, чем высказывание Уу (случай ошибки). Введем обозначения:
Тй - множество термов документа б, идентифицирующего сущность 8ь
Ту - множество термов высказывания Уу, идентифицирующего сущность 8х;
Тк - множество термов высказывания Ук, идентифицирующего сущность 82;
Тй пТупТк - участвующие в поиске термы, характерные для сущностей и 82;
ТйпТу\(ТйпТупТк) - участвующие в поиске термы, указывающие на верное соответствие между высказыванием Уу и сущностью 8х;
ТапТк\(ТапТупТк) - участвующие в поиске термы, вносящие ошибку в оценку релевантности.
Основные причины ошибок заключаются в следующем.
1. Между термами высказывания присутствуют функциональные зависимости, идентифицирующие сущность. Например, высказывания «принтер НР 01200 с картриджем С7115А» и «картридж С7115А для принтера НР 01200» имеют идентичные наборы термов. Предлоги «для» и «с» задают функциональные отношения
между группами термов, но заведомо имеют малые значения глобального и локального веса терма.
2. Высказывание Уу задано более кратко (например, использовано смешанное задание сущности), чем высказывание Ук с большим количеством термов, имеющих высокую оценку.
Экспериментальные данные подтверждают утверждения о причинах недостаточной точности векторных и вероятностных моделей для задачи идентификации сущности. При проведении экспериментов в коллекции Б мощностью порядка 104 документов, при 279 случаях ошибок множество ТйпТу\(ТйпТупТк) было всегда пусто.
Кроме того, был исследован режим обратной связи по релевантности, когда итеративным путем уточняется вес термов. Для каждого высказывания исходного множества (далее - обучающая выборка) было задано соответствие в коллекции Б. В случае ошибки, вес термов множества ТйпТу\(ТйпТупТк) увеличиваем, а вес термов ТйпТк\(ТйпТупТк) уменьшаем.
До и после уточнения весов термов проводился прогон программной системы на обучающей и тестовой выборке высказываний. В полученном ответе системы подсчитывалось число правильно найденных пар высказывание-документ.
Таблица
Номер Число случаев Число коррекций
итерации ошибок весов термов
1 279 3692
2 90 173
3 74 9
4 73 0
После уточнения весов термов эффективность метода на «обучающей» выборке увеличилась (см. табл.). Увеличения эффективности на тестовой выборке зафиксировано не было.
АВТОМАТИЗАЦИЯ УПРАВЛЕНИЯ ИНФОРМАЦИОННОЙ ИНФРАСТРУКТУРОЙ КОМПЛЕКСНОЙ САПР
В.Н. Ачкасов, A.B. Стариков, A.B. Кузьмин
Программный инструментарий, поддерживающий иерархическую структуру проекта, сетевое планирование и оценку получаемых результатов с использованием динамической модели процесса проектирования, представлен в мониторной и информационной системах САПР. Данные системы инвариантны по отношению к другим (проектирующим) подсистемам и обеспечивают своего рода платформу для построения комплексных САПР различного назначения.
Разработка информационной модели процесса проектирования проходит в три этапа. На первом
этапе осуществляется выбор одного из множества технологических маршрутов проектирования, обеспечиваемых комплексной САПР, то есть задается (и прорабатывается) так называемый вектор обработки. При этом определяются идентификаторы проектирующих подсистем, реализующих необходимые проектные процедуры. Перечень идентификаторов устанавливается и утверждается руководителем САПР по согласованию с администратором информационной системы. В дальнейшем это множество идентификаторов, включенное в базу данных информационной системы, исполь-
зуется при разработке и сопровождении информационных моделей проектов с целью указания подсистем, имеющих право доступа к проектным решениям, выработанным для каждого функционального узла каждого разрабатываемого проекта.
На втором этапе создается иерархическая схема проекта, адекватно отражающая структуру объекта проектирования. На этом этапе выполняется иерархическая декомпозиция объекта на фрагменты, в отношении которых также может быть выполнена декомпозиция, и так далее до тех пор, пока сложность каждого фрагмента не станет приемлемой для выполнения его проектирования с помощью имеющихся инструментальных средств. В дальнейшем фрагменты объекта проектирования получают относительную свободу при прохождении по маршруту проектирования, то есть их проектирование в определенном смысле выполняется самостоятельно.
Иерархическая схема проекта используется при разработке исходного описания информационной модели проекта и создается в среде информационной системы комплексной САПР. Для подготовки исходного описания разработан специальный язык описания проекта, позволяющий задавать следующие элементы информационной модели проекта:
- уникальный идентификатор, однозначно определяющий данный проект среди множества разрабатываемых в САПР проектов;
- перечень уникальных (в рамках данного проекта) идентификаторов проектируемых функциональных узлов объекта проектирования;
- иерархическую подчиненность (структуру) функциональных узлов объекта проектирования;
- перечень идентификаторов типов проектных решений, вырабатываемых для каждого функционального узла объекта проектирования и выбираемых из множества (домена) типов проектных решений, определенного в базе данных информационной системы;
- перечень идентификаторов проектирующих подсистем, реализующих проектные процедуры, которые имеют право доступа к проектному решению указанного типа для каждого проектируемого узла;
- перечень идентификаторов проектирующих подсистем, реализующих проектные процедуры, ответственным исполнителям которых необходимо послать оповещение в случае изменения проектного решения для проектируемого узла.
Трансляция исходного описания информационной модели проекта выполняется с помощью генератора модели проекта. Для визуальной проверки сгенерированной рабочей модели проекта используется листинг рабочей модели, формируемый одной из сервисных программ. При необходимости рабочую модель проекта можно модифицировать либо путем корректировки исходного
описания модели и повторной его трансляции, либо с помощью программ интерактивной (оперативной) корректировки. Рабочая модель проекта используется информационной системой для решения задач управления фондом проектных решений и, в частности, для предотвращения несанкционированного доступа к контейнерам с проектными решениями со стороны проектирующих подсистем.
На третьем этапе создается информационная модель процесса проектирования путем выполнения привязки фрагментов объекта проектирования к проектным процедурам конвейера обработки, представляющего технологический маршрут проектирования. На этом этапе решается вопрос о возможности параллельного выполнения некоторых проектных процедур маршрута, а также осуществляется календарное планирование работ, выполняемых проектными процедурами маршрута. Информация о векторе обработки, то есть о технологическом маршруте проектирования, и результаты иерархической декомпозиции проекта, полученные на предыдущих этапах, используются при разработке исходного описания информационной модели процесса проектирования на специальном декларативном языке.
Укрупненная структурная схема формирования информационной модели процесса проекти-
рования, использующейся при решении задач автоматизации управления информационной инфраструктурой САПР, представлена на рисунке.
Для обработки исходного описания и формирования рабочей модели процесса проектирования используется специальный транслятор, называемый генератором рабочей модели. Генерация ра-
бочей модели процесса проектирования выполняется по трехпроходной схеме. Хотя многопроходная схема трансляции требует несколько больших временных затрат на генерацию рабочей модели, чем однопроходная, она позволяет существенно снизить сложность процедур, реализующих каждый проход генератора.
УНИФИЦИРОВАННЫЙ ИНФОРМАЦИОННЫЙ ИНТЕРФЕЙС И ЕГО РЕАЛИЗАЦИЯ В КОМПЛЕКСНОЙ САПР
А.В. Стариков, И.П. Потапов, Д.Г. Хорюшин
Современные комплексные САПР различного назначения часто создаются путем включения в их состав наиболее эффективных инструментальных средств проектирования, обеспечиваемых сторонними фирмами-разработчиками. При объединении проектирующих подсистем, созданных на различной концептуальной основе, первостепенной становится задача организации системного информационного интерфейса комплексной САПР.
Информационное взаимодействие проектирующих подсистем в комплексной САПР осуществляется путем передачи сформированных проектных решений. Эта передача определяется причинно-следственными связями между проектными процедурами, представленными в технологическом маршруте проектирования. По характеру зарождения, использования и передачи проектная информация может быть разделена на две группы: информация, необходимая для использования только в данной проектной процедуре; информация, совместно используемая несколькими проектными процедурами.
Поскольку минимальным объектом управления для мониторной системы (МС) комплексной САПР является проектная процедура, при рассмотрении информационного взаимодействия проектирующих подсистем учитывается только информация, совместно используемая разными проектными процедурами. Принимая во внимание высокую сложность и разнородность подсистем комплексной САПР и противоречивость требований к ее информационному обеспечению, в качестве основной единицы информационного обмена между подсистемами предлагается использовать специальный файл, называемый контейнером.
Контейнер - это унифицированная информационная структура, состоящая из двух синтаксически и семантически неоднородных частей: описательной части контейнера и собственно проектных данных.
Описательная часть контейнера условно делится на три части: описательная часть, формируемая автором проектного решения; описательная часть, формируемая МС; описательная часть,
формируемая информационной системой (ИС).
При формировании контейнера с проектным решением его автор (обычно это ответственный исполнитель проектной процедуры) должен поместить в контейнер информацию, однозначно идентифицирующую этот контейнер и обеспечивающую учет его движения в распределенной вычислительной среде комплексной САПР. Эта информация содержит следующие сведения: идентификатор ЭВМ; идентификатор проектирующей подсистемы САПР; идентификатор проекта; идентификатор проектной процедуры; идентификатор автора (имя ответственного исполнителя); идентификатор функционального узла в проекте; идентификатор типа проектного решения; тип носителя, назначенного для хранения контейнера (магнитный диск, магнитная лента, магнитно-оптический диск и т.д.); дата формирования контейнера; спецификации файлов, содержащих собственно проектные данные; резервные поля (для обеспечения возможности развития системы).
Перечисленная информация вводится автором проектного решения с помощью редактора, входящего в состав сервисных средств МС. Формирование и редактирование информации выполняется с помощью специальных экранных форм и ряда простых команд редактирования содержимого их полей ввода.
Описательная часть, формируемая МС, включает в себя следующие элементы: данные паспортизации (идентификатор контейнера, контрольные суммы записей данных, файлов данных и контейнера в целом); резервные поля (для обеспечения возможности развития системы).
Описательная часть, формируемая ИС в момент приема контейнера, а также на протяжении всего времени хранения его в хранилище контейнеров ИС, включает в себя следующие элементы: дата поступления контейнера в хранилище; ссылки на записи в журнальных файлах учета выдачи контейнеров и учета изменений, выполненных в контейнерах; резервные поля (для обеспечения возможности функционального расширения системы).
