Содержание к диссертации
Введение
Глава 1. Диалоговые средства для многоаспектного информационного поиска
1.1.Основные Факторы, определяющие состояние индустрии интерактивного информационного поиска ..
1.1.1."Феномен конечного пользователя" ...15
1.1.2.Вопросы совместимости и стандартизации языковых средств диалоговых ИПС ...17
1.2 Дополнительные требования к диалогу для систем, ориентированных на конечного пользователя ..19
1.3.Характеристика типовых решений, используемых при построении диалога в современных АИПС ...22
1.3.1 .Системы с командным языком . 22
1.3.2.Системы с доступом через иерархию меню ...23
1.3.3.Системы комбинированного типа ...25
1.4.Интерфейсы ИПС и экспертные системы для информационного поиска...26
1.4.1 .Коммуникационные интерфейсы ... 29
1.4.2. Поисковые интерфейсы ... 29
Выводы .37
Глава 2. Функциональная модель с развитым сценарием диалога .39
2.1 Концепция функциональной модели ИПС с развитым сценарием диалога..39
2.2 Функциональные характеристики модели ИПС с развитым сценарием диалога ...42
2.2.1. Наличие нескольких уровней (языков) общения пользователь/система . 42
2.2.2. Адаптация пользователя к системы в процессе работы . 46
2.2.3. Совместимость с системами, управляемыми различными командными языками ...48
2.2.4. Управление диалогом по инициативе пользователя и по инициативе системы ...50
2.2.5. Обеспечение заинтересованности пользователя в обучении . 52
2.2.6. Динамическое формирование поисковой стратегии ...53
2.2.7. Уточнение информационной потребности в процессе диалога . 55
2.2.8. Инструментальные средства для повышения эффективности многоаспектного поиска 56
2.2.9. Предоставление справочной информации и автоматическая генерация запросов ...59
2.2.10.Ведение банка поисковых стратегий ...61
2.2.11 .Создание комфортной среды для пользователя ...62
Выводы ...64
Глава 3. Построение программного комплекса АИПС с развитым сценарием диалога ...65
3.1. Структура программного комплекса ... 66
3.2 Структура функциональных модулей ... 67
3.3 Проблемы навигации в сети диалога. Графовая модель программного комплекса ... 71
3.4 Ситуативное меню и ситуативная подсказка . 76
3.5 Технологический аспекты создания программного комплекса . 77
3.6 Основные компоненты технологической системы поддержки разработки ..79
3.7 "Диалог разработчика" - диалоговый инструмент поддержки разработки и моделирования программного комплекса АИПС с развитым сценарием диалога 99
3.8 Реализация механизма навигации в сети диалога ... 103
3.9 Моделирование сценариев диалога с целью выявления структурных дефектов создаваемого комплекса ... 107
3.9.1 Граф переходов и его структура 107
3.9.2.Форма представления и алгоритмы преобразования графа переходов... 110
3.10 Использование модели для выявления ошибок в структуре создаваемого программного комплекса .113
3.11 Автоматическое формирование ситуативных меню и интерактивной подсказки ...117
3.12 Администрирование разработки ... 120 Выводы .121
Глава 4. Реализация функциональной модели ИПС с развитым сценарием диалога в системах патентной информации ... 123
Выводы ... 131
Заключение ...132
Литература .134
- Дополнительные требования к диалогу для систем, ориентированных на конечного пользователя
- Наличие нескольких уровней (языков) общения пользователь/система
- Основные компоненты технологической системы поддержки разработки
- Использование модели для выявления ошибок в структуре создаваемого программного комплекса
Введение к работе
Растущая зависимость промышленно развитых стран от источников информации, а также от уровня развития и эффективности использования средств ее передачи и переработки привела к формированию на рубеже 21 века нового понятия, соответствующего новой экономической категории - национальные информационные ресурсы.
В настоящее время информационные ресурсы - это непосредственный продукт деятельности наиболее квалифицированных представителей практически всех основных профессиональных групп - квалифицированных рабочих, инженеров, техников, ученых, представителей управленческого персонала и т.д. Отмечая роль этого ресурса в современных условиях, [13] указывает, что в сложившихся к настоящему времени социально-экономических условиях ценность информационных ресурсов по отношению ко всем остальным национальным ресурсам имеет явную тенденцию к росту.
Необходимость эффективной промышленной эксплуатации этого ресурса вызвало бурный скачок в развитии промышленности обработки данных. Именно в этой сфере концентрируют свои производительные и интеллектуальные ресурсы наиболее промышленно развитые страны - в первую очередь США, Япония, Великобритания, Франция, ФРГ. В большинстве из них существуют и реализуются программы создания новых поколений технических, программных и технологических средств в сфере информационной индустрии. Одной из ключевых целей подобных программ является обеспечение эффективного доступа к информации, содержащейся в интерактивных базах данных (БД).
Среди множества разнообразных информационных ресурсов, широко используемых в настоящее время, особое место занимает патентная информация.
Патентная информация содержит накопленные за последние 150 лет сведения о способах решения огромного числа сложных технических проблем в самых различных областях человеческой деятельности. По сравнению с други- ми частями информационных ресурсов патентная информация обладает рядом отличительных особенностей: - патентные документы обычно содержат наиболее актуальную информа цию; (поскольку автор изобретения стремится обеспечить ему легальную правовую защиту, в его интересах немедленное оформление патента, описывающего суть нового метода, конструкции и пр.); патентные документы имеют унифицированную структуру, что упрощает извлечение из них нужной информации; информация, включаемая в патентные документы, обычно не может быть получена из других источников информации; так, в США 84% патентов содержат уникальную технологическую информацию; все патентные документы классифицируются с использованием национальных и международной классификаций, что позволяет более систематизированным способом проводить поиск в БД патентной информации или их статистический анализ.
Высокая ценность патентной информации как уникального источника технологических знаний определяет широкий спектр возможных способов ее использования: а) для оценки состояния технологии в заданной предметной области;
Анализ содержащейся в патентной документации информации может не только позволить выявить уже существующие технологии, избежав, таким образом, повторного проведения работ, и при необходимости вступить в контакт с их создателями, но и, на основе анализа динамики патентования, оценить перспективность области в целом, определить наиболее перспективные сферы приложения средств и интеллекта, прогнозировать развитие конкуренции, оценить рынки сбыта и пр.; б) для поиска вариантов конкретных технических решений; в) для ог\енки новизны предлагаемых решений, обеспечения патентной чисто ты разрабатываемых технологий; г) для оценки технологической активности фирм, стран и т.д.;
Существует корреляция между уровнем экспорта страны на душу населения и уровнем зарубежного патентования, т.е. динамика патентования отражает динамику технологического развития;
Патентно-лицензионный баланс является одним из общепринятых критериев, характеризующим "технологический отрыв" - таким же надежным показателем экономической мощи государства, каким в течение многих лет служила численность армии в качестве показателя военной мощи [36].
В промышленно развитых зарубежных странах ценность патентной информации получила широкое признание. К настоящему времени существует множество БД - как сугубо патентных, так и общеинформационных, содержащих патентную информацию. Так, согласно обзору, в западном мире имеется около 200 БД, имеющих патентную информацию, из которых около четверти специализируются только на ней.
В последнее время для представления многих видов информации, в том числе патентной, наблюдается массовый переход на новые виды носителей. Наиболее удобным современным носителем информации, предназначенным в первую очередь для переноса информации, является оптический диск. К оптическим дискам следует относить диски типа CD-ROM, WORM, CD-R, DVD-ROM, магнитооптические диски и т.д. Эти носители информации обладают рядом достоинств: большая емкость при небольших размерах достаточно высокая надежность носителя хранение информации в машиночитаемом виде, что позволяет оперативно использовать информацию в различных автоматизированных приложениях.
К недостаткам оптических дисков следует отнести необходимость создания новых автоматизированных информационных технологий на базе вычислительной техники, что требует значительных финансовых затрат.
Важнейшим требованием к патентному фонду является его безусловная полнота. Для обеспечения полноты фонда патентной документации патентные ведомства используют известный принцип: каждое патентное ведомство предоставляет всем свою патентную документации, в ответ получает всю патентную документацию от всех прочих патентных ведомств.
Такой международный обмен патентной документацией ведется под эгидой ВОИС. В соответствии с принятой всеми странами резолюцией, международный обмен патентной документацией, начиная с 2000г., переводится на машиночитаемый носитель информации - оптический диск.
В последние годы активно прорабатывается еще одна прогрессивная, но очень дорогостоящая идея - электронные патентные ведомства (электронные библиотеки).
В рамках этой идеи каждое патентное ведомство должно выставить свой национальный патентный фонд в Интернет, предоставив патентную информацию в общемировой доступ. В результате каждое патентное ведомство будет иметь возможность доступа ко всему мировому патентному фонду. Такое решение современно, прогрессивно, но требует значительной финансовой поддержки для качественного, полноценного моделирования привычных условий работы пользователей, профессионально использующих патентную документацию.
Сейчас для организации доступа к патентной информации (в том числе и бесплатного) широко используется Internet, имеется возможность работать с высококачественными БД патентной информации известных информационных фирм QUESTAL ORBIT, STN International, DERWENT, и т.д.
Идеи создания интегрированной автоматизированной системы патентной информации (АСПИ) в нашей стране были сформулированы достаточно давно. Поэтому, современные задачи информационного обеспечения всей территории РФ на основе новых принципов переноса и представления информации (автоматизированных информационных технологий) не являются абсолютно новыми. Особенностью указанной задачи для настоящего времени является в первую очередь: падение уровня информационного обеспечения регионов РФ из-за известных экономических трудностей, приведших к прекращению централизованного комплектования региональных патентных фондов наличие фрагментов современной инфраструктуры (в первую очередь технические аспекты) на территории РФ (линии связи, Интернет, вычислительные центры), позволяющей внедрять информационные технологии удаленного доступа существование широкого набора стандартных технических и программных средств для создания и эксплуатации современных информационных технологий имеющаяся тенденция сокращения стоимости технических вычислительных средств.
В нашей стране уже в конце 70-х годов двадцатого века была сформулирована концепция интегральной автоматизированной системы патентной информации (АСПИ), выполняющей функции специализированной всесоюзной информационной системы в составе ГАСНТИ, определены основные принципы ее построения, предусмотрены ее взаимосвязи с другими национальными и международными информационными системами [26]. Это дало возможность уже в то время перевести на качественно новый уровень решение задач обеспечения патентной информацией разработчиков новой техники и экспертов государственной научно-технической экспертизы [27]. Заложенные в этой концепции идеи нашли дальнейшее развитие в середине 80-х годов в рамках работ, предусматривающих создание распределенного банка данных патентной информации и обеспечению средств удаленного доступа к нему.
В настоящее время принимаются меры по возрождению уровня информационного обеспечения патентной документацией современными средствами, к которым в первую очередь следует отнести повышение точности (адресности) распределения патентной информации на льготных условиях, использование возможностей оптических дисков в качестве носителя информации, электронных способов связи и доставки информации.
Все это позволяет говорить о признании особой роли патентной информации в системе НТИ как в нашей стране, так и за рубежом.
Проблемы эффективного использования патентной информации связаны с рядом специфических трудностей.
Одна из них обусловлена большими объемами патентной документации (как правило, фонды патентных ведомств промышленно развитых стран содержат десятки и даже сотни миллионов документов, например, объём патентного фонда Всероссийской патентно-технической библиотеки составляет 150 миллионов единиц хранения) при наличии тесных взаимосвязей между отдельными фрагментами входящей в состав БД информации.
Так, типичной является ситуация, когда при тематическом поиске выборка релевантных документов охватывает порядка 80% рубрик Международной патентной классификации (МПК). Это делает чрезвычайно сложной задачу построения тематических БД по отдельным предметным областях. Для проведения тематического поиска в политематических БД требуется создание дополнительных инструментальных средств, обеспечивающих его эффективность.
Вторая особенность патентной информации, существенная с точки зрения организации доступа к интерактивной БД, заключается в принципиальной многоаспектности патентного поиски. Как известно, в течение достаточно долгого времени патентная информация рассматривается в качестве особой области НТИ, для которой разрабатываются собственные системы классификации документов (МПК - международная патентная классификация), получившие широкое распространение. Кроме МПК, использование которой для индексирования документов национальными патентными ведомствами стран-членов ВОИС нормативно закреплено, существуют и активно используются для индексирования и поиска национальные патентные классификации (НПК) ряда промышленно развитых стран - например, США, Великобритании, Япония.
Информационно-поисковый язык классификационного типа на базе МПК используется в качестве входного языка для всех систем поиска патентной информации в обязательном порядке. Универсальность МПК как механизма дос-
11 тупа к патентной информации позволяет широко применять принцип дополнительности при описании и индексировании патентных документов. В соответствии с этим принципом в название документа, как правило, не включается информация, присутствующая в коде или наименовании рубрики МПК, к которой отнесен этот документ.
Таким образом, поиск патентных документов в системах любого типа -библиографических, реферативных, полнотекстовых - должен рассматриваться как многоаспектный. Это в свою очередь требует наличия в поисковом аппарате эффективных средств построения развитых стратегий многоаспектного поиска, учитывающих сложную структуру патентных документов.
Наконец, еще одной особенностью патентной информации является чрезвычайно широкий круг ее потребителей. Пользователями БД патентной информации являются информационные работники фирм и государственных учреждений, работники патентных ведомств, изобретатели, ученые, инженеры и т.д.
Наличие у патентной информации явно выраженных содержательных и структурных особенностей, отличающих ее от других видов НТИ, и существование специальных требований, обусловленных характеристиками контингента ее потребителей, привело к созданию специализированных АИПС патентной информации, характеризующихся в первую очередь наличием дополнительных инструментальных средств и развитыми возможностями диалогового взаимодействия с пользователем.
Таким образом, актуальность настоящего исследования обусловлена большой практической значимостью построения механизма эффективного доступа к уникальному по объему, составу и структуре источнику технологических знаний, которым является патентная информация.
Целью исследования является разработка и практическая реализация функциональной модели автоматизированной ИПС, отличительной особенностью которой являются развитый сценарий диалогового взаимодействия системы с пользователем при многоаспектном поиске с учетом специфики патентной информации и контингента ее потребителей.
Научная новизна настоящей работы заключается в разработке и обосновании функциональной модели АИПС с развитым сценарием диалога для решения задач эффективного доступа к патентной информации. В частности, показано влияние сценария диалога на способ построения и эффективность стратегии многоаспектного поиска, проанализирована взаимосвязь функциональной модели со структурой программного комплекса, реализующего функции диалоговой АИПС, и предложен метод моделирования возможных сценариев диалога с использованием графовой модели представления этой структуры.
Практическая ценность работы заключается в том, что описанный в ней метод построения диалоговых АИПС дает возможность построения информационных систем в области патентной информации, характеризующихся развитыми инструментальными возможностями многоаспектного поиска и высокой степени адаптации к уровню знаний и подготовки пользователей. Предлагаемая технология построения программного комплекса позволяет автоматизировать реализацию ряда стандартных функций диалоговых информационных систем.
В главе 1 проводится анализ проблемы организации эффективного доступа пользователей к интерактивным базам данных и приводится характеристика типовых подходов к ее решению, существующих в современной мировой практике.
Выделяются наиболее существенные факторы, определяющие лавинообразный рост числа конечных пользователей, заинтересованных в проведении самостоятельного интерактивного поиска, и языковая несовместимость большинства наиболее распространенных интерактивных систем в промышленно развитых странах.
Описываются способы организации взаимодействия интерактивных систем с пользователем - как по входному языку (системы с командным языком, системы с доступом через меню, системы смешанного типа), так и по принци- пам организации диалога (запрос/ответ, диалог с заданным сценарием, системы с гибким сценарием диалога).
Описываются возможности современных интерфейсов, выступающих в качестве посредника между АИПС и конечным пользователем. Отмечается, что ключевым фактором, определяющим инструментальную эффективность поисковых систем (в особенности в области патентной информации), является возможность динамического формирования поисковой стратегии в процессе сеанса поиски Показывается, что эта возможность может быть обеспечена в рамках развитого диалогового взаимодействия система/пользователь, не реализуемого традиционными методами построения интерактивных АИПС.
В главе 2 выделяется перспективное направление интеллектуализации взаимодействия АИПС/пользователь, связанное с динамическим формированием поисковой стратегии в диалоговой среде, включающей развитые инструментальные и сервисные средства поиски.
Описываются характеристики предлагаемой функциональной модели АИПС с развитым сценарием диалога, основными из которых являются: наличие нескольких уровней общения пользователь/система; адаптация пользователя к системе в процессе работы; управление диалогом по инициативе пользователя и по инициативе системы; обеспечение заинтересованности пользователя в обучении; динамическое формирование поисковой стратегии с возможностью уточнения информационной потребности в процессе диалога; наличие дополнительных функциональных возможностей, ориентированных на применение в условиях многоаспектного поиска ; ведение банка поисковых стратегий; создание комфортной среды для пользователя.
Показана взаимосвязь характеристик функциональной модели с эффективностью решения задач многоаспектного патентного поиска в режиме диало- гового взаимодействия пользователь/система.
В главе 3 показано, что реализация описанной в предыдущей главе функциональной модели требует решения задачи построения программного комплекса со сложной структурой межпрограммных связей. Предлагается структура программного комплекса, реализующего функции АИПС с развитым сценарием диалога, в которой выделяются ключевые компоненты, связанные с обработкой межпрограммных связей (навигацией в сети диалога) и поддержкой стандартных функций диалога (предоставление интерактивной подсказки, вывод и обработка ситуативного меню и пр.). Описывается предлагаемая дисциплина построения программных комплексов указанной структуры, а также диалоговые средства поддержки разработки, автоматизирующие ряд функций проектирования и реализации программного комплекса. Предлагается графовая модель интерпретации сценариев диалога, служащая для выявления структурных дефектов создаваемого программного комплекса. Описываются типы семантических и структурных дефектов, обнаруживаемых при помощи данной модели.
В главе 4 описываются практические результаты использования функциональной модели АИПС с развитым сценарием диалога и механизма ее реализации при разработке автоматизированных поисковых систем в области патентной документации. Анализируется положительный опыт, полученный при создании АИПС по патентной документации (АИПС ДИАПАТ, Мимоза) с политематической базой данных.
Показано, что использование результатов настоящей работы приносит положительный эффект, заключающийся в повышении эффективности информационного поиска в среде развитого диалога, снижении трудозатрат на разработку программного обеспечения и повышении его качества до уровня, отвечающего потребностям широкого промышленного применения.
Дополнительные требования к диалогу для систем, ориентированных на конечного пользователя
Проведенный специалистами анализ описанной выше кризисной ситуации показал, что главной проблемой, требующей скорейшего разрешений, является проблема достижения языковой совместимости диалоговых ИПС (по крайней мере тех из них, которые имеют наиболее широкий контингент пользователей). Так, согласно [33], "Кризис - это проблема Вавилонской башни - все говорят на разных языках, и никто не понимает друг друга". Остроту проблемы хорошо иллюстрирует, например, тот факт, что в своё время разработчики системы Knowledge Index взяли в качестве языка запросов системы язык службы DIALOG, разработанный десятилетием раньше - только потому, что этот язык уже знаком пользователям. Этот пример показывает, что проблема несовместимости языков диалоговых ИПС имеет не только прагматический, но и научный характер - она фактически тормозит новые разработки в данной области, т.к. их появление может усугубить и без того тяжелую ситуацию.
Естественным шагом на пути к достижению совместимости различных систем является принятие национальных и международных стандартов на языки диалоговых ИПС. В качестве примера таких разработок можно отметить следующие три:В США был разработан Национальный стандарт на командный язык для интерактивного информационного поиски. Эта работа проводится под эгидой Национальной организации по стандартам в области информатики США (National Information Standards Organisation, NISO). Ее целью является, как указано в проекте стандарта, описание "словаря, синтаксиса и функционального содержания команд в командном языке, используемом в интерактивных поисковых системах". Как указывают разработчики стандарта, они рассчитывают, что многие интерактивные ИПС либо возьмут предложенный стандартный язык в качестве языка запросов, либо будут допускать его использование в качестве одного из опциональных вариантов. Проект стандарта NISO задает следующие характеристики командного языка: 1) структуру оператора (предложения) языка; эта структура достаточно проста (оператор языка = команда + спецификация команды), но формализована; отказ от попыток использовать на входе естественный язык или его подмножество - принципиальная позиция разработчиков стандарта; 2) перечень команд, их аббревиатур и функциональных описаний для наиболее распространенных функций интерактивных ИПС (поиск, отображение информации, листание экранов, просмотр словарей, сохранение результатов работы и пр.); 3) перечень операторов языка и специальных символов, значение за которыми закреплено в языке (например, логические операторы, символы усечения и маскирования и пр.).
Важной характеристикой стандарта является его "либеральная" трактовка самого понятия совместимости. Например, определенные в стандарте команды, могут быть не единственно допустимыми, а одними из множества команд, используемых для описания данных функций. Это допускает (и делает законной) синонимию команд - в том случае, если наличие синонимии команд не препятствует их однозначной идентификации; перечень команд стандарта является открытым, допускающим введение новых функций и описывающих их команд (при условии соблюдения общего синтаксиса командного языка).
Стандарт не запрещает использование, даже в рамках одной системы, различных способов взаимодействия пользователь/система. Подобная широта подхода, в сочетании с привлечением в качестве участников разработки представителей наиболее популярных информационных служб, позволяет надеяться на то, что в будущем предлагаемый стандартом язык получит широкое признание как в США, так и в международных информационных системах. б) разработка Международной организацией по стандартизации (International Standart Organisation, ISO) стандарта на Общий командный язык (Common command Language, CCL). Этот проект [50] во многом аналогичен описанному выше - с той разницей, что работа проводится на международном уровне, и создатели языка опираются на в целом удачный опыт по стандартизации языков средств интерактивных поисковых систем в сети EURONET [45]. В целом проект предполагает более детальный уровень описания языковых средств, что может затруднить его широкое распространение. в) разработка в СССР Общесетевого командного языка (ОКЯ), предназначенного для использования в рамках ГАСНТИ . В качестве прообраза такого языка предполагается использовать CCL, что должно облегчить в будущем взаимодействие с международными информационными службами. Оценивая в целом достигнутый уровень и перспективы стандартизация командных языков диалоговых ИПС, можно отметить следующие основные моменты: средства программного обеспечения интерактивных ИПС во многом сохраняют черты пакетов прикладных программ. Единство происхождения и общность подхода находит свое отражение в методологической и структурной общности языковых средств, что делает задачу их стандартизации принципиально разрешимой, несмотря на наличие широкого спектра индивидуальных языковых различий [29]; для того, чтобы цели стандартизации могли быть успешно достигнуты, она должна отвечать насущным потребностям широкого круга заинтересованных сторон - потребителей информации, разработчиков средств программного обеспечения, владельцев информационных служб и пр. Здесь критическое значение может иметь время появления стандарта, слишком ранняя стандартизация является тормозом для проведения работ по поиску альтернативных (может быть более удачных) вариантов, опоздание со стандартизацией может привести к потере управления развитием отрасли.
Наличие нескольких уровней (языков) общения пользователь/система
Анализ традиционно используемых при построении ИПС языков диалогового общения (глава 1) позволяет сделать вывод, что системы с языком командного типа и с доступом через меню представляют собой в определенном смысле диаметрально противоположные подходы к построению интерфейса ИПС/пользователь. В первом случае шире спектр предлагаемых возможностей, но их использование связано с преодолением трудностей обучения и адаптации к системе. Во втором случае система доступна даже малоподготовленному пользователю, но эффективность ее использования может быть невысока.
Реализуемая интерфейсами сочетание в рамках одной ИПС возможностей систем обоих типов - упрогцение командного языка путем построения надстройки типа меню - дает возможность работать малоподготовленному пользователю, однако за счет снижения эффективности поиска .
В рамках функциональной модели с развитым сценарием диалога реализуется другой подход к построению языка диалогового взаимодействия ИПС системы с конечным пользователем.
Язык меню и язык командного типа (или его элементы) рассматриваются как границы диапазона возможностей языкового интерфейса, ориентированные, соответственно, на абсолютно неподготовленного пользователи, и специалиста-посредника, работающего с предварительно проработанным информационным запросом.
Во внутренних точках этого диапазона могут находиться языковые средства промежуточных уровней, соответствующие разной степени владения пользователем навыками работы с системой. Система должна предлагать пользователю язык (уровень) обгцения, соответствующий его квалификации в области информационного поиска, опыту работы с интерактивными ИПС (в частности, с данной системой), сложности информационного запроса.
Выбор конкретных возможностей внутри диапазона осуществляется пользователем динамически, в процессе проведения сеанса работы с системой, причем может варьироваться не только во времени (по мере накопления у пользователя опыта взаимодействия с системой), но и в зависимости от конкретной диалоговой ситуации. Аналогично этому, варьируется по сложности характер сценария проводимого поиска: от минимального набора операций, позволяющих извлечь информацию из БД, до сложной стратегии поиска, включающий развитые инструментальные средства [II].
В предлагаемой нами функциональной модели системы с развитым сценарием диалога предусмотрено наличие следующих уровней и языковых средств взаимодействия пользователь - система (по нарастанию сложности диалога): 1. Использование стандартного сценария диалога, предлагаемого системой. Стандартный, принимаемый по умолчанию, сценарий диалога включает одноаспектный поиск с просмотром его статистических результатов. Роль пользователя в управлении диалогом минимальна и заключается во вводе внешней информации (наименования и значения поисковых дескрипторов) в формате, диктуемой системой. Соответственно, минимален и уровень знаний, требуемый для проведения подобного сеанса поиска; в практике патентного поиска в таком режиме могут быть получены ответы на вопрос об активности той или иной фирмы в заданной предметной области, наполненности заданной рубрики патентной классификации и т.п. 2. Использование стандартных функций системы для выполнения действий, выходящих за пределы стандартного сценария. К таким действия могут относиться, например, просмотр выборки документов, листание словарей и каталогов, заказ твердых копий отдельных документов выборки и пр. Набор стандартно закрепленных функций может быть связан или не связан с контекстом диалога - но в любом случае его мощность невелика, а назначение каждой функции вполне ясно даже малоподготовленному пользователю. Названия этих функций должны быть мнемоничны, а их назначение и/или способ вызова должны быть представлены на экране терминала (в случае контекстной зависимости - в той точке, где возможен их вызов) - в виде меню, описаний функциональных клавиш и т.п. После выполнения любой из стандартных функций системы пользователь может вернуться к принятому по умолчанию сценарию диалога. 3. Использование элементов языка командного типа. Для достаточно хорошо подготовленных пользователей наличие языка командного типа позволяет достичь экономии усилий при выполнении рутинных операций. Учитывая, однако, что в нашей функциональной модели входной язык должен быть не только (и не столько) языком ввода запросов, сколько языком диалогового взаимодействия системы и пользователя, мы предложили иной подход к построению языка командного типа. Отличительными особенностями этого языка в системах с развитым сценарием диалога является: упрощённая структура предложений (команд) языка; команды, как правило, не содержат операндов; выбор режима выполнения задаваемых ими функций определяется либо по контексту диалога, либо по умолчанию (исходя из наиболее вероятного варианта продолжения диалога), либо путем выбора по меню, представленному на экране видеотерминала; отсутствие требования стандартизации наименований команд. Для задания соответствующей команде функции достаточно ввести минимально идентифицирующую команду наименование, обычно от 1 до 3 букв. Этот подход, называемый нами "терпимой стандартизацией" сокращает количество ситуаций, трактуемых системой как ошибка пользователя, и, на наш взгляд, повышает доверие пользователя к системе; широкое использование синонимии команд. С каждой командой может быть связан список ее допустимых к использованию синонимов. Допустимость синонимии на уровне наименований команд при упрощённой структуре языка облегчает решение задачи языковой совместимости различных ИПС; допустимость омографии команд. Полный список команд системы включает команды двух уровней - контекстнонезависимые, т.е. сохранявшие одинаковый смысл в течение всего сеанса работы с системой, и контекстноза-висимые, выполнимые только в определенных точках диалога (например, заказ копии документа при просмотре выборки). Такая структуризации позволяет упростить командный язык за счет разрешения формальной омографии для команд различного уровня; наличие ситуативного меню команд, описывающего контекстнозависи-мые команды в каждом конкретном контексте.
Основные компоненты технологической системы поддержки разработки
В рамках принятого нами структурно-иерархического подхода к проектированию и разработке диалоговых АИПС технологические аспекты разработки принадлежат к нижнему, реализационному уровню. Если на функциональном уровне результатом анализа функциональных требований к АИПС явилось созданий функциональной модели АИПС с развитым сценарием диалога, на структурном уровне - структура программного комплекса в виде набора функциональных и системных модулей с разграничением функций между ними, то целью анализа и синтеза на технологическом уровне является создание технологических средств поддержки разработки, обеспечивающих эффективное построение АИПС с определенными выше функциональными и структурными свойствами.
Основными характеристиками создаваемой технологии должны быть: создаваемые средства должны быть достаточны для построения программных комплексов со сложным характером межпрограммных связей; технология должна быть простой, удобной и функционально ориентированной; перефразируя цитировавшийся уже закон Муэрса, можно сказать, что разработчики АИПС не будут пользоваться технологией, если им проще без нее обойтись, чем ее использовать - даже если это использование сулит возможность улучшения качественных или эксплуатационных характеристик создаваемой системы; специализация именно диалоговых АИПС позволяет, во-первых, обеспечить ее простоту и привлекательность для разработчика по сравнение с имеющимися достаточно развитыми, но требующими значительных усилий по освоению, универсальными системами автоматизации программирования; во-вторых, специализация технологии позволит включить в ее состав средства реализации по крайней мере некоторых из общесистемных функций по организации диалога, что может существенно упростить разработку системы в целом; технология должна быть автоматизированной, т.е. обеспечивать сокращение трудозатрат на разработку за счет автоматизации ряда ее функций. Предлагаемая технология охватывает оба этапа двухступенчатого процесса разработки программного комплекса - проектирование и программирование. Эти два этапа, последовательно выполняемые при создании любого сколько-нибудь сложного программного комплекса, тесно взаимосвязаны, однако по ряду параметров неравнозначны [13]: 1. Если в 60-70 -тые годы основная трудоемкость работ по созданию программных комплексов падала на собственно программирование (не случайно в течение продолжительного времени мерой сложности разработки являлось совокупное количество команд в результирующем программном коде, а мерой производительности труда программистов - количество написанных им операторов языка в единицу времени), то с середины 70-х годов отмечается перенос тяжести разработки на этап проектирования. Так, в качестве типичной картины распределения трудозатрат по фазам разработки в 70-е годы можно считать приводимые в [13] данные: проектирование - 46%, кодирование и автономная отладка - 20%, комплексное тестирование и приемо-сдаточные испытания -34%. В случае разработки диалоговых программных комплектов АИПС относительная роль процесса проектирования еще выше, т.к. на этом этапе обычно производится уточнение функциональных спецификаций диалогового интерфейса системы. 2. Создание языков программирования высокого уровня и развитие технологии программирования привело к резкому снижению в 80-е годы количества алгоритмических и технических ошибок, допускаемых при написании программных кодов. Так, согласно [12], при создании сложных программных комплексов распределение количества ошибок (в процентах) между этапами проектирования и программирования составляет 63/37; это же соотношение для диалоговых информационных систем равно 83/17. Таким образом, с точки зрения возможного количества ошибок этап проектирования является существенно более критичным.
Известно, что тяжесть ошибки (стоимость исправления) быстро возрастает с увеличением технологического интервала времени, измеряемого числом промежуточных производственных операций между событиями появления ошибки и ее обнаружения [13]. Применительно к задаче создания прикладных программных систем существует оценка, согласно которой экономическая тяжесть поиска и устранения ошибки программирования на интервале от выработки требований до сопровождения растет как логарифмическая функция технологического времени, на котором она оставалась необнаруженной [40]. Осознание этого факта нашло отражение в 80-е годы в разработке и применении специальных методов, обеспечивающих возможно более раннее проверку работоспособности создаваемой системы и ее соответствия функциональным требованиям за счет использования специальных методов моделирования - как на уровне отдельных функциональных компонент, так и на уровне системы-прототипа. В частности, широкую популярность завоевала идея макетирования программ, т.е. создания "на скорую руку" работоспособных - пусть в ограниченном наборе функций, с неразвитыми возможностями сервиса, отображения информации и пр. - черновых версий программ, позволяющих сделать предварительное заключение об адекватности предлагаемых методов решения проблемы [88]. Для рассматриваемой нами задачи построения программного комплекса с развитой структурой межпрограммных связей критичным является прежде всего макетирование не отдельных функциональных модулей, а взаимосвязей между ними, т.е. моделирование сценариев диалога. Возможности такого моделирования должны закладываться на этапе проектирования программного комплекса и обеспечиваться средствами поддержки разработки.
Использование модели для выявления ошибок в структуре создаваемого программного комплекса
Программный комплекс, реализующий функции диалоговой АИПС, представляет собой совокупность взаимосвязанных компонент - функциональных модулей. Поскольку для представления сценариев диалога имеют значение только те точки, в которых может произойти ветвление сценария, обусловленное взаимодействием системы с пользователем, на модели должны быть представлены только те функциональные модули, которые осуществляют подобное взаимодействие; по примерной оценке, для существенно диалоговых систем их количество составляет около 90% от общего числа компонент комплекса. В теории и практике моделирования для анализа взаимодействия структурных компонент сложных систем широко используются модели различных типов -графы, сети конечных автоматов, формальные грамматики и пр. В данной работе для построения модели сценариев диалога мы будем опираться на описанное выше представление структуры программного комплекса в виде графа переходов, узлы которого соответствуют функциональным модулям программного комплекса, а ребра - взаимосвязям (передачам управления) между ними; в этом случае любой из возможных сценариев диалога является подграфом графа переходов. Использование графовой модели позволяет, на наш взгляд, сочетать возможности формального анализа модели с сохранением полной наглядности получаемых результатов. Поскольку граф переходов заведомо ориентирован, обозначим его как G=(X,Z), где X - множество вершин, Z - многозначное отображение множества X само на себя. Целью анализа должно быть определение характеристик, которыми должен обладать граф G с тем, чтобы сделать возможным выявление и устранение его структурных дефектов на этапе проектирования программного комплекса.
В приложениях теории графов к решению задач, связанных с построением программ и программных комплексов (проверка правильности, тестирование и пр.) часто используется граф определенного типа, называемый управляющим графом программы иди системы, и обладающий следующими свойствами [17]: граф не содержит параллельных ребер; в множестве вершин графа выделена одна вершина s, называемая входом графа; в множестве вершин графа выделена хотя бы одна вершина t, называемая выходом графа; каждая вершина х из множества X достижима из входа s; каждая вершина х из множества X достигает выхода t. Нетрудно показать, что для анализируемого нами графа переходов G также выполняются второе, третье и четвертое требования из приведенного выше списка. В самом деле, на графе нетрудно выделить вершины входа и выхода - функциональные модули, реализующие процедуры запуска и завершения сеанса работы с пользователя с системой. Достижимость каждой вершины из входа графа означает требования отсутствия на графе переходов вершин, к которым невозможен доступ в процессе работы с системой. Невыполнение его означало бы, что существует функция системы, которую невозможно выполнить при любой последовательности действий пользователя (или, что то же самое, что какая-либо из программ комплекса никогда не выполняется). Достижимость выхода из любой вершины графа G означает возможность выполнить в любой точке диалога действие (последовательность действий), результатом которого будет завершение сеанса работы с системой. Требование отсутствия параллельных ребер на графе (нескольких вариантов связи между смежными точками сценария диалога) не должно являться обязательным требованием при построении комплекса - например, идентичный сценарий диалога может формироваться как по умолчанию, так и с использованием команд системы. Поэтому в качестве первого из ограничений, накладываемых на структуру графа переходов, можно считать следующее: граф должен быть представим в виде управляющего графа, в котором разрешены параллельные ребра. Как отмечалось выше, с функциональной точки зрения оказывается удобным выделение в языке управления диалогом двух типов операторов: команд системы, сохраняющих одинаковый смысл в любой точке диалога, под- или микрокоманд, семантика которых определяется контекстом. При этом под- и микрокоманды определены только в рамках одной функциональной подсистемы - совокупности функциональных модулей, реализующих группу взаимосвязанных функций. При построении теоретико-графовой модели программного комплекса наличие двух типов операторов языка означает наличие на графе переходов ребер двух типов - соответствующих передачам управления между функциональными модулями по командам иди под- и микрокомандам. Важно отметить, что на полном графе переходов G могут быть выделены подграфы функциональных подсистем, для которых должно быть справедливо следующее: с учетом под- и микрокоманд данной подсистемы ее подграф графа переходов должен быть управляющим графом, с допустимыми на нем параллельными ребрами. Показать это можно повторением тех же рассуждений, что были приведены выше для графа G в целом: в соответствии с предложенным в предыдущем разделе способом разбиения системы на функциональные подсистемы в каждой подсистеме выделяется корневая программа входа в подсистему, из которой должен быть достижим каждый функциональный модуль (через под- и по микрокоманды). Дополнительны требованием, обеспечивающим удобство построения диалога в рамках функциональной подсистемы, является требование достижимости корневой программы из любого модуля подсистемы; с функциональной точки зрения это означает, что пользователь в любой момент может повторить выполнение функции сначала. Это означает, что корневой модуль подсистемы также должен являться ее выходом. Таким образом, сформулированные выше требования к структуре подграфов, соответствующим каждой подсистеме - второе ограничение структуры графа переходов. Наконец, еще одним требованием, обусловленным дисциплиной проектирования системы, является недостижимости любого функционального модуля подсистемы, за исключением корневого, извне подсистемы. Задача, для решения которой строится теоретико-графовая модель программного комплекса диалоговой АИПС заключается в проверке соответствия структуры создаваемого комплекса (как в процессе разработки, так и по ее окончании) перечисленным выше требованием. Наличие формируемых в процессе разработки формальных описаний взаимосвязей функциональных модулей позволяет автоматически обнаруживать дефекты создаваемой структуры, обусловленные погрешностями проектирования или ошибками на стадии реализации.
