Опубликован: 06.10.2011 | Доступ: свободный | Студентов: 1678 / 90 | Оценка: 4.67 / 3.67 | Длительность: 18:18:00
Лекция 5:

Инструментарий

< Лекция 4 || Лекция 5: 123 || Лекция 6 >

4.3. Репозиторий проекта "в целом"

Управление сборкой, контроль версий поднимают специфические проблемы управления проектом. Дополняя эти частные решения, часто интегрируя их, в последние годы появились платформы "общего репозитория проекта", предоставляя общее хранилище проекту в целом. Одной из наиболее известных таких систем является SourceForge. Другим примером является разработанная в ETH система Origo.

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

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

4.4. Просмотр и документирование

Большие программные системы включают многие компоненты, связанные различными отношениями, такими как клиентские отношения и отношения наследования в ОО-мире. Методы в этом мире подвергаются многим перевоплощениям в своем долгом путешествии через поколения наследования – классы могут переопределять их, переименовывать, отменять их определение.

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

  • Кто является родителями класса С? Его наследники, предки, потомки? Его клиенты, поставщики?
  • Какой из предков впервые определил метод f?
  • У какого предка я могу найти версию f, применяемую в классе С?

Связанной задачей является задача генерирования документации по тексту ПО. Возможно, вам потребуются версии класса на разных уровнях абстракции (контрактный облик или интерфейс класса), в разных форматах (HTML, PostScript). Насколько возможно, этот процесс должен быть автоматизирован и должен извлекать информацию из самого текста ПО, а не из различных документов, его сопровождающих. Если пользоваться внешней информацией, то всегда есть риск, что она устарела, не поспевая за изменениями ПО. Так как код может не содержать всю требуемую информацию, некоторые языки программирования предоставляют специальные конструкции для этих целей. Так, языки Java и C# позволяют задавать документируемые комментарии, обрабатываемые специальным инструментарием; в языке Eiffel для этих целей введено специальное предложение note, которое может и должно появляться в классах Eiffel, позволяя описать специальные свойства класса.

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

4.5. Метрики

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

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

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

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

4.6. Интегрированная среда разработки

Прогресс, достигнутый в разработке индивидуальных инструментов программной инженерии – компиляторов, интерпретаторов, редакторов, компоновщиков, средств управления конфигурацией, – привел к объединению всех этих инструментов в интегрированную среду разработки – IDE (Integrated Development Environment). Интеграция означает, что для разработчика среда представляется единым инструментом, обычно интерактивным и графическим (поддерживается также возможность работы с командной строкой). Пользователи IDE могут выполнять в ней все задачи, связанные с разработкой ПО, или, по крайней мере, большинство таких задач. Вместо того чтобы готовить текст в редакторе, сохранять его в файле, потом переходить к новому инструменту – компилятору, затем к отладчику, – все это теперь можно выполнять в одном месте – в среде разработки.

Типичный графический интерфейс пользователя – GUI – все еще предоставляет разные подокна – редактора, компилятора, отладчика и так далее, но теперь все они связаны друг с другом. Их можно комбинировать для исследования различных свойств класса: видеть текст в окне редактора, структуру в окне документации, можно запустить на выполнение один из методов в окне отладчика. Можно обмениваться информацией между окнами, используя механизм перетаскивания – "drug and drop".

Одной из наиболее известных IDE является среда Eclipse, относящаяся к системам с открытым кодом и изначально ориентированная на Java. Из коммерческих сред следует отметить среду Microsoft Visual Studio.

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

4.7. IDE: EiffelStudio

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

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

Реализация EiffelStudio использует свою собственную технологию; на момент написания среда включала примерно 2 миллиона строк Eiffel-кода (примерно 6000 классов) плюс поддержка С кода для исполняемой среды (runtime).

Общая структура

На следующем рисунке показаны главные компоненты EiffelStudio:

Главные компоненты EiffelStudio

увеличить изображение
Рис. 4.7. Главные компоненты EiffelStudio

Центром среды – ее машиной – является EiffelStudio. Она обеспечивает пользователя ключевыми механизмами: просмотром и документацией, компиляцией, отладкой, взаимодействия между текстуальным и графическим (Diagram Tool) способом задания структуры, метрическим инструментарием.

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

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

Рисунок показывает два механизма компиляции. Компилятор может сгенерировать C-код, используемый здесь в качестве переносимого ассемблерного языка, который на целевой машине компилируется в машинный код. Для платформы .Net компилятор создает байт-код для этой платформы, известный как промежуточный язык CIL (Common Intermediate Language), который затем JIT-компилятором транслируется в окончательный код. Для платформы .Net используется ее собственная исполняемая среда, но в схеме, базируемой на C, результат компиляции компонуется с собственной исполняемой средой EiffelStudio.

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

Просмотр и документация

Возможности просмотра и документирования в EiffelStudio разработаны с особой тщательностью. Работа пользователя в студии характеризуется метафорой "выбрать и опустить" (pick and drop) – выбираем "камешек", представляющий программный элемент, и опускаем его в "лунку" для выполнения подходящей операции над этим элементом. Более детально:

  • выбираемыми элементами могут быть классы, методы, кластеры и другие элементы, такие как сообщение об ошибке;
  • запускаем процесс "выбрать и опустить" щелчком правой кнопки мыши на любом представлении (имя, значок) выбранного элемента, появляющегося в любом месте;
  • после захвата элемента курсор меняет свой вид, его изображение зависит от захваченного элемента: – для класса, – для метода;
  • вы опускаете значок в лунку опять-таки щелчком правой кнопки мыши. Во многих случаях роль лунки может играть все окно или подокно. Например, если класс опустить в окно редактора, то в окне появится текст класса и станет возможным его редактирование;
  • для удобства нет необходимости при перемещении камешка удерживать нажатой кнопку мыши, как это делается в распространенном механизме "перетащить и опустить". Один щелчок делается для захвата элемента и один для его размещения в нужном месте. Щелчок левой кнопки позволяет отменить операцию.

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

Реализаторы метода

увеличить изображение
Рис. 4.8. Реализаторы метода

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

Отображать такую информацию, как и любой другой облик, можно в разных форматах – HTML, PDF, RTF (Microsoft Word) и других форматах (достаточно просто добавить произвольный формат, написав для него соответствующий "фильтр"). При командной работе предоставляемые возможности облегчают работу, позволяя обмениваться информацией, начиная от наиболее детализированной формы – исходного кода, и заканчивая абстрактными представлениями – обликами и диаграммами.

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

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

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

Это естественное желание разработчика задает ограничение на проектирование окружения.

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

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

Тающий лед

Рис. 4.9. Тающий лед

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

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

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

Механизм таяния автоматический. Изменения могут быть сделаны либо путем редактирования текста в EiffelStudio, либо внешним инструментарием. При нажатии кнопки компиляции Compile механизм анализа зависимостей EiffelStudio находит минимальное множество элементов (это могут быть отдельные методы, а не обязательно классы), которые должны быть перекомпилированы. Сюда входят не только те элементы, которые вы явно изменили, но и другие, зависящие от них методы. Скрытие информации позволяет делать этот процесс более эффективным, поскольку, если метод изменился, но эти изменения не затронули его интерфейс, то клиентов класса перекомпилировать не нужно. Анализ не требует вмешательства пользователя, в частности, файла сборки или его эквивалента: как отмечалось ранее, семантической информации, присутствующей в тексте, вполне достаточно. Вычисление зависимостей в EiffelStudio выполняется автоматически. Это одно из преимуществ инструментов, встроенных в IDE и специально предназначенных для статически типизированного ОО-языка.

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

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

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

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

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

4.8. Ключевые концепции, введенные в этой лекции

  • Инструментарий ПО для программной инженерии играет ту же роль, что и средства CAD для проектировщиков и инженеров, работающих в архитектуре, электронике, машиностроении.
  • Для реализации программ, написанных на языке высокого уровня, применяются два подхода: компиляция, преобразующая программу в исполняемый код, и интерпретация, которая предлагает машину, непосредственно выполняющую исходную программу.
  • Некоторые реализации комбинируют компиляцию и интерпретацию. Например, компиляция может производить не машинный код, а код на промежуточном языке, который затем будет интерпретироваться. Примером смешанной стратегии компиляции и интерпретации является технология тающего льда, которая поддерживает возрастающую разработку путем интерпретации частей программы, подвергшихся изменению, оставляя остальную часть программы скомпилированной.
  • Компиляторы выполняют несколько задач: лексический и синтаксический анализ, семантический анализ, генерацию кода и его оптимизацию. Традиционно эти задачи решались на нескольких последовательных "проходах" компилятора. Теперь компиляторы строят и декорируют базисные структуры данных – АСТ и таблицу идентификаторов.
  • Компоновщик или линкер связывает скомпилированные модули, разрешая ссылки.
  • Загрузчик загружает программу в память, готовя ее к выполнению.
  • Исполняемая среда (runtime) обеспечивает поддержку в период выполнения программы.
  • Редакторы и CASE-инструментарий помогает строить программу из текстового и графического ввода. При работе с графикой и текстом должно поддерживаться "циклическое обращение".
  • Инструментарий компоновки, такой как Make, собирает систему из ее компонентов на основе описания зависимостей.
  • Инструментарий контроля версий сохраняет последовательные версии частей программы, храня различия (diffs) между версиями.
  • Средства просмотра и документирования облегчают анализ и понимание больших программных систем.
  • Интегрированная среда разработки – IDE – поддерживает основные задачи разработки ПО, предоставляя взаимосвязанную коллекцию инструментов с согласованным интерфейсом.

Новый словарь

Branching Ветвление Browsing Просмотр
Bytecode Байт-код CASE Средства автоматизации программиста
Commit Фиксация (транзакций) Debugger Отладчик
Configuration management Управление конфигурацией Diff Инструментарий, определяющий различия
DSL Проблемно-ориентированный язык IDE Интегрированная среда разработки
Jitter JIT-компилятор Melting Ice Технология "тающий лед"
Jitting Компиляция байт-кода Pass (of a compiler) Проход компилятора
Metric tool Метрический инструментарий Runtime Исполняемая среда
Round-trip engineering Циклическое обращение. Ограничение при взаимных преобразованиях текста и графики Update Обновление
Version control Контроль версий Virtual machine Виртуальная машина

4.9. Упражнения

4.9.1. Словарь

Дайте точные определения терминам словаря.

4.9.2. Карта концепций

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

4.9.3. Интерпретатор и компилятор

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

< Лекция 4 || Лекция 5: 123 || Лекция 6 >