Объектно-ориентированная среда

Завершенная схема среды будет приведена позже (рис. 18.2). Некоторые ее важнейшие компоненты помещены на CD, прилагаемом к книге. Цель этого представления состоит в том, чтобы показать, как поддержка среды может сделать ОО-концепции удобными для практического использования. Предостережение: обсуждаемая среда никоим образом не является совершенной (фактически она все еще развивается). Это просто пример современной OO-среды. Другие, упомянем, например, Borland Delphi, завоевали широкий и заслуженный успех. Но мы должны изучить одну среду более глубоко, чтобы понять связь между принципами ОО-метода и их ежедневным применением разработчиком у терминала. Автор надеется, что многие концепции будут полезны и для читателей, использующих другие инструментальные средства.

Компоненты среды

СредаПри чтении этой лекции следует учитывать, что за годы, прошедшие после написания этого текста, сама среда (но не язык) существенно изменилась. На диске, прилагаемом к книге, представлена одна из ее последних версий Envision, позволяющая работать на Eiffel в среде Visual Studio.Net. Хотя данный текст описывает устаревшую версию, но общие идеи проектирования подобной среды сохранили свое значение. В предисловии редактора и автора даются ссылки на сайт, позволяющий познакомиться с последними достижениями в этой области. объединяет следующие элементы:

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

Язык

Язык - это нотация, введенная в лекциях 7-18 курса "Основы объектно-ориентированного программирования" и применяемая в ней. Мы по существу полностью ее рассмотрели за исключением нескольких технических деталей, таких как представление специальных символов.

Развитие

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

Открытость

Одно из предназначений языка программирования состоит в использовании его для обертывания компонентов, написанных на других языках. Механизм включения внешних элементов с помощью предложения external был описан ранее. Библиотека Cecil позволяет внешнему ПО использовать ОО-механизмы: создавать экземпляры классов и вызывать компоненты этих объектов через динамическое связывание (конечно, при ограниченном статическом контроле типов).

Особый интерес представляют интерфейсы с языками C и C++. Для C++ доступно средство под названием Legacy++, позволяющее на основе существующего класса C++ создать обертывающий класс (wrapper class), автоматически инкапсулирующий все экспортируемые компоненты оригинала. Это особенно полезно для организаций, которые использовали C++ как первую остановку на пути к ОО и теперь хотят без потерь инвестиций перейти к законченной и систематической форме объектной технологии. Инструментарий Legacy++ сглаживает такой переход.

Технология компиляции

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

Требования к компиляции

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

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

Технология тающего льда

Для решения указанных проблем технология компиляции, известная как Технология тающего льда (Melting Ice Technology), использует сочетание дополняющих друг друга методов. Откомпилированную систему называют замороженной, уподобляя ее куску льда в морозильной камере. Образно говоря, чтобы начать работу над системой, ее нужно достать из холодильника и немного подогреть. Растаявшие элементы представляют собой изменения. Эти элементы не станут причиной цикла "перекомпиляция - сборка" для удовлетворения требования C2. Вместо этого "растаявший" код будет непосредственно обрабатываться исполняющей машиной, встроенной в окружение.

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

Быстрая перекомпиляция. Типичное время ожидания - несколько секунд.(рис 18.1) "Замороженная" и "растаявшая" части системы

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

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

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

Анализ зависимостей

Как это и должно быть в любой современной среде разработки, процесс перекомпиляции является автоматическим. Вы просто нажимаете кнопку Melt в инструментарии Project Tool, описанном ниже, и механизмы тихо определят набор элементов, подлежащих перетрансляции. Нет никакой потребности в файлах Make, а нотация не содержит понятия "include file".

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

Для снижения времени в качестве единицы перекомпиляции выбирается не класс, а отдельная подпрограмма.

Предкомпиляция

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

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

В новую систему можно включить неограниченное число откомпилированных библиотек. Механизм объединения таких библиотек поддерживает совместное использование. Если две откомпилированные библиотеки B и C ссылаются на A (например, графическая библиотека Vision и клиент-серверная библиотека Net, обсуждаемые далее, обе используют библиотеку структур данных и фундаментальных алгоритмов Base), то только одна копия A включается в систему.

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

Удаленное выполнение

Интерпретируемый код, сгенерированный после таяния, традиционно известный как байт-код, является независимым от платформы. Для выполнения байт-кода достаточно иметь копию Исполняющей Машины (Execution Engine), известной как 3E и свободно загружаемой через Интернет.

Установка 3E в качестве дополнительного модуля (plug-in) Web-браузера дает возможность непосредственного выполнения кода. 3E автоматически выполнит соответствующий код при активизации пользователем гиперссылки, соответствующей байт-коду. Этот механизм удаленного выполнения стал популярен благодаря Java.

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

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

Оптимизация

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

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

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

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

Инструментальные средства

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

Bench и процесс разработки

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

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

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

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

На рис. 18.2 показана общая схема среды разработки, где в центре находится рабочее место разработчика.

Инструментальные средства высокого уровня

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

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

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

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

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

На рис. 18.3 приведен пример работы с Case, показан кластер описания химического предприятия, свойства одного из его классов (VAT) и свойства одного из компонентов этого класса ( fill ).

Библиотеки

Перечень библиотек приведен на рис. 18.2. Они играют значительную роль в процессе разработки ПО, обеспечивая разработчиков богатым набором (несколько тысяч классов) компонентов повторного использования. Набор библиотек содержит:

В нижней части рис. 18.2 показаны библиотеки, используемые для поддержки сохраняемости во время выполнения. Класс STORABLE и дополнительные инструментальные средства, обсуждаемые ранее, поддерживают хранение, поиск и передачу по сети объектных структур в соответствии с принципом Замыкания Сохраняемости. Библиотека Store обеспечивает интерфейс с базами данных, реализуя механизмы доступа и сохранения данных в реляционных (Oracle, Ingres, Sybase) и ОО-базах данных.

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

Особый интерес представляет совместное использование Net, Vision and Store для формирования клиент-серверных систем. Сервер обеспечивает работу базы данных с помощью Store и выполняет громоздкие вычисления, используя Base, Math и т. д. Тонкие клиенты, использующие Vision (или одну из библиотек для конкретных платформ), обеспечивают практически только интерфейс пользователя.

Реализация интерфейса

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

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

Платформы

Приведенные иллюстрации получены во время сеанса работы на Sun Sparcstation исключительно по причине удобства. На время написания книги поддерживались другие платформы, включая Windows 95 и Windows NT, Windows 3.1, OS/2, Digital VMS (Alpha и Vax) и все основные версии Unix (SunOS, Solaris, Silicon Graphics, IBM RS/6000, Unixware, Linux, Hewlett-Packard 9000 Series и т. д.).

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

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

Инструментальные средства

Среда разработки зачастую состоит из инструментальных средств, построенных на основе функционального подхода, когда каждое средство выполняет определенные функции: просмотр, отладку или форматированную печать исходных текстов. Например, среда Sun Java Workshop (продемонстрированная в сентябре 1996 г.) соответствует этому традиционному образцу, так для поиска предков класса необходимо запустить специальный браузер.

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

Тем же самым способом, каким мы учились доверять типам объектов, а не функциям, описывающим программную архитектуру, можно создавать инструментальные средства в соответствии с используемыми объектами разработки (development objects). Вместо отладчика или окна браузера необходимы Инструмент Класса (Class Tool), Инструмент Компонента (Feature Tool), Системный Инструмент (System Tool), Инструмент Проекта (Project Tool), Объектный Инструмент (Object Tool) в соответствии с абстракциями, используемыми в ОО-разработке: классами, компонентами, системами (наборами классов), проектами и экземплярами класса во время выполнения ("объектами" в строгом смысле).

Project Tool, например, будет полностью следить за проектом. Он используется для выполнения Melt, Freeze или Finalize. На рис. 18.2 показан Project Tool в процессе компиляции, показывающий процент выполненной работы.

Class Tool может быть нацелен на конкретный класс, например, LIST (рис. 18.6).

Feature Tool совместно с Project Tool во время сеанса отладки (рис. 18.7) показывают компонент и ход выполнения с механизмами пошаговой отладки, отображают состояние стека (см. значения локальных сущностей в Project Tool). Feature Tool нацелен на компонент call_this_routine класса TEST.

В процессе выполнения можно следить за отдельным объектом с помощью инструментария Object Tool, показанного на рис. 18.8.

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

Можно использовать столько экземпляров Class Tool, Feature Tool и Object Tool, сколько необходимо, но только один System Tool и один Project Tool доступен в течение сеанса.

Перенастройка и просмотр

Существуют разные способы перенастройки инструмента, например перенастройка Class Tool с LIST на ARRAY. Можно просто ввести новое имя класса в соответствующее поле (если Вы точно его не помните, то можно использовать символ подстановки " * " - ARR* для получения меню со списком соответствующих имен).

Можно также использовать кратко представленный ранее механизм pick-and-throw1 ("выбрать и перетащить") (см. лекцию 15 курса "Основы объектно-ориентированного программирования"). Если щелкнуть правой кнопкой мыши на имени класса, например, на CHAIN в Class Tool настроенном на класс LIST, то курсор превратится в "камешек" (pebble) в форме эллипса, показывая, что выбран класс. Далее нужно выбрать "лунку" (hole) такой же формы в Class Tool (том же самом или другом) и положить камешек в лунку, щелкнув правой кнопкой мыши. В качестве лунки может выступать кнопка на панели инструментов или клиентская область окна соответствующего инструментального средства.

Механизм pick-and-drop - обобщение drag-and-drop. Вместо необходимости постоянно удерживать нажатую кнопку операция разбивается на три шага. Сначала выбирается объект щелчком правой кнопки мыши, появляется камешек. Далее в режиме перетаскивания камешек постоянно связан нитью с выбранным элементом(рис 18.9) (рис. 18.9). Наконец, еще один щелчок правой кнопкой мыши уже в целевой лунке. Можно назвать три преимущества по сравнению с обычным drag-and-drop:

Однако все это связано только с интерфейсом пользователя. Более важная роль pick-and-drop проявляется в соединении с другими механизмами среды - поддержка интегрированного набора механизмов для всех задач разработки ПО. Если вновь обратиться к Class Tool, отображающем отложенный класс LIST библиотеки Base (рис. 18.10), то второй сверху ряд кнопок позволяет выбрать формат вывода. Возможные варианты:

class text (текст класса) ;

ancestors (предки) ;

short form (краткая форма) ;

routines (подпрограммы) ;

deferred routines (отложенные подпрограммы)

и так далее. Щелчок на одной из них отобразит текст класса в соответствующем формате. Например, если нажимается кнопка Ancestors (Предки), то Class Tool отобразит структуру наследования (рис. 18.10).

В любом окне инструментальных средств все важные элементы интерактивны (clickable). Это означает, что для получения информации о классе CURSOR_STRUCTURE достаточно щелкнуть на нем правой кнопкой мыши и использовать pick-and-drop для перенастройки этого или другого инструментального средства на выбранный класс. После этого можно выбрать другой формат, например краткую форму. Далее можно снова применить pick-and-drop и настроить Feature Tool на интересующую Вас подпрограмму. В Feature Tool можно просмотреть предысторию, то есть все приключения компонента в играх наследования: все версии после переименования, переопределения и т. д. Для любого упомянутого класса и компонента можно вновь использовать pick-and-drop.

В процессе сеанса отладки, показанного ранее (рис. 18.7), необходимую информацию можно также получить с помощью pick-and-drop. Щелчок правой кнопкой на объекте 0X142F18 (внутренний идентификатор, сам по себе ничего не говорящий, но интерактивный) позволяет запустить Object Tool, использованный для отображения экземпляра PERSON (рис. 18.8). Этот инструментарий обеспечит просмотр всех полей и ссылок объекта, также интерактивных. Так можно легко исследовать структуры данных во время выполнения.

Можно осуществить вывод в каждом из доступных форматов (HTML, TЕX, RTF, FrameMaker MML, troff), причем компактный язык описаний позволяет определить собственные форматы или модифицировать существующие. Вывод может быть отображен, сохранен с файлами класса или в отдельном каталоге для подготовки документации проекта или кластера.

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

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

Некоторые лунки, известные как "кнопки-лунки" (buttonholes), одновременно выполняют функции кнопки. Например, щелчок левой кнопкой на лунке Stop Point приведет к отображению в Project Tool информации о точках останова. Это представление тоже интерактивно и позволяет легко удалить существующие точки останова или добавить новые.

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

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

Библиографические замечания

Обзор преимуществ среды дан в [M 1996b], он также доступен в Internet [M-Web] наряду со многими другими техническими документами и описаниями реальных проектов.

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

В публикациях [M 1985c], [M 1987b], [M 1987c], [M 1988], [M 1988a], [M 1988d], [M 1988f], [M 1989], [M 1993d], [M 1997] обсуждаются различные аспекты среды на различных стадиях ее развития.

Описание языка дано в [M 1992]. Книга Reusable Software [M 1994a] содержит наряду с обсуждением принципов построения библиотек детальное описание библиотек Base.

Другая книга [M 1994] представляет среду в целом. [М. 1995c] описывает анализ Case и среду проектирования, [М. 1995e] - конструктор графических приложений Build [M 1995e]. Принципы построения интерфейса представлены в [M 1993d].

Генератор YOOC разработан Christine Mingins, Jon Avotins, Heinz Schmidt и Glenn Maughan из Monash University [Avotins 1995] и доступен на FTP-сервере Monash University. ОО-методы синтаксического анализа библиотеки Parse представлены в [M 1989d] и [M 1994a].

Библиотека Math разработана Полем Дюбуа и описана в [Dubois 1997].