учебники, программирование, основы, введение в,

 

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

Компоненты среды
Среда объединяет следующие элементы:

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

Следующие разделы содержат обзор этих элементов за исключением первого, составляющего предмет данной книги.
Язык
Язык - это нотация, введенная в лекциях 7-18 курса "Основы объектно-ориентированного программирования" и применяемая в ней. Мы по существу полностью ее рассмотрели за исключением нескольких технических деталей, таких как представление специальных символов.
Развитие
Первая реализация языка выпущена в конце 1986 г. Единственный существенный пересмотр (1990 г.) не затронул никаких фундаментальных концепций, но упростил выражение некоторых из них. С тех пор ведется постоянная работа по уточнению и упрощению, затрагивающая только детали. Два недавних расширения связаны с механизмом параллелизма (рассмотренным в, где добавлено единственное ключевое слово separate) и конструкцией Precursor для облегчения переопределения. Стабильность языка, редкое явление в этой области, была для пользователей среды одним из важных преимуществ.
Открытость
Одно из предназначений языка программирования состоит в использовании его для обертывания компонентов, написанных на других языках. Механизм включения внешних элементов с помощью предложения external был описан ранее. Библиотека Cecil позволяет внешнему ПО использовать ОО-механизмы: создавать экземпляры классов и вызывать компоненты этих объектов через динамическое связывание (конечно, при ограниченном статическом контроле типов).
Особый интерес представляют интерфейсы с языками C и C++. Для C++ доступно средство под названием Legacy++, позволяющее на основе существующего класса C++ создать обертывающий класс (wrapper class), автоматически инкапсулирующий все экспортируемые компоненты оригинала. Это особенно полезно для организаций, которые использовали C++ как первую остановку на пути к ОО и теперь хотят без потерь инвестиций перейти к законченной и систематической форме объектной технологии. Инструментарий Legacy++ сглаживает такой переход.
Технология компиляции
Первой задачей среды разработки является выполнение ПО.
Требования к компиляции
Технология компиляции разрабатывалась и совершенствовалась многие годы для решения следующих задач:

  • C1 Эффективность сгенерированного кода должна быть сопоставимой с эффективностью, достигаемой при использовании классического языка типа C. Нет никаких причин платить за OO-методы снижением производительности.
  • C2 Время перекомпиляции после внесения изменений должно быть коротким. Точнее, оно должно быть пропорционально объему изменений, а не размеру полной системы. Важнейшим требованием для разработчиков, создающих большие системы, является возможность немедленно увидеть результаты сразу после внесения изменений.
  • C3 Третье требование появилось позже, но становится важным для пользователей: поддержка быстрой доставки приложений через Internet для непосредственного выполнения.

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

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

При увеличении числа изменений доля растаявшего кода будет расти и через некоторое время снижение производительности может стать заметным. Разумно "замораживать" всю систему полностью каждые несколько дней. Поскольку замораживание подразумевает компиляцию и компоновку, типично на это требуется несколько минут (или даже часов после нескольких дней обширных изменений). Можно запустить эту задачу в фоновом режиме или ночью.
Анализ зависимостей
Как это и должно быть в любой современной среде разработки, процесс перекомпиляции является автоматическим. Вы просто нажимаете кнопку Melt в инструментарии Project Tool, описанном ниже, и механизмы тихо определят набор элементов, подлежащих перетрансляции. Нет никакой потребности в файлах Make, а нотация не содержит понятия "include file".
Для выявления фрагментов, требующих перекомпиляции, инструментальные средства среды сначала выясняют, какие сделаны изменения. Изменения могут делаться редактором классов, встроенным в среду, либо обычным внешним текстовым редактором. Поскольку исходный текст класса хранится в отдельном файле, имеющем временную отметку, то она обеспечивает нас нужной информацией. Далее анализируются отношения между классами - клиентские и наследования - для определения того, что еще затронуто и требует перекомпиляции. В случае клиентских отношений скрытие информации позволяет минимизировать подобные действия: если изменения затрагивают только секретные компоненты класса, то его клиенты не нуждаются в перекомпиляции.
Для снижения времени в качестве единицы перекомпиляции выбирается не класс, а отдельная подпрограмма.


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

Предкомпиляция
Понимая всю значимость повторного использования, разработчикам дается возможность объединять тщательно отработанные наборы компонентов в библиотеки, откомпилированные раз и навсегда. Другие разработчики будут просто включать их в свои системы, ничего не зная о внутренней организации компонентов.
Эта цель достигается с помощью механизма предкомпиляции набора классов. Такую откомпилированную библиотеку можно с помощью файла Ace включить в новую систему.
В новую систему можно включить неограниченное число откомпилированных библиотек. Механизм объединения таких библиотек поддерживает совместное использование. Если две откомпилированные библиотеки B и C ссылаются на A (например, графическая библиотека Vision и клиент-серверная библиотека Net, обсуждаемые далее, обе используют библиотеку структур данных и фундаментальных алгоритмов Base), то только одна копия A включается в систему.
Автор библиотеки может запретить клиентам доступ к ее исходному тексту (все за и против такой политики обсуждаются в гл. 4). Поскольку используется предкомпиляция, то запрет реализовать просто. В таких случаях пользователи смогут просматривать краткую форму и плоско-краткую форму классов библиотеки, представляющих интерфейс классов, тогда как полный текст классов останется недоступным.
Удаленное выполнение
Интерпретируемый код, сгенерированный после таяния, традиционно известный как байт-код, является независимым от платформы. Для выполнения байт-кода достаточно иметь копию Исполняющей Машины (Execution Engine), известной как 3E и свободно загружаемой через Интернет.
Установка 3E в качестве дополнительного модуля (plug-in) Web-браузера дает возможность непосредственного выполнения кода. 3E автоматически выполнит соответствующий код при активизации пользователем гиперссылки, соответствующей байт-коду. Этот механизм удаленного выполнения стал популярен благодаря Java.
Существует два варианта 3E, отличающиеся набором библиотек. Первый предназначен для использования в Интернете и отличается повышенной безопасностью, он допускает только терминальный ввод-вывод. Второй, предназначенный для Интранет (корпоративных сетей), обеспечивает полноценную поддержку ввода-вывода и ряд других возможностей.
Ведется работа над реализацией средств перевода байт-кода в байт-код Java, что обеспечит дополнительную возможность выполнения на виртуальной машине Java.
Оптимизация
Для максимальной реализации цели C1 одного замораживания кода недостаточно. Для получения законченной, устойчивой системы требуется дополнительная оптимизация:

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

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

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

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

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

Откомпилированный завершенный C код должен быть скомпонован. На этой стадии используется система поддержки выполнения, набор подпрограмм, обеспечивающих интерфейс с операционной системой: файловый доступ, обработка сигналов, распределение памяти.
В случае кросс-разработки встроенной системы можно обеспечить минимальный размер системы, исключив, например, ввод-вывод.
На показана общая схема среды разработки, где в центре находится рабочее место разработчика.
Инструментальные средства высокого уровня
В верхней части присутствуют два инструментальных средства высокого уровня.
Build - интерактивный генератор приложений, основанный на модели Контекст-Событие-Команда-Состояние (см.). Его можно использовать для визуальной разработки графического интерфейса пользователя (GUI) в интерактивном режиме.
Case - средство анализа и проектирования, обеспечивающее возможность рассмотрения системы на высоком уровне абстракции с привлечением графических представлений. В соответствии с принципами бесшовности и обратимости Case позволяет:

  • Разрабатывать системные структуры в графической среде, создавая визуальные представления классов ("пузырьки") и определяя их клиентские отношения и отношения наследования с помощью стрелок с последующей группировкой их в кластеры. В конце Case сгенерирует соответствующие программные тексты (прямое проектирование - forward engineering).
  • Обработать существующий текст класса и воспроизвести соответствующее графическое представление, облегчая анализ и реструктурирование (обратное проектирование - reverse engineering).

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

Библиотеки

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

  • Библиотеки Base, включающие около 200 классов. Они содержат фундаментальные структуры данных - списки, таблицы, деревья, стеки, очереди, файлы и т. д. Наиболее фундаментальные классы составляют библиотеку Kernel, регулируемую международным стандартом (ELKS).
  • Графические библиотеки: Vision для независимого от платформы графического интерфейса пользователя, WEL для Windows, MEL для Motif, PEL для OS/2-Presentation Manager.
  • Net для клиент-серверных разработок позволяет передавать по сети объекты произвольной сложности. Платформы могут быть одинаковыми или разными (использование independent_store делает формат независимым от платформы).
  • Lex, Parse для анализа языка. Parse, в частности, обеспечивает интересный подход к синтаксическому анализу, основанному на последовательном приложении ОО-концепций к синтаксическому анализу (каждое правило моделируется с помощью класса, см. библиографию). Общедоступное средство YOOCC служит препроцессором для Parse.
  • Math - библиотека, обеспечивающая ОО-представление фундаментальных численных методов. Она основана на библиотеке NAG и охватывает большой набор средств. Некоторые из ее концепций были представлены вкурса "Основы объектно-ориентированного программирования", как пример ОО-изменения архитектуры не ОО-механизмов.
  • ObjEdit обеспечивает возможность редактирования объектов в интерактивном режиме в процессе выполнения.
  • Web поддерживает обработку форм, отправленных клиентами на Web-сервер с целью создания CGI-скриптов.

В нижней части показаны библиотеки, используемые для поддержки сохраняемости во время выполнения. Класс 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, отличающейся собственной культурой.
На представлен набор окон среды во время работы. Рисунок черно-белый, но в реальной среде активно используется цвет, особенно для синтаксического выделения различных частей текстов класса. По умолчанию ключевые слова выделены синим цветом, идентификаторы - черным, комментарии - красным. Пользователь может изменить эти настройки.
Инструментальные средства
Среда разработки зачастую состоит из инструментальных средств, построенных на основе функционального подхода, когда каждое средство выполняет определенные функции: просмотр, отладку или форматированную печать исходных текстов. Например, среда Sun Java Workshop (продемонстрированная в сентябре 1996 г.) соответствует этому традиционному образцу, так для поиска предков класса необходимо запустить специальный браузер.
Недостаток такого подхода в его модальности. Сначала необходимо выбрать, что Вы хотите сделать, а затем соответствующий инструмент. Практика разработки программного обеспечения выглядит иначе. В течение сеанса отладки, может внезапно потребоваться средство просмотра: например, обнаруживается, что новая версия подпрограммы вызывает ошибки и необходимо посмотреть оригинал. При просмотре оригинала, возможно, захочется посмотреть класс включения, его краткую форму и т.д . Модальные среды не позволяют этого делать: нужно перейти из "отладчика" в "браузер" и опять искать интересующий элемент (подпрограмму) несмотря на то, что он присутствует в другом окне.
Тем же самым способом, каким мы учились доверять типам объектов, а не функциям, описывающим программную архитектуру, можно создавать инструментальные средства в соответствии с используемыми объектами разработки (development objects). Вместо отладчика или окна браузера необходимы Инструмент Класса (Class Tool), Инструмент Компонента (Feature Tool), Системный Инструмент (System Tool), Инструмент Проекта (Project Tool), Объектный Инструмент (Object Tool) в соответствии с абстракциями, используемыми в ОО-разработке: классами, компонентами, системами (наборами классов), проектами и экземплярами класса во время выполнения ("объектами" в строгом смысле).
Project Tool, например, будет полностью следить за проектом. Он используется для выполнения Melt, Freeze или Finalize. Показан Project Tool в процессе компиляции, показывающий процент выполненной работы.
Class Tool может быть нацелен на конкретный класс, например, LIST ).
Feature Tool совместно с Project Tool во время сеанса отладки () показывают компонент и ход выполнения с механизмами пошаговой отладки, отображают состояние стека (см. значения локальных сущностей в Project Tool). Feature Tool нацелен на компонент call_this_routine класса TEST.
В процессе выполнения можно следить за отдельным объектом с помощью инструментария Object Tool, показанного на.
В окне отображаются различные поля объектов. Одно из них, guardian, содержит непустую ссылку, следуя которой можно просмотреть соответствующий объект, как вскоре будет показано.
Можно использовать столько экземпляров Class Tool, Feature Tool и Object Tool, сколько необходимо, но только один System Tool и один Project Tool доступен в течение сеанса.
Перенастройка и просмотр
Существуют разные способы перенастройки инструмента, например перенастройка Class Tool с LIST на ARRAY. Можно просто ввести новое имя класса в соответствующее поле (если Вы точно его не помните, то можно использовать символ подстановки "*" - ARR* для получения меню со списком соответствующих имен).
Можно также использовать кратко представленный ранее механизм pick-and-throw1 ("выбрать и перетащить") (см.курса "Основы объектно-ориентированного программирования"). Если щелкнуть правой кнопкой мыши на имени класса, например, на CHAIN в Class Tool настроенном на класс LIST, то курсор превратится в "камешек" (pebble) в форме эллипса, показывая, что выбран класс. Далее нужно выбрать "лунку" (hole) такой же формы в Class Tool (том же самом или другом) и положить камешек в лунку, щелкнув правой кнопкой мыши. В качестве лунки может выступать кнопка на панели инструментов или клиентская область окна соответствующего инструментального средства.
Механизм pick-and-drop - обобщение drag-and-drop. Вместо необходимости постоянно удерживать нажатую кнопку операция разбивается на три шага. Сначала выбирается объект щелчком правой кнопки мыши, появляется камешек. Далее в режиме перетаскивания камешек постоянно связан нитью с выбранным элементом
). Наконец, еще один щелчок правой кнопкой мыши уже в целевой лунке. Можно назвать три преимущества по сравнению с обычным drag-and-drop:

  • Нет необходимости постоянно держать нажатой кнопку мыши. При частом выполнении операций drag-and-drop в конце рабочего дня возникает значительная мышечная усталость.
  • При ослаблении давления на кнопку на долю секунды операция может завершиться в неправильном месте, часто с неприятными или катастрофическими последствиями. (Это случилось с автором в Windows 95 при перетаскивании значка, представляющего файл. Потом пришлось долго выяснять, что с этим файлом произошло.)
  • Обычный drag-and-drop не позволяет отменить операцию! Как только объект выбран, с ним необходимо что-то сделать. В механизме pick-and-drop щелчком левой кнопки операцию можно отменить в любой момент.
  • Следует особо отметить, что механизм типизирован, камешек можно положить только в соответствующую лунку. Допускаются некоторые отклонения: аналогично тому, как полиморфизм позволяет присоединить объект RECTANGLE к сущности POLYGON, можно положить компонент в лунку класса и увидеть соответствующий класс с подсвеченным компонентом. Это еще один пример непосредственного применения концепций метода при построении среды. (Здесь различие с механизмами drag-and-drop не является критическим, поскольку они также могут быть ограниченно типизированными.)

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

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

ancestors (предки) ;

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

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

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

и так далее. Щелчок на одной из них отобразит текст класса в соответствующем формате. Например, если нажимается кнопка Ancestors (Предки), то Class Tool отобразит структуру наследования .
В любом окне инструментальных средств все важные элементы интерактивны (clickable). Это означает, что для получения информации о классе CURSOR_STRUCTURE достаточно щелкнуть на нем правой кнопкой мыши и использовать pick-and-drop для перенастройки этого или другого инструментального средства на выбранный класс. После этого можно выбрать другой формат, например краткую форму. Далее можно снова применить pick-and-drop и настроить Feature Tool на интересующую Вас подпрограмму. В Feature Tool можно просмотреть предысторию, то есть все приключения компонента в играх наследования: все версии после переименования, переопределения и т. д. Для любого упомянутого класса и компонента можно вновь использовать pick-and-drop.
В процессе сеанса отладки, показанного ранее , необходимую информацию можно также получить с помощью pick-and-drop. Щелчок правой кнопкой на объекте 0X142F18 (внутренний идентификатор, сам по себе ничего не говорящий, но интерактивный) позволяет запустить Object Tool, использованный для отображения экземпляра PERSON . Этот инструментарий обеспечит просмотр всех полей и ссылок объекта, также интерактивных. Так можно легко исследовать структуры данных во время выполнения.
Можно осуществить вывод в каждом из доступных форматов (HTML, TЕX, RTF, FrameMaker MML, troff), причем компактный язык описаний позволяет определить собственные форматы или модифицировать существующие. Вывод может быть отображен, сохранен с файлами класса или в отдельном каталоге для подготовки документации проекта или кластера.
Механизмы просмотра не делают никаких различий между встроенными библиотеками и классами, определенными разработчиком. Если используется базовый класс INTEGER, то его точно так же можно просматривать в Class Tool в любом доступном формате. Автор библиотеки может закрыть доступ к исходному тексту, но краткая и плоско-краткая формы доступны и остаются интерактивными. Это вполне соответствует общим принципам однородности и бесшовности. В течение всех этапов разработки ПО используются единые концепции, насколько это возможно.


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

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

Некоторые лунки, известные как "кнопки-лунки" (buttonholes), одновременно выполняют функции кнопки. Например, щелчок левой кнопкой на лунке Stop Point приведет к отображению в Project Tool информации о точках останова. Это представление тоже интерактивно и позволяет легко удалить существующие точки останова или добавить новые.
Систематическое применение этих методов обеспечивает механизм просмотра, при котором все представляющие интерес элементы являются гиперссылками. Такое решение гораздо предпочтительнее модальных сред, постоянно вынуждающих Вас задавать себе вопросы: "Я просматриваю? О нет, я отлаживаю, так что придется запустить браузер. А какой инструментарий нужно запустить для получения документации?"
Нет ни отладки, ни просмотра, ни документирования, ни редактирования. Есть единый процесс создания ПО, и инструментальные средства должны в любой момент обеспечить любые необходимые действия с объектами.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика