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

Раздел включает обзор систем поддержки естественно-языкового интерфейса.

5.1. Введение в системы программирования

5.1.1. Основные понятия и определения

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

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

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

Этот минимум, позволяющий достаточно эффективно вести процесс создания программ, был представлен еще в начале 70-х годов XX века. Однако настоящую популярность такой интегрированный набор инструментов приобрел в середине 1980-х годов благодаря компании Borland Inc. (http://www.borland.com/). Пакет Turbo Pascal впервые появился в 1983 году для операционной системы СР/М, а в начале 1984 года был перенесен в MS-DOS. Практически все начало истории персональных компьютеров IBM PC связано с системой Turbo Pascal - наиболее популярной средой разработок.

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

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

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

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

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

5.1.2. История и эволюция

5.1.2.1. Некоторые важные даты

Вот некоторые вехи истории систем программирования.

1952 г. - Грейс Мюррей Хоппер (Grace Murray Hopper) разработала "А-О" - первый компилятор.
1957 г. - Джон Бэкус (John Backus) и его сотрудники установили в IBM первый компилятор языка FORTRAN.
1986 г. - Статья в Wall Street Journal сыграла большую роль в популяризации понятия CASE (Computer-Aided Software Engineering). На русский язык этот термин обычно переводится как "средства автоматизации разработки программ".

5.1.2.2. Основные этапы в формировании состава систем программирования

Можно выделить три основных этапа в формировании состава систем программирования.

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

5.1.2.3. История развития системы программирования компании Borland Inc. на базе языка Pascal

За особые заслуги компании Borland Inc. в области систем программирования приведем историю развития такой системы на базе языка Pascal.

1983 г. - Создание Андерсом Хейлсбергом (Anders Hejlsberg) программы Turbo Pascal для операционной системы СР/М.
1984 г. - Перенос Turbo Pascal в MS-DOS.
1990 г. - Представление Turbo Pascal для Windows.
1992 г. - Последний выпуск Borland Pascal версии 7.0.
1995 г. - Появление Delphi - доведенной до логического совершенства и кульминационного пика интегрированной среды Turbo Pascal.

5.1.3. Классификация

5.1.3.1. Классификация по ориентации на поддержку процессов

Начнем с основной классификации систем программирования, которая положена в основу структуры данной главы.

Инструментарий поддержки технологических процессов:

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

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

инструментальные среды программирования;
средства автоматизации разработки программ (CASE-средства);
интегрированные среды и репозитории проекта.

Инструментарий поддержки коллективной разработки.

5.1.3.2. Функциональная классификация

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

Рассмотрим четыре группы инструментов [Жоголев 1996].

Редакторы, поддерживающие конструирование (формирование) многочисленных программных документов.
Анализаторы, производящие:

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

Преобразователи, позволяющие:

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

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

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

5.1.3.3. Классификация по категориям

Классификация систем программирования по категориям [Калянов 1996] определяет уровень их интегрированности по выполняемым функциям и включает:

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

5.1.3.4. Классификация по предоставляемому интерфейсу

Системы программирования предоставляют два ярко выраженных типа программного интерфейса.

Интерфейс командной строки (Command Line Interface - CLI). Это традиционный интерфейс систем программирования в операционной системе Unix. В современных диалектах Unix практически все инструменты имеют и надстройку с графическим пользовательским интерфейсом.
Графический пользовательский интерфейс (Graphic User Interface - GUI). Этот интерфейс традиционен для систем программирования в Windows.

5.1.4. Проблемы и перспективы развития

Обстоятельства меняются, принципы нет.
О. Бальзак

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

Отечественные системы программирования и трансляторы характеризовалась в большей степени исследовательским уровнем, чем промышленным качеством [Поттосин 1995]. Отсутствие реального рынка и конкуренции программных продуктов привело к тому, что даже широко использовавшиеся трансляторы не соответствовали международным требованиям на программный продукт.

Часто может оказаться, что достаточно быстро разработать инструментарий для собственных нужд может практически любая команда. Любопытную и поучительную историю приводят в Интернете (http://progstone.nm.ru): "Одна команда пришла в волнение, когда они увидели инструменты, которые давали им все возможности для получения и просмотра перекрестных ссылок. Однако небольшие отличия между этими инструментами и набором скриптов, которые у них уже были, и на написание которых понадобилось одно утро, заключались в том, что:

инструменты нельзя было модифицировать;
инструменты стоили 20 000 фунтов стерлингов, плюс 5000 за каждое рабочее место;
инструменты требовали несколько недель на установку и настройку;
инструменты были с графическим интерфейсом.

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

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

проектирование и реализация инструментария, обеспечивающего кросс-платформенную разработку приложений на языках Java, С и C++ в средах ОС Unix и Windows NT;
разработка инструментария для эффективного написания программ, поддерживающих распределенные вычисления;
разработка высокопроизводительных систем программирования;
разработка средств отладки Интернет-приложений;
разработка инструментария с высоким уровнем абстракции для проектирования интерфейсов.

Упомянем и возможности, которые предлагает Интернет для доставки систем программирования до пользователя.

Пусть нам потребовался высокопроизводительный оптимизирующий компилятор с языка программирования C++ для SPARC-архитектуры. Два его наиболее удачных варианта.

Профессиональный коммерческий C++ компилятор компании Sun Microsystems Inc. (http://accessl.sun.com/).
Свободно распространяемый под General Public License (GPL) лицензией C++ (http://gcc.gnu.org/).

Интернет содержит достаточное количество ресурсов и для образовательных целей. Конечно, особый интерес для ВУЗов представляют свободно распространяемые программы. Многие учебные заведения используют язык Pascal для первоначального обучения программированию. В Интернете можно найти свободно распространяемые компиляторы с языка Pascal:

Free Pascal (http://www.freepascal.org/);
GNU Pascal (http://agnes.dida.physik.uni-essen.de/~gnu-pascal/).

Среди других доступны компиляторы с языков С, C++, Eiffel, Lisp, Clos, FORTRAN и многие другие.

5.1.5. Рекомендации по литературе

Читайте книги - некоторые из них специально для этого написаны.
Михаил Генин

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

Следующие книги:

"Теория синтаксического анализа, перевода и компиляции" [Ахо, Ульман 1978] и "Компиляторы: принципы, технологии и инструменты" [Ахо, Сети, Ульман 2001], содержащие теоретические основы конструирования компиляторов;
"Конструирование компиляторов для цифровых вычислительных машин" [Грис 1975], в которой рассматриваются практические вопросы реализации компиляторов;
"Как Паскаль и Оберон попадают на "Самсон", или искусство создания трансляторов" [Кожохарь, Евстюнин, Терехов, Уфнаровский 1992], в которой приведены примеры практически готовых трансляторов для отечественной ЭВМ "Самсон";
"Языки и методы программирования в системе "Эльбрус" [Сафонов 1989], в которой приведены практические сведения об использовании систем программирования, реализованных на вычислительных комплексах "Эльбрус";
"Текущее состояние российских исследований и разработок в области трансляции" [Поттосин 1995]. Эта работа дает представление об отечественных разработках последних лет и содержит ссылки на российские коллективы и центры, занимающиеся разработкой систем программирования.

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

5.2. Процесс-ориентированный инструментарий

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

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

5.2.1. Возникновение и исследование идеи

Вдохновение нужно в поэзии, как и в геометрии.
Александр Сергеевич Пушкин

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

Поисковые информационные системы. Эти системы по сделанному запросу выдают ссылки на найденные документы. Подробно такие системы будут рассмотрены в разд. 5.3.6. Наиболее известными поисковыми системами являются:

поисковые системы общего назначения (например, Яndex (http://www.yandex.ru) и Google (http://www.google.com));
тематические каталоги Интернета (например, Yahoo (http://www.yahoo.com));
базы данных патентов в Интернете (например, Questel-Orbit (http://www.questel.orbit.com));
индексы цитирования научных статей (например, Researchlndex (http://www.citeseer.nj.nec.com/cs)).

Системы поиска решений. Эти системы представляют собой структурированный набор разнообразного рода эвристических приемов и методов (http://www.triz.minsk.by/index0.htm). Они объединяют предшествующий опыт различных авторов и коллективов и должны способствовать увеличению количества рождающихся идей.

5.2.2. Управление

Сильный действует рукой, мудрый - умом, а хитрый - кем-то еще.
Владислав Гжегорчик

Инструментарий поддержки процесса управления разделим на три группы.

Системы управления проектами.
Организационные средства.
Средства оценки качества.

5.2.2.1. Системы управления проектами

Перечислим группы средств, предназначенных для управления проектами:

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

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

Подробную информацию о системах управления проектами, включающую описание их характеристик, можно получить в Интернете (http://www.aproject.ru/tools/tools.html). Перечислим ряд наиболее интересных систем:

Microsoft Project (компании Microsoft (http://www.microsoft.com/office/project/default.htm)) - самая распространенная в мире на сегодняшний день система, которая может быть рекомендована для планирования несложных проектов. Пакет достаточно прост, имеет традиционные средства помощи и удобные инструменты создания отчетов;
система Time Line (компании Time Line, Inc. (http://www.timeline.com)) - также предназначена для несложных проектов. Содержит минимально необходимые функции управления проектами;
Primavera (компании Primavera Systems, Inc. (http://www.primavera.com)) - более мощная система, применяемая для управления средними и крупными проектами.

5.2.2.2. Организационные средства

К организационным средствам относятся:

электронная почта;
электронный календарь;
интранет.

Электронная почта

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

Электронный календарь

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

Интранет

Термином интранет обозначают корпоративные информационные системы, построенные на принципах, заимствованных из сети Интернет. По сути, интранет - это перенос хорошо известных сетевых технологий во внутрикорпоративные сети. Внутренняя сеть позволяет создать целостный портрет организации и обрести радикально новую систему внутренних коммуникаций и доступа к информационным ресурсам. Интранет может быть значительно "умнее" Интернета, потому что он контролируем, и в него можно инвестировать значительно больше знаний и средств. В качестве серверов итранета можно использовать хорошо известные серверы Интернета, например Apache (http://www.apache.org).

5.2.2.3. Средства оценки качества

Для сравнения качества программных продуктов применяются количественные методы оценки. Среди программ оценки качества отметим Metricate компании Software Productivity Centre (http://www.spc.ca)), которая анализирует все аспекты деятельности компаний по производству программного обеспечения. Это - эффективность технологических процессов, качество программного кода, уровень управления проектами, стоимость выполнения различных этапов, производительность получаемой системы, продуктивность труда разработчиков и качество готовых изделий.

5.2.3. Анализ требований и проектирование

5.2.3.1. Системы на основе структурной методологии

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

Silverrun ModelSphere (компании magma solutions GmbH (http://www.spc.ca)) - поддерживает методы DATARUN, Гейна-Сарсона, Йордона, Мартина и др.;
Oracle Designer (компании Oracle (http://www.oracle.com)) - поддерживает CASE*Method Баркера;
ERwin (компании Computer Associates International, Inc. (http://www.cai.com)) - поддерживает диаграммы функционального моделирования.

О системах на основе структурной методологии
Обратим внимание, что практически все перечисленные системы в настоящее время поддерживают также и объектно-ориентированную методологию.

Из отечественных систем укажем следующие:

ДРАКОН - поддерживающая ДРАКОН-схемы [Паронджанов 1999];
CASE-Аналитик (компании Эйтекс) - поддерживающая подход Гейна-Сарсона. Система работает с иерархией диаграмм, последовательно детализирующих модель (рис. 5.1).

В состав системы САSЕ.Аналитик входят [Калянов 1996]:

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

5.2.3.2. Системы на основе объектно-ориентированной методологии

Укажем лучшие и наиболее известные системы для анализа требований и проектирования на основе объектно-ориентированной методологии:

Rational Rose (компании Rational Software Corporation (http://www.rational.com));
Together Control Center (компании TogetherSoft Corporation (http://www.togethersoft.com)).

Перечислим основные достоинства и возможности системы Rational Rose:

система прошла достаточно долгий путь развития и совершенствования. Она поддерживает язык UML и ряд ранних языковых нотаций (например, Воосh и ОМТ (Object Modeling Technique));
система реализована на обеих наиболее распространенных операционных системах - Unix и Windows;
система имеет три основные модификации. Пользователь имеет возможность выбрать одну из них, устраивающую его по финансовым соображениям:

Enterprise - с возможностью генерации кода на языках Visual C++, Visual BASIC, Java, CORBA IDL Еще совсем недавно существовала поддержка языка Smalltalk;
Professional - возможность генерации кода на одном из перечисленных языков;
Modeler - без языковой поддержки;

система поддерживает восстановление спецификаций из кода;
система поддерживает генерацию проектной документации.

Система обладает удобным рабочим интерфейсом, в который входят:

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

5.2.4. Программирование (реализация)

5.2.4.1. Трансляторы

Диван был транслятором. Он создавал вокруг себя поле, преобразующее,
говоря просто, реальность действительную в реальность сказочную.
Аркадий и Борис Стругацкие. "Понедельник начинается в субботу"

Транслятор - программный инструмент, предназначенный для перевода (трансляции) программ с одного формального языка на другой. Существует несколько основных видов трансляторов:

компиляторы;
декомпиляторы;
интерпретаторы.

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

Обратим внимание на то, что многие другие программные инструменты могут рассматриваться как языковые трансляторы, например:

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

5.2.4.2. Компиляторы

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

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

Далее мы расскажем об основных программах, входящих в состав компилятора. В сети Интернет подробный обзор таких программ можно найти на сайте Compiler Construction Tools (http://catalog.compilertools.net).

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

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

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

5.2.4.3. Системы генерации трансляторов

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

С точки зрения существующих алгорифмов синтаксического анализа, все языки и порождающие их грамматики делятся на два класса LL(n) и LR(n). Этот теоретический раскол в классе грамматик, распознаваемых анализаторами, построенными по принципу снизу вверх, и анализаторами, реализующими принцип сверху вниз, естественным образом наложил свой отпечаток и на практические реализации систем. В результате существуют системы с входными языками, специфицируемыми LR(n) и LL(n) грамматиками соответственно. Исторически первой системой, реализующей синтаксически управляемую трансляцию, была система уасс, входной язык которой принадлежит к классу LR(1) или, более точно, LALR(1). Система уасс, разработанная в 1972 году в рамках проекта Unix, успешно используется до сих пор, что, конечно, не может не свидетельствовать в пользу простоты и мощности идей, положенных в ее основу.

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

BISON - реализация уасс, написанная в рамках проекта GNU (http://www.gnu.org/software/bison/bison.html);
PCYACC (компании Abraxas Software (http://www.abxsoft.com/pcyacc.htm)). Это коммерческая реализация уасс, включающая в себя различные утилиты, упрощающие процесс разработки трансляторов. Среди них: документатор, отладчик, библиотекарь и т. д. В поставку включены спецификации грамматик многих современных языков программирования (С, C++, SQL и т. д.);
Yacc++ (компании Compiler Resources, Inc. (http://world.std.com/~compres/)). Это расширение, целиком и полностью построенное на идеях объектно-ориентированного программирования. На выходе этой системы пользователь получает полноценную иерархию классов, реализующих трансляцию со специфицированного языка.

Естественное желание разработчиков пользоваться давно написанными средствами, прошедшими не один год тестовых испытаний в реальных проектах, отрицательно сказалось на количестве систем, транслирующих входные языки класса LL(n), т. е. реализующих двойственный подход к проблеме. Тем не менее, в рамках некоторых учебных проектов, а также в рамках проекта "Оберон" был создан ряд таких систем. Среди них следует отметить:

SYNTAX - технологический комплекс, созданный в Санкт-Петербургском государственном университете под руководством профессора Б. К. Мартыненко (http://www.niimm.spb.su/~mbk/syntax/syntax.html).

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

DEPOT4 (авторская разработка Юргена Лампе (Jurgen Lampe) (http:// www.math.tu-dresden.de/wir/depot4/depot4.html)). Это система, генерирующая трансляторы, работающие по принципу рекурсивного спуска. При этом допускается возможность регулированного отката при обнаружении неоднозначностей. Таким образом, при наличии требования на отсутствие левой рекурсии в правилах грамматики сама грамматика может быть и не LL(1). Естественно, что чем ближе грамматика к классу LL(1), тем более быстрый транслятор можно будет с нее получить;
LLGEN (является частью большого учебно-коммерческого проекта, известного под названием Amsterdam Compiler Kit - АСК (http://www.cs.vu.nl/vakgroepen/cs/ack.html)). Она также генерирует трансляторы, работающие по принципу рекурсивного спуска.

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

ALE - Attribute-Logic Engine (авторская разработка Боба Карпентера (Bob Carpenter) и Джеральда Пенна (Gerald Penn) (http://www.cs.toronto.edu/~gpenn/ale.html)). Система, базирующаяся на принципах искусственного интеллекта;
EAG (ftp://hades.cs.kiin.nl/pub/eag/). Система, в основе которой лежат расширенные аффиксные грамматики;
PRECC (авторская разработка Питера Брюера (Peter Breuer) и Джонатана Боуена (Jonathan Bowen) (http://www.afm.sbu.ac.uk/precc/)). Это система, позволяющая грамматике входного языка быть контекстно-зависимой.

5.2.4.4. Системы анализа корректности программного кода

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

lint (компании Sun Microsystems, Inc. (http://www.sun.com)) для языка программирования С;
PC-lint и FlexeLint (компании Gimpel Software (http://www.gimpel.com)) анализируют программный код на языках С и C++.

5.2.4.5. Интерпретаторы

Не существует фактов, есть лишь их интерпретация.
Ф. Ницше

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

5.2.4.6. Декомпиляторы

Декомпилятор - программа, позволяющая по программе на языке низкого уровня (обычно это коды некоторой машины) получить программу на высокоуровневом языке, в некотором смысле ей эквивалентную. Под эквивалентностью чаще всего понимают эквивалентность внешних проявлений работы исходной программы и декомпилированной (http://www.it.uq.edu.au/groups/csm/dcc.html).

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

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

Теория анализа потоков управления появилась давно, т. к. анализ активно применялся в компиляторах практически с момента их появления. Однако анализ потоков управления при компиляции имеет свою специфику - он используется в основном для целей оптимизации. Большинство алгоритмов анализа потоков управления, которые ориентированы на декомпиляцию, ставят своей целью уменьшение количества goto-выражений посредством введения новых логических переменных, дублирования кода (code replication) или использования конструкций высокого уровня, недоступных в большинстве широко используемых языков, таких как Pascal, С или C++.

В работах Кристины Цифуентес (Cristina Cifuentes) (http://www.itee.uq.edu.au/~cristina) представлены алгоритмы, использующие минимальный набор инструкций высокого уровня: циклы типов while и do...while, if- и case-выражения. Управление выполнением объемлющих конструкций из вложенных не допускается. Причем эти алгоритмы используют оператор goto лишь тогда, когда граф управления не может быть структурирован никаким иным способом в пределах перечисленных конструкций.

Анализ практических достижений в области декомпиляции языка Java выполнил Дэйв Дайер (Dave Dyer) (http://www.javaworld.com). Он сравнил между собой три наиболее известных к середине 1997 года декомпилятора: DejaVu, Mocha и WingDis. Дайер предложил систему тестирования декомпиляторов, основанную на интересной классификации допускаемых ими ошибок. В соответствии с этой системой все ошибки делятся на шесть категорий. "Тяжесть" ошибки возрастает с номером категории. Ошибки, в результате которых декомпилированная программа перестает собираться, но которые могут быть легко исправлены (например, отсутствие явного приведения типов там, где оно с очевидностью должно быть), относятся к первой, самой легкой категории, тогда как генерация правильного, но нечитаемого текста на Java считается ошибкой третьей категории. Заметим, что некоторые ошибки, проявляясь у одних декомпиляторов, полностью отсутствуют у других. Это свидетельствует о жизнеспособности такой классификации - она позволяет определить области, в которых одни декомпиляторы имеют преимущество над другими.

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

Mocha и Crema входят в состав программного продукта Jbuilder компании Borland Inc. (http://www.borland.com));
Source Tee Java Decompiler (компании SourceTee Software Co. (http://www.srctec.com/decompiler/));
Jad (авторская разработка Павла Кузнецова (http://www.sai.msu.su/sal/F/1/JAD.html)).

5.2.4.7. Усложнители декомпиляции (шифраторы, обфускаторы)

Практические успехи в области декомпиляции языков программирования (и особенно языка Java) оказались столь велики, что в последнее время были проведены значительные исследования в области защиты программ от декомпиляции (http://www.cs.washington.edu/homes/douglas/publish/). Существует специальный класс программ (шифраторов, обфускаторов), усложняющих декомпиляцию. Такие программы используют два основных подхода.

Общее (универсальное) усложнение.
Целенаправленное усложнение (направленное против конкретного декомпилятора).

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

5.2.4.8. Системы управления компиляцией и построением программ

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

make (компании Sun Microsystems Inc. (http://www.sun.com)) входит в состав операционной системы Solaris;
GNU Make (организации Free Software Foundations (http://www.gnu.org/software/raake/make.html));
Jmk - Make in Java (общинная разработка (http://sourceforge.net/projects/NO).

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

Файл с инструкциями имеет свой синтаксис.

Строка комментариев начинается с символа диез #.
Пустые строки игнорируются.
Любая строка, оканчивающаяся символом обратная наклонная черта \, продолжается на следующую строку. Все символы пробела и табуляции вокруг наклонной черты сжимаются в один символ пробела.
Если строка выглядит следующим образом <цель>: [<зависимости>], то это означает, что цель определяется зависимостями и соответственно для того, чтобы добиться выполнения целей, необходимо выполнить зависимости.
Строка, идущая за строкой с указанием цели, должна иметь вид <пробел_или_табуляция> <команда>. Указанная команда будет передана командному интерпретатору в случае, если цель нуждается в обновлении.
Команда [<пробел_или_табуляция>] <имя> = <значение> позволяет изменнять значение переменной. Любая строка, содержащая знак равенства, является макроопределением. Такая строка связывает строку <значение> с именем <имя>.
Любое слово в файле описаний, начинающееся с символа $, является использованием макроопределения. Включенное в любом месте файла описание $ (<имя>) будет заменено на его существующее макроопределение. Если <имя> является одиночным символом, то разрешено использование макроопределения в упрощенном виде $<имя>.
Некоторые макроопределения являются предопределенными. Они могут использоваться только в правой части строки правила, в других макроопределениях и в строках команд. Приведем примеры предопределенных макроопределений:

$@ - означает полное имя текущей цели;
$* - имя текущей цели с отброшенным типом файла (суффиксом);
$? - список зависимостей, которые обновились с момента предыдущего получения цели;
$< - полное имя исходного файла, к которому применяется правило трансформации.

Обычно существует некоторая база предопределенных правил суффиксов и динамических макроопределений. Они являются правилами по умолчанию для стандартного получения результирующих файлов по исходным файлам. Все они сведены в специальный файл. Например, правило трансформации .cc.о определяется как $(COMPILE.cc) $(OUTPUT_OPTION) $<. Это означает, что для того, чтобы получить файл .о (если есть .сc), надо выполнить указанную команду. Динамическое макроопределение $ (COMPILE.сс) определяется в той же базе как $(ссс) $(CCFLAGS) $ (CPPFLAGS) -с.

Пример файла с инструкциями приведен в листинге 5.1. Именование каталогов дано в стиле операционной системы Unix.

Листинг 5.1. Пример файла с инструкциями для утилиты make

BASE_DIR = /usr

BIN_DIR = $(BASE_DIR)/bin

LIB_DIR = $(BASE_DIR)/lib

# В результате такого описания получится, что значение
# переменной BIN_DIR стало равным /usr/bin, a LIB_DIR - /usr/lib.

OBJS = main.о classa.o classb.o

LIBS = libCstd.a libCrun.a

main: clean $(OBJS)

$(CCC) -o $@ $(OBJS) -L $(LIB_DIR) $(LIBS)

# Разыменование переменной ССС, которая у нас не присутствует,
# но может присутствовать в окружении.
# Использование $@ после параметра -о приводит к тому, что результирующий файл будет
# называться тоже main.

clean:

rm -f *.o main core

# Удаление всех объектных файлов и core-файла, который может быть
# создан в результате некорректного завершения предыдущей компиляции.

classa.o: classa.h

# Указывает зависимость - т. е. когда будет изменен файл classa.h,
# файл classa.o потребует перекомпиляции.

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

-n - только печатать команды, не исполняя их. То есть если make примет решение на исполнение команд, то система, не передавая их интерпретатору команд, напечатает их на экране;
-p - напечатать все макроопределения. То есть после разбора файла определений (makefile) напечатать все найденные там определения макросов и продолжить работу;
-s - не печатать команды. Без указания этой опции make при передаче команд интерпретатору команд печатает их на экран;
-m - обновить только цель. С этой опцией make, произведя разбор файла определений, выполняет только команды, необходимые для обновления главной цели, и никаких других команд в интерпретатор команд более не передает. Причем команды для обновления главной цели выполняются обязательно, вне зависимости от необходимости.

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

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

5.2.5. Тестирование и отладка

Заблуждения, заключающие в себе некоторую долю правды, самые опасные.
Адам Смит

Мы будем изучать вместе инструментарий, применяемый как на этапе тестирования, так и на этапе отладки. Очень часто оказывается, что один и тот же инструмент может указать на факт наличия ошибки, одновременно локализовать место ее возникновения и указать причину. Большая часть инструментов связана с технической стороной вопроса (http://www.softwareqatest.com/qatweb1.html).

5.2.5.1. Тестовые мониторы

Тестовый монитор состоит из трех основных компонентов.

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

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

5.2.5.2. Средства отслеживания тестового покрытия

Системы такого типа предназначены для выявления тестового покрытия программы, в том числе участков кода, пропущенных при тестировании.

Важную роль здесь играет понятие линейного участка - фрагмента программы, на протяжении которого нет передачи управления. Если выполняется первый оператор такого участка, то будут выполнены и все остальные. Часто данные системы используют в качестве вспомогательного средства профайлер (см. разд. 5.2.5.3).

Примеры систем:

Rational PureCoverage (компании Rational Software Corporation (http://www.rational.com));
Java Test Coverage and Instrumentation Toolkits (компании Glen McCluskey & Associates LLC (http://www.glenmccl.com)).

5.2.5.3. Средства динамического построения профиля программы

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

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

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

prof (компании Sun Microsystems Inc. (http://www.sun.com));
gnuprof (организации Free Software Foundations (http://www.gnu.org));
ProDelphi (авторская разработка Гельмута Адольфа (Helmuth Adolph) (http://www.prodelphi.de)).

5.2.5.4. Системы построения срезов программы

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

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

Причины возникновения данного направления очевидны. При работе с исходным текстом программы часто необходимо проследить формирование значения некоторой переменной. Это особенно актуально. при отладке и. сопровождении программ. В этом случае получение среза приносит существенное облегчение работы, поскольку резко снижается объем исследуемого кода. Предположим, что во время тестирования мы установили, что некоторая переменная в некоторой позиции содержит неверное значение. Получив соответствующий срез, мы локализуем проблему. В дополнение к сказанному, срезы позволяют разбить большую программу на небольшие компоненты. Это способствует более простому пониманию смысла программы, что очень актуально при сопровождении программных продуктов. Впоследствии часть этих компонентов может быть использована при создании новой программы. Бадгер и Вейзер продемонстрировали [Badger, Weiser 1988], как срезы могут быть использованы для автоматической параллелизации. Однако основной областью применения срезов остается отладка и сопровождение программ.

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

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

Практически все существующие методы вычисления динамического среза рассчитаны на работу с программами, написанными в стиле структурного программирования. Бол и Хорвиц [Ball, Horwitz 1993] предложили подход для вычисления статических срезов для неструктурированных программ, модифицировав понятие зависимости по контролю для данного случая.

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

5.2.5.5. Отладчики

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

Кроме классических отладчиков существуют еще несколько групп инструментов.

Средства динамической отладки распределения памяти — специальный инструментарий, позволяющий анализировать распределение памяти в процессе исполнения программы.
Средства отладки многопоточных и параллельных приложений. Это те приложения, которые в некоторой точке могут разветвиться для выполнения параллельной работы, потом попадают в точку ожидания и опять выполняются последовательно. Примеры — средства компании Sun Microsystems Inc. (http://www.sun.com):

thd (Thread Analiser) — нитевой анализатор, который исполняется для того, чтобы отслеживать многопоточные приложения;
locklint - анализатор корректности взаимных исключений;
looptool - анализатор распараллеливания программ.

5.2.5.6. Системы отслеживания проблем (ошибок)

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

основная информация об ошибке:

номер ошибки;
краткое описание проблемы;
ключевые слова;
приоритет;
состояние;

место проявления ошибки:

программный продукт;
версия продукта;
компонент;
особенность;

персоналии:

ответственный менеджер;
ответственный инженер;
инженер, выставивший ошибку;
адреса рассылки;

анализ ошибки и исправление:

подробное описание ошибки;
тест, на котором проблема проявляется;
предлагаемое исправление;
комментарии;
информация для пользователей;

влияние исправления:

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

Примерами систем отслеживания проблем являются:

Bugzilla, применяемая для сбора информации об ошибках гипертекстового браузера Mozilla (http://bugzilla.mozilla.org);
Open Source Web Browser (авторская разработка Адама Сигеля (Adam Siegel) (http://www.asgtools.com/products/bt.html)).

5.2.6. Ввод в действие

Основная группа систем данного процесса - это системы инсталляции. Укажем самые популярные инсталляторы для операционной системы Windows (http://www.softshape.com/swrus/faq_swrus.html):

MindVision's Installer VISE - мощнейший профессиональный инсталлятор, используемый даже крупными корпорациями;
WISE - известен самым маленьким размером получающегося дистрибутива. Имеет богатый язык скриптов;
InstallShleld Professional/Express - старейший продукт, обладающий всеми необходимыми возможностями для создания сколь угодно сложных сценариев установки;
CreateInstall - простой, легкий в освоении и компактный инсталлятор.

5.2.7. Сопровождение

Можно выделить следующие основные группы инструментов, используемых при сопровождении программ:

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

5.2.8. Завершение эксплуатации

Основная группа систем данного процесса - это системы деинсталляции. Такие системы выполняют действие, обратное действию инсталляции, и, как правило, входят в инсталляционный пакет.

5.3. Универсальный инструментарий

Напомним, что в этом разделе под универсальностью инструментария будем понимать возможность его применения в нескольких процессах

5.3.1. Инструменты работы с текстом

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

5.3.1.1. Средства, базирующиеся на регулярных выражениях

Развитыми средствами определения шаблонов и осуществления поиска являются средства семейства grep в операционной системе Unix. Как grep, так и egrep могут искать участки текста, используя регулярные выражения. Наряду со специальными утилитами используются механизмы, встроенные в некоторые языки обработки текстов, например Perl (http://www.perl.org).

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

Написание конкретного шаблона для поиска в исходном тексте может быть затруднительным, а иногда и невозможным. Например, пусть требуется локализовать два последовательных оператора цикла: цикл типа for, следующий за циклом типа while, причем оба с произвольными условиями и блоками операторов, на одном и том же уровне вложенности. Возможная спецификация для grep может быть такой: .*while.*for. Однако такая спецификация grep отыщет не только последовательные операторы цикла, но и вложенные. Дополнительно будут найдены такие последовательные операторы, которые непосредственно не следуют друг за другом. Кроме того, оба требуемых ключевых слова могут оказаться в комментарии.
Вторая проблема, связанная с использованием grep, заключается в написании шаблонов для отыскания деклараций. Рассмотрим написание шаблона для поиска декларации целой переменной х и символьной с. Поскольку порядок деклараций на одном и том же уровне вложенности в большинстве случаев не столь важен, они могут оказаться в любом порядке в исходном тексте. Поэтому для отыскания, например, двух деклараций с помощью регулярных выражений надо применять конструкцию такого вида: (.*int[ ]*x[ ]*;.*char[ ]*c[ ]*;) | (.*char[ ]*c[ ]*;.*int[ ]*x[ ]*;). Сложность же такой спецификации для более чем двух отыскиваемых деклараций очевидна. Если в исходном тексте была декларирована инициализированная целая переменная (int x=0;), то поиск для нее окажется неудачным в любом случае.
Третья проблема, которая может возникнуть при использовании средств семейства grep, связана со специальными символами. Обычно эти средства воспринимают символ "новая строка" как разделитель даже тогда, когда мы ищем выражение в многострочном контексте. Это особенно мешает поиску в исходном тексте, поскольку зачастую предмет поиска охватывает несколько строк. К тому же необходимость постоянно учитывать разделители (пробелы, символы "новая строка", символы табуляции) затрудняет составление регулярных выражений.

Регулярные выражения для поиска по шаблонам используются в утилитах ed, sed, awk и perl:

ed и sed являются текстовыми преобразователями. Они позволяют находить и заменять фрагменты, базируясь на регулярных подвыражениях (в случае sed - многострочных). Они тоже воспринимают входной текст как поток символов, что некорректно;
awk воспринимает входной текст как набор записей, и, несмотря на то, что это уже более подходящая абстракция, нежели символ, она все же не адекватна в применении к программному тексту. Семантически разные части могут оказаться в одной записи. Например, for (i=0;i<5,-i++) { - это все одна запись;
perl, в частности версии 5, обладает более широким механизмом регулярных выражений, но даже и они остаются не столь удобными для поиска в исходном тексте программы, поскольку не учитывают его особенности.

5.3.1.2. Средства поиска различий

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

Примеры таких систем:

diff (компании Sun Microsystems Inc. (http://www.sun.com)) входит в состав операционной системы Solaris;
GNU diff (организации Free Software Foundations (http://www.gnu.org/software/diff/diffutils/)) представляет собой совокупность нескольких утилит:

diff - основная утилита для нахождения различий между двумя файлами;
cmp - утилита, выдающая информацию о номерах строк, в которых в файлах есть различия;
diff3 - утилита, находящая различия между тремя файлами;
sdiff - утилита для интерактивного объединения двух файлов в один.

5.3.1.3. Средства поиска на основе шаблонов

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

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

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

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

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

Запросы могут быть следующих типов:

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

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

Найти все операторы цикла while, в которых происходит сравнение какого-нибудь выражения на неравенство его нулю. Запрос будет выглядеть так: while (# != 0) @. На основе данного запроса система производит поиск всех операторов while, удовлетворяющих вышесказанному условию, на любом уровне вложенности. Знак # - это шаблон для произвольного выражения, а @ - шаблон для произвольного оператора. Такой запрос может оказаться полезным, если необходимо выявить все конструкции в программе с таким условием, с целью их замены на while (#) @.
Найти все вхождения трех подряд идущих операторов if. Запрос будет выглядеть так: if (#) @ if (#} @ if (#) @. Целью такого запроса может стать локализация потенциальных кандидатов на преобразование последовательных операторов if в оператор switch.
Найти все вхождения оператора if, где в качестве условия возможно ошибочное использование оператора присваивания = вместо равенства ==. Запрос будет выглядеть так: if (# = #) @. Целью такого запроса может стать локализация часто встречающейся ошибки в коде на языке С, когда в выражениях сравнения используется оператор присваивания.
Найти последовательности операторов, в которых три или более операторов if встречаются подряд, причем возможно их разделение другими операторами. Запрос будет выглядеть так: if (#) @ @* if (#) @ @* if (#) @. Целью такого поиска может стать локализация участков с большой цикломатической сложностью - в данном примере имеется восемь различных путей управления через данную последовательность операторов.

5.3.1.4. Обозреватели и базы данных программ

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

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

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

Omega [Linton 1984];
CIA [Chert, Nishimoto, Ramamoorthy 1990] и CIA++ [Grass 1992];
Microscope [Ambras, O'Day 1987].

5.3.1.5. Средства обнаружения плагиата

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

В работе (http://www.iam.unibe.ch/~scg/) представлено средство обнаружения повторяющихся участков кода. В нем используется техника абстракции от языка. Это осуществляется с помощью подхода, названного авторами визуализацией кода. Он основан на первоначальном преобразовании кода к удобному для дальнейшего исследования виду. Данный подход базируется на преобразовании текста, а не на синтаксических сущностях.

5.3.1.6. Текстовые редакторы

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

Строковые редакторы, позволяющие смотреть и редактировать текст только на одной строке. При этом текст воспринимается как последовательность строк, разделенных символом "конец строки".
Потоковые редакторы, позволяющие воспринимать текст в виде потока символов. При этом признаки конца строки также являются символами.
Экранные редакторы, позволяющие перемещать по тексту окно, в котором можно передвигать курсор и устанавливать его в нужные позиции. Многие экранные текстовые редакторы позволяют видеть на экране текст в том виде, в котором он будет напечатан (концепция What You See Is What You Get - WYSIWYG).

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

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

Редакторы для составления программ могут учитывать синтаксическую структуру обрабатываемой программы и выполнять дополнительный анализ и проверку (см. разд. 5.3.1.7).

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

Microsoft Word (компании Microsoft (http://www.microsoft.com)) в операционной системе Windows и аналогичный ему по возможностям редактор StarOffice (компании Sun Microsystems Inc. (http://www.sun.com/staroffice/)) в Unix;
Биллом Джоем (Bill Joy) был разработан полноэкранный текстовый редактор для Unix - vi. Этот редактор до сих пор является одним из самых используемых стандартных текстовых редакторов на компьютерах с операционной системой Unix.

5.3.1.7. Синтаксически-ориентированные редакторы

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

предоставление пользователю возможности редактирования текста на уровне смысловых конструкций используемого языка;
избавление пользователя от необходимости детально знать правила записи конструкций языка программирования;
ускорение ввода программы за счет подстановки языковой конструкции целиком при нажатии одной функциональной клавиши;
ведение непрерывного контроля правильности программы, включая синтаксис и полную статическую семантику;
обеспечение автоматического форматирования текста программ и ее просмотра в удобном режиме. Примеры синтаксически-ориентированных редакторов:
EMACS (организации Free Software Foundations (http://www.gnu.org/software/emacs/)) - редактор, в основе которого лежит LISP-система;
MENTOR - исторически первая система структурного редактирования;
ALOE - генератор структурных редакторов в рамках проекта GANDALF.

5.3.1.8. Гипертекстовые средства

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

Linux Cross-Reference - LXR (http://lxr.linux.no) - было создано как средство просмотра ядра операционной системы Linux;
Mozilla Cross-Reference (http://lxr.mozilla.org) - средство просмотра исходных текстов браузера Mozilla;
FreeBSD Unix Cross-Reference (http://lxr.linux.no/freebsd/source/) - средство просмотра текстов операционной системы FreeBSD Unix.

5.3.2. Системы документирования

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

javadoc (компании Sun Microsystems, Inc. (http://www.sun.com)) - генератор документации Java. Он считывает исходные тексты программ на языке Java, ищет комментарии специального вида и сопоставляет их с классами и методами, которые они описывают. Собрав все элементы, генератор придает им вид HTML-структуры и сохраняет в виде файла. Комментарии для генератора похожи на блочные комментарии в языке С, но имеют две звездочки после первой наклонной черты. Существует несколько ярлыков - символов, имеющих специальное значение (например, знак @). Так, комбинация символа и слова - @author заставит программу использовать специальные команды HTML, выделяющие имя автора в программе;
ToolBook - инструментальная система разработки информационных приложений, создания гипермедиа-приложений (электронной документации, словарей, справочников и энциклопедий) и интерактивных обучающих программ. Отличительная особенность данной системы - использование метафоры книги в качестве основы создаваемых приложений. Приложение называется книгой, состоит из страниц и обладает всеми свойствами Windows-приложений [Смирнов, Керов, Дерюшев 1998].

5.3.3. Системы разработки интерфейсов

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

C++ Visual Studio (компании Microsoft (http://www.microsoft.com));
C++ Workshop Visual (компании Sun Microsystems (http://www.sun.com));
Delphi Suite (компании Borland Inc. (http://www.borland.com));
средства построения графического интерфейса в Java (компоненты и контейнеры).

5.3.4. Системы управления базами данных

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

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

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

По типу поддержки модели данных различают несколько классов СУБД:

реляционные СУБД;
объектные СУБД;
логические СУБД.

Значительно менее популярными в настоящее время являются СУБД, поддерживающие модели данных: иерархическую, сетевую, плоский файл, реляционную с вложенностью, семантическую и многомерную.

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

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

Дейт [Дейт 2000] утверждает, что "и с экономической, и с теоретической точки зрения можно сказать, что реляционный подход наиболее важный (и это положение дел, по-видимому, не изменится в обозримом будущем)". Вот некоторые наиболее известные реляционные СУБД:

DB2 (компании IBM (http://www-4.ibm.com/software/data/));
Oracle (компании Oracle (http://www.oracle.com));
Access (компании Microsoft (http://www.microsoft.com)).

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

POSTGRES (создана в университете Беркли (http://db.cs.berkeley.edu));
Starburst (компании IBM (http://www.research.ibm.com)).

5.3.5. Системы управления базами знаний и экспертные системы

5.3.5.1. Системы искусственного интеллекта

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

Искусственный интеллект (artificial intelligence) - одна из областей информатики, направленная на моделирование и решение задач, связанных с обработкой символьной информации, логикой и естественным языком. [Нильсон 1985]. Искусственный интеллект ставит перед собой и более серьезную задачу построения теории интеллекта, базирующуюся на обработке информации. Отдельные ветви этой области касаются психологии, философии и лингвистики. Базы знаний и экспертные системы - два наиболее известных типа систем, связываемых с искусственным интеллектом.

К системам искусственного интеллекта можно предъявить различные требования (http://asu.pstu.ac.ru/structure/prepod/solov.htm).

Работа с неполной и неточной информацией. Системы должны поступать "как крутой детектив". На основе неполной и неточной информации они разрабатывают первый вариант алгоритма, который потом совершенствуется на основе новой информации, получаемой системой.
Понимание плохоформализуемого. Системы должны быть "как кулинарная книга". Например, "добавить по вкусу", "варить до готовности" и т. п.
Самообучение. Системы должны не только хранить закономерности, но и показывать - как они используются при поиске решения. Например, при конструировании электрического стула система должна найти закон Ома и использовать его в расчетах.
Понимание смысла вопроса. Например, на вопрос "Вы не скажете, который час?" в некоторых случаях вполне разумным будет ответ "Меня зовут Лена".
Наличие возможности обучения и объяснения. Системы должны "напоминать толмача". Они должны иметь возможность обучения и объяснения. Например, будет полезнее, если система в области медицины на вопрос о наиболее эффективном лечении подробно объяснит, "что с такой болезнью давно пора помирать", вместо того чтобы прописывать цианистый калий.

5.3.5.2. Механизмы выводов на знаниях

Жизнь - это искусство делать верные выводы из неверных посылок.
С. Батлер

Под механизмом вывода в экспертных системах будем понимать ту часть экспертной системы, в которой содержатся общие знания о схеме управления решением задач. Машина вывода выполняет две основные функции [Гаврилова, Хорошевский 2001].

Просмотр существующих фактов из рабочей памяти (базы данных) и правил из базы знаний и добавление в рабочую память новых фактов.
Определение порядка просмотра и применения правил.

В зависимости от проблемной области (пространства поиска), будем классифицировать выводы следующим образом:

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

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

Перечислим основные типы выводов на знаниях.

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

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

О практическом применении метода резолюций
Следует заметить, что метод резолюций используется в так называемых языках логического программирования. Например, на языке Prolog запись программы будет близка к записи в стандартной форме.

Обратный вывод Маркова. В этом методе поиск вывода идет от цели к аксиомам и теоремам, истинность которых априорно известна. Чтобы определить выводимость формулы из посылок, надо найти формулы - предшественники, из которых нужная формула может быть выведена одним применением правила вывода. Затем по каждой из получившихся формул - предшественников, не являющейся аксиомой исчисления, определяется множество непосредственных формул - предшественников и т. д. Дерево вывода получается, если все листья становятся аксиомами исчисления.
Продукционный вывод. Продукционные модели для представления знаний в экспертных системах отличаются от формальных продукционных систем тем, что они используют более богатые правила и содержат эвристическую информацию о специфике проблемной области, выражаемую, например, в виде семантических структур. В продукционном правиле есть элемент процедурности, т. к. предполагается, что правило будет использовано для выполнения некоторого действия. Декларативные знания не несут никакой информации о том, как они будут использованы. В общем случае продукционное правило может быть представлено в следующей форме: (i); S; С; А=>В; Q, где А=>В называют ядром продукции. Здесь:

А - совокупность посылок;
В - заключение;
С - условие применимости продукции;
S - сфера применимости продукции;
(i) - собственное имя продукции (метка);
Q - постусловие (если ядро реализовано, то может появиться необходимость изменения информации в базе данных, базе знаний или в продукционной системе. Информация об этом может находиться в Q).

Вот лишь некоторые наиболее известные системы, применяющие механизм выводов [Попов 1987], [Гаврилова, Хорошевский 2001]:

MYCIN (разработка Стэнфордского университета (http://www.stanford.edu)) - экспертная система в области медицины;
PROSPECTOR (компании SRI International) - экспертная система в области геологии;
Cattell (разработка компьютерного центра РАН (http://www.ccas.ru/~posp)) - экспертная система в области социальной психологии.

5.3.5.3. Неточный вывод на знаниях

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

Рассмотрим один из типов неопределенности - неточность. Неточное высказывание - высказывание, истинность которого не может быть установлена с определенностью. Модель оперирования с неточными данными и знаниями включает две составляющие.

Язык представления неточности.
Механизм вывода на неточных знаниях.

Для построения языка необходимо выбрать форму представления неточности. Это может быть скаляр, интервал, распределение, лингвистическое выражение или множество. Также надо предусмотреть возможность приписывания всем высказываниям меры неточности. Из подходов к описанию неопределенности можно выделить вероятностный и алгебраический. Механизмы оперирования с неточными высказываниями можно разделить на два типа.

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

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

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

В качестве примеров систем, применяющих аппарат неточного вывода на знаниях, приведем:

CubiCalc (компании HyperLogic (http://www.hyperlogic.com))
FuziCalc (компании FuziWare Inc.).

5.3.6. Электронные библиотеки и инструментарий Интернета

5.3.6.1. Парадигма усиления информации

Рассмотрим парадигму усиления информации, которая достаточно удачно описывает роль ресурсов Интернета (рис. 5.5).

Парадигма проводит параллели с принципом, положенным в основу работы транзистора: усиление сигнала при подпитке от базы.

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

5.3.6.2. Профессиональный поиск информации

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

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

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

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

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

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

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

В настоящее время крупнейшим информационным ресурсом является Интернет, и в первую очередь - среда World Wide Web (WWW) - глобальная интерактивная распределенная гипертекстовая информационная система. Предпринятые попытки оценить размер информации в Интернете согласуются в том, что в среде WWW содержится более миллиарда страниц. Если предположить, что размер среднестатистической страницы составляет 4-10 Кбайт, то речь идет о терабайтах информации. Кроме поверхностной (не скрытой за поисковыми формами) части Интернета, существует скрытая (hidden, deep) часть, к которой относится множество крупных баз данных. Объем скрытой части оценивают в 500 раз больше, чем поверхностной.

5.3.6.3. Проблемы работы с информационными ресурсами Интернета

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

Недостаточная структурированность информации (наличие так называемых слабоструктурированных данных). Для облегчения поиска в таких документах было предложено несколько моделей представления такой информации, в том числе Stanford's Object Exchange Model (http://www.rocq.mria.fr/~simeon/semistructure/art.html), в рамках которой данные представляются в виде направленного графа с поименованными вершинами и дугами.
Избыточность информации. Около трети информации в Интернете является точными или приблизительными копиями других документов.
Наличие противоречивых и недостоверных сведений. Типичным примером является включение некорректных ключевых слов в группу инструкций МЕТА, специально предназначенных для описания и индексирования документов поисковыми машинами. Некоторые поисковые машины сделали попытку решить эту проблему с помощью полнотекстовой индексации документов. Однако сетевые мастера Интернета предложили сразу несколько способов обмануть поисковый робот, например, писать белым шрифтом по белому фону все то, что ранее включалось в инструкцию МЕТА.
Большое количество ошибок (например, опечаток, грамматических ошибок, ошибок оцифровки). Эти ошибки являются следствием неконтролируемого качества, включая отсутствие редакторского контроля над публикуемой информацией.

Укажем на ряд особенностей поиска в Интернете, связанных с понятием человеческий фактор [Jansen, Sprink, Saracevic 2000].

Поведение пользователя. Пользователь не готов долго ждать результата и не готов даже искать его в предоставленной поисковой системой выборке. Практически половина пользователей не идет далее первого экрана, предложенного информационно-поисковой системой.
Неумение делать запросы. Большинство пользователей не использует расширенные возможности поиска, такие как логические выражения. Кроме того, типичные поисковые запросы очень коротки - более 60% запросов состоят всего из 1-2 слов.

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

5.3.6.4. Коллекции информационных ресурсов в Интернете

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

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

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

Систематизация коллекций - задание структуры коллекции, осуществляемое на основе свойств ее предметной области и (или) свойств составляющих ее информационных ресурсов.

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

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

Возможны различные подходы к заданию состава коллекций:

явным образом - непосредственно как совокупность принадлежащих ей информационных ресурсов или как список ссылок на них (например, URL в WWW);
неявным образом - путем спецификации в какой-либо форме критерия принадлежности информационного ресурса данной коллекции. Примером может служить задание коллекции на основе полнотекстовой документальной системы путем спецификации поискового запроса.

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

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

5.3.6.5. Базы данных в Интернете

Среди информационных ресурсов Интернета особый интерес вызывают базы данных, которые подразделяются на [Краснослободцев, Смирнов, Лиходедов 1998]:

текстовые (полнотекстовые, реферативные, библиографические);
содержащие изображения и использующие средства мультимедиа;
числовые и табличные;
содержащие программное обеспечение.

Базы данных в Интернете рассчитаны как на массового, так и на профессионального потребителя. Баз данных первого типа - большинство. Ко второй группе относятся профессиональные информационные системы, представляющие собой специализированные базы данных и поисковые программы. Например, крупнейший мировой продавец информации - компания Questel-Orbit, разместила в Интернете базу данных патентов (http://www.qpat.com). Специализированные базы данных, как правило, имеют свой узкоспециальный интерфейс и собственную уникальную структуру. В последние годы появилась тенденция к интеграции и стандартизации профессиональных баз данных.

5.3.6.6. Краткая история поисковых средств Интернета

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

Необходимость создания поисковых средств Интернета была осознана практически с момента создания сети. Исторически известны такие приложения, как Apachie (для ftp), Veronica (для Gopher) и WAIS (поиск в индексированных базах данных). На сегодняшний день наиболее развитый и удобный в использовании инструмент - поисковые системы. Поисковая система состоит из компонентов, таких как:

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

Серверы, на которых расположены поисковые системы, называют поисковыми серверами.

В число наиболее посещаемых англоязычных поисковых систем (и, соответственно, серверов) входят:

В русскоязычной части Интернета популярны:

Яndex (http://www.yandex.ru);
Rambler (http://www.rambler.ru).

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

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

5.3.6.7. Искусственный интеллект и задача поиска в Интернете

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

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

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

Понятие онтология было введено в искусственный интеллект Томом Грубером [Gruber 1993], как спецификация концептуализации. Подобно формальным спецификациям программных продуктов, онтология - это описание концептов и связей между ними. Предполагалось, что онтологии будут использованы исключительно для облегчения взаимодействия интеллектуальных агентов. Затем понятие онтологии было расширено. В частности, иерархическая структура классов в объектно-ориентированном программировании представляет собой онтологию.

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

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

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

В настоящее время исследование применимости идей искусственного интеллекта к среде Интернет ведется в различных направлениях [Mahalingam, Huhns 1997].

Обработка поисковыми машинами запросов на естественном языке. Система получает запрос на естественном языке, с помощью грамматических и лингвистических правил сопоставляет запрос с информацией в Интернете. Удачным примером такой системы является Япс1ех (http://www.yandex.ru). В ней независимо от того, в какой форме употреблено в запросе слово, поиск учитывает все его формы по правилам русского языка.
Продукционно-эвристическое распознавание естественного языка. Системы, развивающиеся в этом направлении, как правило, являются узкопрофильными и предназначены для выполнения очень узко сформированных целей или обработки ограниченных областей данных. Пример системы - FAQFinder (http://www.infolab.nwu.edu/faqfinder/).
Автоматическое наполнение базы знаний. Это и следующее направления используют агентную технологию. Данное направление реализовано в интеллектуальном браузере WebWatcher (http://www.cs.cmu.edu/afs/cs.cmu.edu/project/theo-6/web-agent/www/project-home.html).
Использование эвристических правил для установки приоритета. Это направление реализовано в другом интеллектуальном браузере - Letizia (http://lcs.www.media.mit.edu/people/lieber/Lieberary/Letizia/Letizia-Intro.html).
Направление нейронных сетей. Основой здесь являются сети искусственных нейронов и других аналогичных конструкций, присущих нервной системе человека, в которых протекают психические процессы, опирающиеся на физиологический и биохимический уровни. Пример реализации этого направления - система работы со знаниями - Autonomy (http://www.autonomy.com/).
Принцип разделяемых знаний. Реализуется в виртуальных группах, т. е. организациях и рабочих коллективах людей, которые работают и общаются между собой в интерактивном режиме. Знакомство с такого рода системами можно начать с AJMS (http://aims.parl.com/About-AIMS.html).

Экспериментальные системы интеллектуального поиска используют одновременно мощь существующих поисковых систем и элементы искусственного интеллекта для отбора и анализа извлеченной из Интернета информации [Холчева 1999]. Поисковая система по запросу пользователя обращается на крупнейшие поисковые серверы. Полученные ссылки сортируются. Анализируются html-файлы, расположенные по этим адресам. Пользователю предлагаются выдержки из текста документов, отражающие результаты поиска.

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

Таблица 5.1. Приоритеты логических операций

Приоритет	Обозначение	Назначение
0	""	Поиск по точному соответствию
1	!	Исключение лексемы
2	&	Логическое И
	\|	Логическое ИЛИ

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

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

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

5.4. Инструментарий поддержки процессов некоторых технологических подходов

5.4.1. Системы формального преобразования и верификации программ

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

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

Система TXL [Kozaczynsky, Hing, Engberts 1992] конвертирует код, написанный на диалекте, в код на базовом языке. Это выполняется через преобразование синтаксического дерева грамматики диалекта в синтаксическое дерево базового языка, а затем получение новой программы из последнего. Для преобразования деревьев использовался рекурсивный алгоритм обхода дерева.
Средство IntelliJ Renamer (http://www.intellij.com/products/) - это мощное средство для преобразования программ и поиска в программном коде, разработанное для языка Java. Оно позволяет производить переименование методов, пакетов, полей, переменных и параметров методов с автоматическим исправлением вхождений. IntelliJ CodeSearch позволяет делать поиск в исходном коде на языке Java, к примеру, вызовов определенных методов или определения классов, реализующих некоторый интерфейс. Это средство корректно работает с перегруженными методами различных классов с одинаковыми именами. В этих средствах используется идея работы по синтаксическому дереву.
Система RescueWare (http://www.relativity.com/products/rescueware/) является системой производства программ с новой бизнес-логикой, преобразуя и используя части существующих программных ресурсов. Для осуществления этих операций система предлагает разделение задачи на несколько подзадач. Сначала проходит стадия понимания программ [Бульонков, Бабурин 2000]. На этом этапе выделяются такие сущности, как программный уровень, потоки данных, карта вызовов. Далее проходит стадия изоляции определенной бизнес-логики. На этом этапе выделяются компоненты, пригодные для переиспользования. Впоследствии созданные компоненты используются для генерации новой программной системы с учетом особенностей новых платформ. В таких подходах ключевым моментом, зачастую, является преобразование программы на процедурном языке в программу на объектно-ориентированном языке. Для осуществления такого преобразования объекты должны быть идентифицированы из процедурных частей. Объектно-ориентированные программы (в сравнении с процедурно-базируемыми) считаются более простыми в сопровождении.

Существуют также системы, которые предназначены для анализа исходных кодов с целью получения высокоуровневых абстракций. Так, например, существуют средства [Niere, Wadsack, Zundorf 2000], которые анализируют код на языке Java с целью генерации диаграмм UML. Данный подход базируется на использовании сетей рассуждений, построенных на нечеткой логике [Jahnke, Heitbreder 1998]. Также существуют средства, которые предоставляют среду разработки для объектно-ориентированных языков, используя диаграммы UML. Они позволяют не только генерировать код по диаграммам, но и анализировать его с целью построения такой диаграммы. Это позволяет более наглядно представлять архитектуру разрабатываемой системы и улучшать ее понимание.

5.4.2. Средства сборочного программирования

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

5.5. Инструментальные системы

Целое - это больше, чем сумма частей.
Аристотель

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

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

Выделяют три группы инструментальных систем.

Инструментальные среды программирования.
Средства автоматизации разработки программ.
Интегрированные среды.

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

5.5.1. Инструментальные среды программирования

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

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

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

Особенности инструментальных сред программирования:

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

Примеры инструментальных сред:

Visual Studio (компании Microsoft (http://www.microsoft.com));
Forte for Solaris Developer Tools (компании Sun Microsystems Inc. (http://www.sun.com));
Delphi Suite (компании Borland International (http://www.borland.com)).

5.5.2. Средства автоматизации разработки программ (CASE-средства)

Средства автоматизации разработки программ - инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки программного обеспечения. Первоначально под CASE-средствами понимались средства, применяемые на ранних процессах жизненного цикла." В первую очередь - на наиболее трудоемких процессах анализа и проектирования. Международный стандарт [ISO/IEC 14102:1995] определяет CASE-средства более широко - как программное средство, поддерживающее процессы жизненного цикла программного обеспечения. CASE-средства характеризуются наличием мощных средств визуального моделирования.

Особенности средств автоматизации разработки программ:

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

Примеры CASE-средств:

Oracle Designer (компании Oracle (http://www.oracle.com));
ERwin (компании Computer Associates International, Inc. (http://www.cai.com));
Rational Rose (компании Rational Software Corporation (http://www.rational.com)).

5.5.3. Интегрированные среды

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

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

Выделяют три уровня интеграции инструментов в интегрированных средах.

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

Особенности интегрированных сред:

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

Примеры интегрированных сред:

WebSphere Studio WorkBench (компании IBM (http://www.ibra.com/software/ad/workbench/));
CohesionWorX (компании Digital Equipment Corp.);
SorfBench (компании Hewlett-Packard (http://www.hp.com)).

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

5.5.4. Репозитории проекта

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

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

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

Модельный.
Программного интерфейса.
Окружения.

Уровень моделирования достаточно хорошо может быть описан универсальным языком UML. Данный язык является абстрактным, не привязанным к конкретной модели. Язык дает возможность описать зависимости элементов, иерархию, взаимосвязи, свойства и т. п.

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

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

Языково-независимая группа.

Информация для отладчика.
Информация для просмотрщика исходных текстов.

Языково-зависимая группа (например, для языка C++).

Информация для шаблонов.
Коды встроенных функций.
Виртуальные функции.

Группа контроля репозитория.

Контроль информации о версиях.
Контроль отношения к проекту.
Тип параллельной обработки.
Тип управления репозиторием.
Проверка цифровой подписи.

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

Статистика отмечает, что около 80% программного обеспечения создается по уже имеющемуся. Следовательно, необходимо иметь инфраструктуру (электронную библиотеку), которая будет поддерживать архивы и достаточно интеллектуальный поиск нужных прототипов и фрагментов. Фактически, мы на более высоком уровне обращаемся к парадигме сборочного программирования, которая характеризуется стремлением к выделению независимой единицы программистского знания (модульной абстракции). Одним из наиболее известных репозиториев является Microsoft Repository (компании Microsoft (http://www.microsoft.com)).

5.6. Средства поддержки коллективной разработки

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

5.6.1. Системы разделения файлов

Для поддержки коллективной работы с файлами применяются три основных класса систем.

Системы управления версиями файлов.
Системы управления пространствами пользователей.
Системы синхронизации удаленных пространств.

Если три класса систем выпускаются одним производителем, то часто каждая последующая система в этом списке использует предыдущую систему, выступая в качестве надстройки.

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

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

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

Классы систем	Среда операционной системы Windows	Среда операционной системы Unix
Управления версиями файлов	PCS (Revision Control System) (http://www.gnu.org/software/rcs/rcs.html)	SCCS (Source Code Control System) (http://www.sun.com)
Управления пространствами пользователей	CVS (Concurrent Versions System) (http://www.cvshome.org)	bringover/putback (http://www.sun.com)
Синхронизации удаленных пространств	Rsync (http://samba.ann.edu.au/rsync)	synctool (http://www.sun.com)

5.6.1.1. Система управления версиями файлов

Множество грехов отпадает, если рядом с колеблющимся стоит свидетель его поступков.
Эпикур

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

Проиллюстрируем работу с версиями на примере системы SCCS. При передаче файла под ее управление, система создает новый файл (так называемый s.-файл) в подкаталоге с именем SCCS. Именно в этом дополнительном файле будут отслеживаться и храниться все изменения: /имя_файла/SCCS/s.имя_файла

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

sccs create <имя_файла> - передать файл под управление SCCS.

sccs get <имя_файла> - извлечь последнюю версию файла, открытую только для чтения.

sccs edit <имя_файла> - извлечь последнюю версию для редактирования, открытую для записи, и заблокировать возможность открыть файл для редактирования остальным пользователям.

sccs unedit <имя_файла> - отменить редактирование и исключить информацию о попытке редактирования, дать возможность открыть файл для редактирования остальным пользователям.

sccs delta <имя_файла> - вернуть измененную версию и добавить комментарий.

sccs delget <имя_файла> - комбинация Команд delta И get. Другие, наиболее часто применяемые операции выглядят так:

sccs prt <имя_файла> - вывести протокол изменений файла, включая комментарии.

sccs dif fs <имя_файла> - выполнить сравнение двух версий файла.

sccs info <имя_файла> - перечислить все файлы текущего каталога, открытые на редактирование командой edit.

Обратим внимание на то, что системой отслеживаются именно изменения (дельты) между версиями, а не сами полные версии, что позволяет занимать небольшое количество дискового пространства. Каталог SCCS часто называют репозиторием проекта.

Как и все широко распространенные программы утилита SCCS имеет надстройки в виде графического интерфейса, например утилиту vertool.

5.6.1.2. Система управления пространствами

Система управления рабочими пространствами пользователей предназначена для обмена результатами работы между отдельными разработчиками через объединение результатов в выделенном рабочем пространстве. Система работает на основе модели "копирование-изменение-слияние" и понятия "рабочее пространство".

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

Две основные команды работы с этими пространствами (рис. 5.8) представляют собой копирование файлов - из пространства-предка в пространство-потомка (например, команда bringover) и обратно (например, команда putback). Обе эти команды имеют одинаковый набор параметров, позволяющих указать пространство-потомка (опция -w), пространство-предка (опция -р), а также список файлов и/или каталогов. Опция -n позволяет не выполнять реальное копирование, а лишь выдать информацию о возможных действиях.

Модель "копирование-изменение-слияние" отражает схему организации работы с пространствами. Основная последовательность действий такова:

Создается основное мастер-пространство, от которого разработчики порождают свои рабочие пространства.
После внесения изменений в своем рабочем пространстве разработчик передает их в мастер-пространство.
Все разработчики периодически обновляют свои рабочие пространства из мастер-пространства.

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

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

5.6.1.3. Система синхронизации удаленных пространств

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

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

5.6.2. Системы поддержки работы виртуальных групп

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

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

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

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

Классификация систем поддержки работы групп по предоставляемым ими возможностям общения была предложена Бобом Йохансеном (Bob Johansen).

В одно и то же время, в одном и том же месте (same time, same place).. Это классический случай, когда разработчики имеют возможность встречаться в одном помещении в определенное время. Здесь оказываются полезными следующие системы поддержки:

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

В одно и то же время, в разных местах (same time, different place). Системы должны обеспечивать общение в реальном времени. Для этого обычно применяются средства аудио- и видеоконференций.
В разное время, в одном и том же месте (different time, same place). Это довольно редкая ситуация, когда существует комната группы, но разработчики не имеют возможности собраться в ней в одно и то же время. Разработчику должна быть предоставлена возможность доступа к репозиторию проекта и всей информации, доступной на данном этапе проекта.
В разное время, в разных местах (different time, different place). Системы реализуют возможности ведения конференций, форумов и чатов с асинхронным подключением, возможность доступа к репозиторию проекта.
Неограниченные возможности доступа к данным (anytime, anyplace). Эта категория оставлена автором классификации на дальнейшее развитие коммуникационных технологий, когда возможности доступа к данным станут практически неограниченными.

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

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

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

Facilitate.com (компании Facilitate.com (http://www.facilitate.com));
Consensus@nyWARE (компании Soft Bicycle (http://www.softbicycle.com));
3-2-1 IntraNet (компании Internet Media Inc.).

5.7. Естественно-языковый интерфейс

Не надо очеловечивать компьютеры, они этого страсть как не любят!
Программистский фольклор

Системы, обрабатывающие естественно-языковые высказывания, можно разделить на следующие классы:

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

5.7.1. Диалоговые системы

Когда много спрашивают - мало думают и плохо помнят.
М. Горький

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

Рассмотрим пример ведения диалога. Программа предлагает поговорить по некоторым темам, которые выбираются пользователем из меню. Например, выбрана тема "Языки программирования". Программа начинает диалог: "Давайте поговорим о языках программирования. Какому из языков программирования вы отдаете предпочтение?". Первый вопрос выбирается из первой, начальной, рубрики или всех рубрик темы случайным образом. Текущая рубрика запоминается. Пользователь вводит ответ. Например, "На работе я выполняю проект на языке C++, а дома люблю писать программы на языке РЕФАЛ". Программа ищет в рубрикации ключевые слова из ответа пользователя, определяет на их основе, что сказал пользователь, и, основываясь просто на этих ключевых словах пользовательского ответа, случайно выбирает вопрос из текущей рубрики. Если в текущей рубрике не найдено ни одно ключевое слово, система ищет ключевые слова в других рубриках и при нахождении их меняет текущую рубрику. Например, если в какой-либо рубрике темы "Языки программирования" есть слово "C++", которому соответствует вопрос "Сколько лет вы уже программируете на C++?", то программа задает этот вопрос. Остальные ключевые слова, которым соответствуют какие-либо вопросы, запоминаются и ставятся в очередь. Основываясь на ключевых словах (в примере это были слова С++ и РЕФАЛ), накапливается очередь вопросов.

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

5.7.2. Вопросно-ответные системы

Суди о человеке больше по его вопросам, чем по его ответам.
Ф. Вольтер

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

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

5.7.3. Автоматизированные обучающие системы и системы контроля знаний

Плохому учатся и без учителя.
Античный афоризм

Автоматизированные обучающие системы предназначены для обучения пользователей какой-либо предметной области с последующей проверкой знаний. Наиболее эффективная форма проверки знаний - общение пользователя с компьютером на естественном языке, поэтому такие системы должны включать блоки анализа естественно-языковых высказываний. Рассмотрим наиболее интересные подходы к реализации семантических анализаторов высказываний в автоматизированных обучающих системах (АОС) [Искусственный 1990].

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

5.7.4. Системы искусственного интеллекта

Вопрос "может ли компьютер думать?" ничуть не более интересен, чем вопрос "может ли подводная лодка плавать?"
Э. Дейкстра

Мысль умирает первой.
Надежда

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

Система семантического анализа компании Artificial Life Inc. Компания Artificial Life Inc. (http://www.artificial-life.com) разработала систему семантического анализа языка на основе шаблонов. Эта система предназначена как для семантического анализа текстов, так и для анализа отдельных фраз, введенных пользователем. Система позволяет анализировать отдельные документы и выдавать краткий отчет, в котором будет отражен семантический смысл документа, или же вести диалог с пользователем на естественном языке. Диалог с пользователем ведется с помощью робота. Робот может отвечать на вопросы, сам задавать вопросы, что-то рассказывать пользователю и изменять тему разговора. Ядром системы является модуль ALife Smart Engine. Этот модуль содержит функции, реализующие алгоритмы семантического анализа. Alife Smart Engine работает исключительно на шаблонах. Шаблон представляет собой направленный граф, составленный из слов, и поэтому существует поддержка нескольких языков. Необходимо только написать в шаблонах слова на соответствующем языке.
Семантический словарь Тузова. В. А. Тузовым [Тузов 1990] предложено решение общей проблемы семантического анализа русского языка. На основе введенной пользователем фразы строится суперпозиция логических функций. Алгоритм анализа основан на поиске семантических связок слов в высказывании. Все семантические связки между словами хранятся в специальном словаре. Система сама определяет, какое слово какому подчинено, где подлежащее, сказуемое, наречие, определение и т. д. Полностью реализован анализ взаимодействия слов по синтаксическим признакам, предлогам, приставкам, суффиксам и т. д. На основе найденных связок слов строится суперпозиция логических функций. Недостатками данной системы являются: необходимость наличия словаря слов и их форм, правил сочетания слов, а также постоянное их обновление.

ЛИТЕРАТУРА

Можно определить достоинство народа по количеству книг, которые он поглощает.
Э. Лабупе

1. Ахо, Сети, Ульман 2001 - Ахо А., Сети Р., Ульман Дж. Компиляторы: принципы, технологии и инструменты. - М.: Издательский дом "Вильямс", 2001.

2. Ахо, Ульман 1978 - Ахо А., Ульман Дж. Теория синтаксического анализа, перевода и компиляции. В 2-х томах. - М.: Мир, 1978.

3. Бульонков, Бабурин 2000 - Бульонков М. А., Бабурин Д. Е. HYPERCODE - открытая система визуализации программ. // Автоматизированный реинжиниринг программ. - СПб.: Изд-во СПбГУ, 2000.

4. Вендров 1998 - Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1995.

5. Гаврилова, Хорошевский 2001 - Гаврилова Т. А., Хорошевский В. Ф. Базы знаний интеллектуальных систем. - СПб.: Питер, 2001.

6. Грис 1975 - Грис Д. Конструирование компиляторов для цифровых вычислительных машин. - М.: Мир, 1975.

7. Дейт 2000 - Дейт К. Введение в системы баз данных, 6-е изд. - К.; М.; СПб.: Издательский дом "Вильяме", 2000.

8. Жоголев 1996 - Жоголев Е. А. Лекции по технологии программирования. - М.: МГУ, факультет ВМиК, рукопись, 1996.

9. Искусственный 1990- Искусственный интеллект: В 3-х кн. Справочник. - М.: Радио и связь, 1990.

10. Каляное 1996- Калянов Г. Н. CASE структурный системный анализ (автоматизация и применение). - М.: ЛОРИ, 1996.

11. Когаловский 1999 - Когаловский М. Р. Научные коллекции информационных ресурсов в электронных библиотеках.// Электронные библиотеки: Перспективные методы и технологии, электронные коллекции: Труды Первой Всероссийской научной конференции. С.-Петербург, 19-22 октября 1999 г - СПб Изд-во СПбГУ, 1999, с. 16-31.

12. Кожохарь, Евстюнин, Терехов, Уфнаровский 1992 - Кожохарь С. К., Евстюнин М. В., Терехов А. Н., Уфнаровский В. А. Как Паскаль и Оберон попадают на "Самсон", или искусство создания трансляторов. - Кишинев: "Штиинца", 1992.

13. Краснослободцев, Смирнов, Лиходедов 1998- Краснослободцев В. Я., Смирнов А. Б., Лиходедов Н. П. Инновационный инжиниринг. Практикум. Учебное пособие. - СПб.: Государственный технический университет, 1998.

14. Мартин 1982 - Мартин Д. Организация баз данных в вычислительных системах. - М.: Финансы и статистика, 1982.

15. Нильсон 1985 - Нильсон Н. Принципы искусственного интеллекта. - М.: Радио и связь, 1985.

16. Паронджанов 1999 - Паронджанов В. Д. Как улучшить работу ума. - М.: Радио и связь, 1999.

17. Попов 1987 - Попов Э. В. Экспертные системы. - М.: Наука, 1987.

18. Поттосин 1995 - Поттосин И. В. Текущее состояние российских исследований и разработок в области трансляции. - Новосибирск: Изд-во ИСИ СО РАН 1995.

19. Поттосин 1997 - Поттосин И. В. Про грамм истекая инженерия: содержание, мнения и тенденции. // Программирование. - 1997. - № 4. - С. 26-37.

20. Сафонов 1989 - Сафонов В. О. Языки и методы программирования в системе "Эльбрус". - М.: Наука, 1989.

21. Смирнов, Керов, Дерюшев 1998 - Смирнов В. М., Керов Л. А., Дерюшев В. А. Создание Windows и Internet-приложений в виде виртуальных книг. - СПб.: ЭЛБИ, 1998.

22. Сорокин 1989 - Сорокин В. В. Многоуровневая архитектура технологического программного окружения. - Новосибирск: Изд-во НФ ИТМ и ВТ АН СССР, 1989.

23. Тузов 1990- Тузов В. А. Языки представления знаний.- Л.: Изд-во ЛГУ.- 1990.

24. Цейтин 1990 - Цейтин Г. С. На пути к сборочному программированию. // Программирование. - 1990. - № 1. - С. 78-92.

25. Фаулер, Скотт 1999 - Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. - М.: Мир, 1999.

26. Холчева 1999 - Холчева А. В. Система для создания и поддержки персональных электронных библиотек. // Интернет и современное общество: Тезисы Второй всероссийской научно-методической конференции. Санкт-Петербург, 29 ноября - 3 декабря 1999 г. - СПб.: Изд-во СПбГУ, 1999, с. 95-96.

27. Aho, Sethi, Ullman 1986- Aho A., Sethi R., Ullman J. Compilers: Principles, Techniques, and Tools. Springer Verlag, 1986.

28. Ambras, O'Day 1987 - J. Ambras, V. O'Day. Microscope: A program analysis system. // Proc. 20th Hawaii Inter. Confi Syst. Sci., 1987, pp. 460-468.

29. Badger, Weiser 1988 - Badger L., W. M. Minimizing. Communications for Synchronizing Parallel Data-flow Programs. // Proc. International Conference for Parallel Processing. 1988.

30. Ball, Honvitz 1993 - Ball Т., Horwitz S. Slicing Programs with Arbitrary Control-flow. Proceeding First International Workshop Automated and Algorithmic Debugging. // LNCS. 1993. V. 749, pp. 206-222.

31. Chen, Nishimoto, Ramamoorthy 1990- Y. Chen, M. Y. Nishimoto, C. V. Ramamoorthy. The С information abstraction system. IEEE Trans. Software Eng., vol. 16, no.3, pp. 325-334, Mar. 1990.

32. Grass 1992 - J. E. Grass. Object-Oriented Design Archaeology with CIA++. Comput. Syst. J. USENIX Assn., vol. 5, no. 1, pp. 5-67, Winter 1992.

33. Gruber 1993 - T. R. Gruber. A translation approach to portable ontologies. Knowledge Acquisition 5(2), 1993, pp. 199-220.

34. ISO/IEC 14102:1995- ISO/IEC 14102:1995 Information Technology Guideline for the evaluation and selection of CASE tools.

35. Jahnke, Heitbreder 1998 - J. H. Jahnke, M. Heitbreder. Design recovery of legacy database applications based on possibilistic reasoning. Proceedings of 7th IEEE Intl. Conf. Of Fuzzy Systems (FUZZ'98). Anchorage, USA. IEEE Computer Society Press. May 1998.

36. Jansen, Sprink, Saracevic 2000 - B. J. Jansen, A. Sprink, T. Saracevic. Real life, real users, and real needs: a study and analysis of user queries on the web. Information Processing and Management, 36(2), 2000, pp. 207-227.

37. Kozaczynsky, Hing, Engberts 1992 - W. Kozaczynsky, J. Hing, A. Engberts. Program concept recognition and transformation. IEEE Trans. Software Eng., vol. 18, no. 12, pp. 1065-1075, Dec., 1992.

38. Linton 1984 - M. A. Linton. Implementing relational views of programs. // Proc. ACM SIGSOFT/S1GPLAN Software Eng. Symp., Practical Software Devel. Envir., May 1984.

39. Mahalingam, Huhns 1997 - K. Mahalingam, M. N. Huhns. A Tool for Organizing Web Information. // Computer, June 1997, pp. 80-83.

40. Muchnick 1997 - S. Muchnick. Advanced compiler design and implementation. Morgan Kaufmann Publishers, 1997.

41. Niere, Wadsack, Zundorf 2000- J. Niere, J. Wadsack, A. Zundorf. Recovering UML Diagrams from Java code using patterns. University of Paderborn, Department of mathematics and computer science. 2000.

42. Sharon, Bell 1995 - D. Sharon, R. Bell. Tools that bind: creating integrated environments // IEEE Software, March 1995, pp. 76-85.

43. Sommerville 1992 - I. Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992.

технологии программирования к оглавлению к высокоуровн. языкам - 3GL к визуальным средам - 4GL

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

НОВОСТИ ФОРУМА

Рыцари теории эфира