Рис. 1. Нетекстовое представление программы.
Отметим еще одну причину, по которой обычное, текстовое представление программы является неудовлетворительным. Система ЭСКОРТ предназначена для разработки и сопровождения больших программных систем, насчитывающих сотни тысяч операторов. Для подобных систем весьма важно поддерживать информацию о связях между отдельными компонентами. Очевидно, что информация о связях имеет нетекстовую природу, а каждый раз вычислять ее по тексту не представляется возможным, ведь чем больше система, тем важнее информация о связях, но и вычислять ее становится труднее.
Нетекстовое представление позволяет предоставить пользователю такие возможности, как структурное редактирование, разные виды структурного перемещения, настройку внешнего вида программы (поскольку он вычисляется и может изменяться без изменения семантики программы).
В последнее время в технологии реализации СУБД, особенно объектно-ориентированных, сделан большой шаг вперед, однако добиться нужного качества, на наш взгляд, пока не удалось. Это делает крайне важным продолжение исследований в данной области.
Объектно-ориентированная СУБД является информационным ядром системы ЭСКОРТ. СУБД ЭСКОРТ поддерживает понятия версий и вариантов. Использование принципа неуничтожения информации позволило, с одной стороны, обеспечить поддержку системы конфигурационного управления, а с другой - по-новому решить задачу синхронизации процессов - клиентов СУБД.
Инструментальный программный комплекс должен обеспечивать хранение истории разработки, поддерживать механизм версий и вариантов. Отсюда следует, что при модификации объектов, входящих в состав базы данных, должно создаваться новое состояние объектов; старое состояние следует оставить для реализации откатки.
Каждый пользователь системы ЭСКОРТ работает со своим вариантом базы данных. При первом изменении некоторого объекта его новое состояние реализуется как принадлежащее только новому варианту; старое состояние остается в общей базе данных. Тем самым доступ к общей базе данных осуществляется только на чтение. Разделение общих объектов позволяет уменьшить избыточность информации - каждый вариант хранит только модифицированные фрагменты. В этом состоит одно из отличий от системы Cedar, в которой в начальный момент выполняется полное копирование исходного состояния. Впрочем, в рамках простой файловой системы иной (не такой как в Cedar) подход невозможен.
Так как доступ к общей базе данных осуществляется только на чтение, синхронизация в традиционном смысле оказывается необходимой лишь при первом изменении общего объекта. Поскольку такие случаи существенно более редки, чем модификация объектов вообще, для синхронизации можно использовать прямолинейные методы, например, монопольный захват базы данных на время транзакции.
Применение страничной виртуальной памяти позволило сделать СУБД невидимой для программиста - работа с долговременными объектами ничем не отличается от работы с объектами, хранящимися в оперативной памяти. Следовательно, можно использовать обширные библиотеки классов, накопленные для языка C++. В то же время поддерживаются такие специфичные для СУБД средства, как аппарат транзакций и откатка.
Чтобы настроить редактор на конкретный язык программирования, необходимо определить лексику и синтаксис данного языка. Для спецификации языка используется специально разработанный формализм.
Редактор объединяет достоинства текстового и структурного редактирования. Основным режимом ввода и модификации программ является структурный; при редактировании некоторых, указанных при настройке, синтаксических конструкций возможно текстовое редактирование, которое сопровождается синтаксическим разбором соответствующего фрагмента программы. Одновременно производится контроль синтаксиса.
Часть редактора, реализующая уровень хранения, выделена в отдельный компонент. Предполагается, что редактируемые структуры хранятся в объектной базе данных. Модель данных составляют несколько взаимосвязанных классов объектов. Для работы с данными редактор использует фиксированный объектно-ориентированный интерфейс. Пользователь может воспользоваться либо одной из стандартных реализаций этого интерфейса, либо своей собственной.
Абстрактный структурно-текстовый редактор состоит из нескольких утилит для формирования стандартного настроенного редактора, пакета процедур, позволяющих встраивать в прикладные программы средства структурного редактирования (так называемый структурно-текстовый драйвер), и библиотек, реализующих стандартные варианты хранения данных.
В состав инкрементальных систем программирования могут входить следующие компоненты:
Важно, чтобы инкрементальные методы анализа были применимы к незавершенным и некорректным программам: это делает инструментальную систему устойчивой по отношению к ошибкам пользователя, позволяет предоставить ему максимум информации и не навязывать жесткой дисциплины редактирования программы.
В системе ЭСКОРТ реализованы инкрементальные методы анализа программ, удовлетворяющие перечисленным выше требованиям. Эти методы используются, в частности, для контроля корректности абстрактного синтаксиса, проверки правил областей действия, статического контроля типов, подготовки программы к выполнению. Остановимся на последнем из упомянутых аспектов.
Редактирование программы в ЭСКОРТе всегда сопровождается ее инкрементальной трансляцией. Транслятор сопоставляет каждому объекту сегмент выполняемых команд. Сегмент может содержать, помимо прочих, команды вычисления адреса сегмента команд подобъекта, перехода к сегменту команд подобъекта, возврата к сегменту команд объемлющего объекта. Для инкрементальной трансляции применяется атрибутная схема. Граф зависимостей совпадает с графом программы. В качестве внешних атрибутов используется информация о месте определения объекта, местах использования, его синтаксическом классе, выполнении в нем правил областей действия, статическом типовом выражении, синтаксической и типовой корректности. Правило связывает значение вычисляемого атрибута со значениями внешних атрибутов подобъектов и данного объекта:
a(p) = s(o(p), o(p1)o(p2)...o(pN))
Таким образом, сегмент кода для объекта должен быть сформирован заново, если в результате редактирования изменились либо граф программы, либо внешние атрибуты данного объекта или его подобъектов, использованные при предыдущей трансляции. Как видно из атрибутной схемы, ряд изменений в программе вообще не требуют перетрансляции. Примерами таких модификаций могут служить изменения внешнего представления (редактирование комментария, размещение на одной строке управляющей конструкции или последовательных операторов, ранее располагавшихся на нескольких и т.п.), переименование процедуры или переменной.
Предложенную схему перетрансляции можно применить для более глубокой трансляции, а также для использования дополнительной информации, позволяющей оптимизировать формируемый код.