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

Цель лекции

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

1.1. Введение

Данный курс познакомит Вас с возможностями новой версии интегрированной среды Visual Studio 2013 и использованием данной среды для облачных вычислений на платформе Microsoft Azure.

1.2. Концепция интегрированной среды разработки приложений

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

Использование интегрированной среды - один из возможных подходов к разработке программ. Альтернативой ему является более ранний, традиционный подход системы UNIX, основанный на использовании набора инструментов (toolkit, toolbox), родственных по тематике и функциональности, но не объединенных в одну интегрированную интерактивную среду и подчас (в ранних версиях системы UNIX) вызываемых в режиме командной строки (command line interface).

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

Одной из первых интегрированных сред стала среда Turbo Pascal [1] фирмы Borland, руководителем разработки которой в середине 1980-х гг. стал Филипп Кан, ученик Никлауса Вирта.

Корпорация Microsoft внесла особо выдающийся вклад в развитие интегрированных сред, благодаря созданию и развитию среды Visual Studio, которая является одним из лучших образцов современной интегрированной среды. Ее новую версию, Visual Studio 2013, мы и рассмотрим в данном курсе.

1.3. История интегрированных сред

Идея интегрированных сред достигла еще большего развития к середине 1980-х гг., когда появились две группы популярных интегрированных сред:

• Турбо-среды (Turbo Pascal, Turbo C, Turbo C++, Delphi и др.) фирмы Borland для поддержки программирования на этих языках, реализованные сначала для операционной системы MS DOS, затем - для ОС Windows;
• GNU Emacs [2] - многоязыковая и многоплатформная интегрированная среда разработки, реализованная для MS DOS, затем для Windows, OpenVMS и для Linux. Среди сотрудников моей группы разработчиков, работавших с фирмой Sun Microsystems в 1990-х гг., было немало пользователей и энтузиастов среды GNU Emacs, благодаря ее реализации для платформы Solaris.

Следует также упомянуть интегрированную среду тех лет для разработки программ на объектно-ориентированном языке Smalltalk [3] фирмы Xeror PARC - одну из первых интегрированных сред ООП, в которой впервые появилось понятие байт-кода как бинарной постфиксной формы промежуточного представления программы и понятие just-in-time (JIT, динамического) компилятора, выполняющего при первом вызове метода его компиляцию в платформно-зависимый (native) код целевого компьютера.

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

Турбо-среды имели встроенный механизм сборки (build) для полной компиляции всех исходных текстов проекта в бинарный код, а также режим make (F9), аналогичный функциональности классической утилиты make системы UNIX, для повторной компиляции только измененных модулей исходного текста.

Самым важным нововведением в среде Турбо-Паскаль было расширение входного языка объектно-ориентированными концепциями (класс, объект) и конструкцией unit (модуль), воплощающей в себе идею независимой единицы компиляции (compilation unit). Поддержка ООП появилась в версии 5.5. Впоследствии эти идеи были развиты, уже на платформе Windows, в новых версиях интегрированных сред фирмы Borland - Borland Pascal и Delphi (язык программирования фирмы Borland, развивающий идеи Паскаля в сочетании с ООП).

Я со своей группой в начале 1990-х гг. разработал большое число инструментов и приложений на объектно-ориентированном Турбо-Паскале (5.5, 6.0), объемом до нескольких десятков тысяч строк исходного текста (компиляторов, экспертных систем, систем расчета непотопляемости судов, для ВМФ, и др.), используя, по современным понятиям, более чем скромную конфигурацию оборудования - IBM PC с 640 килобайтами памяти под управлением MS DOS. Для размещения в памяти попеременно больших исполняемых модулей использовалась оверлейная структура (overlay). Ограничение в 640 килобайт (максимальный размер исполняемой программы в MS DOS) накладывало весьма серьезные ограничения на размер единицы компиляции, даже если фактически память компьютера имела больший объем, например, 2 МБ. Вследствие ограниченного объема памяти приходилось искусственно разбивать модули (units) на части. Тем не менее, комфортные интегрированные Турбо-среды были для нас просто бальзамом после неуклюжей поддержки основных инструментов на традиционных mainframe-компьютерах, на которых приходилось работать в режиме командной строки. Производительность работы программистов возросла в Турбо-средах просто фантастически, в десятки раз. "И уйду на PC, и утешусь на Турбо-Паскале" - пели мы в нашем программистском фольклоре тех лет.

1.4. Основные возможности современных интегрированных сред

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

• Единая интерактивная оболочка, обеспечивающая вызов всех других компонент, не выходя из среды, с широким использованием функциональных клавиш;
• Текстовый редактор для набора и редактирования исходных текстов программ. В недавнем прошлом в отечественной традиции использовался именно термин исходный текст, впоследствии стал использоваться термин исходный код (source code);
• Система поддержки сборки (build), то есть компиляции проектов из исходных кодов, включающая компилятор с исходного реализуемого языка и компоновщик (linker) объектных бинарных кодов в единый исполняемый код (загрузочный модуль); компоновщик используется либо штатный, входящий в состав операционной системы, либо специфичный для данной среды;
• Отладчик (debugger) для отладки программ в среде с помощью типичного набора команд: установить контрольную точку остановки; остановиться в заданной процедуры (методе); визуализировать значения переменных (или, на более низком уровне, регистров и областей памяти).

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

В современных версиях интегрированных сред появились также следующие возможности (компоненты):

• Профилировщик (profiler) - инструмент для накопления и анализа статистических данных, полученных в результате исполнения программы под управлением интегрированной среды: число вызовов процедур (методов), объем памяти, используемой при выполнении программы, и т.д.
• Рефакторинг (refactoring) [4] - инструментарий систематических групповых модификаций программ в среде, без принципиальных изменений их функциональности, с целью улучшения кода. К типичным подобным действиям относится, например, изменение имени метода в его определении и во всех использованиях, добавление его аргумента, добавление try/catch - блока для обработки ранее не учтенного исключения и т.п.
• Генератор тестов (unit test generator) - инструмент для генерации типовых тестов для тестирования модулей (units) - методов или процедур - с различными возможными сочетаниями значений аргументов; типичные примеры - инструмент JUnit в интегрированных Java-средах и аналогичный инструмент NUnit в среде Visual Studio
• Система управления версиями исходных кодов (source code control system) или инструмент интеграции среды с одной из существующих версионных систем (CVS, RCS, Mercurial, Visual SourceSafe и др.) - поддержка управления версиями файлов исходных кодов проектов в среде при сопровождении программ
• Инструменты поддержки командной разработки программ (teamwork) - этапов жизненного цикла программы (требования и спецификации, проектирование, реализация, тестирование), распределения заданий по разработке среди участников команды программистов, контроля выполнения заданий менеджером проекта. В среде Visual Studio такая компонента называлась сначала Team Foundation Server (TFS), а, начиная с версии Visual Studio 2013, она реализована в виде облачного интерфейса и получила название Visual Studio Online.
• Инструменты анализа кода (code analysis) - его семантической корректности: отсутствие некоторых видов ошибок, обнаруживаемых обычно при исполнении, например, недостижимые условия; отсутствие необходимых проверок и полномочий безопасности и др. Подробнее об этих особенно важных для меня, в силу моих профессиональных интересов, возможностях рассказано ниже, в "Visual Studio 2013 и ее возможности для надежных и безопасных вычислений (trustworthy computing)" . Эти возможности соответствуют духу и принципам надежных и безопасных вычислений (trustworthy computing), сформулированным в 2002 г. корпорацией Microsoft и последовательно воплощаемым этой фирмой в жизнь. Также в современные среды встраиваются инструменты анализа кода в терминах метрик (metrics), характеризующих его сложность, - например, цикломатическое число графа потоков управления в программе, степень сцепления (взаимосвязанности) классов и т.д.
• Инструменты визуализации сгенерированного бинарного кода - методов, переменных, их имен и т.д. Например, в среде Visual Studio для этой цели имеется утилита ildasm (IL disassembler), позволяющая визуализировать единый промежуточный (бинарный) код платформы .NET - Common Intermediate Language - CIL, сгенерированный одним из компиляторов среды
• Инструменты "запутывания" кода (obfuscation), выполняющие именно с этой целью замену имен элементов кода - классов, методов, полей и т.д. на непонятные, "случайные", "запутанные" имена, с целью затруднения изучения декомпилированного бинарного кода, для защиты от "взлома" кода злоумышленниками, которые хотят несанкционированным образом присвоить себе новые идеи, содержащиеся в коде, либо изучить его со злонамеренными целями организации атак. Например, в среде Visual Studio имеется "штатный" обфускатор - DotFuscator.
• Поддержка создания различных видов программных проектов (projects) и решений (solutions) на основе типовых шаблонов кода (code patterns); механизм разработки расширений (plug-ins, add-ins, add-ons). При современной разработке программ подчас требуется создавать очень сильно отличающиеся друг от друга разновидности приложений и инструментов - консольные (простейшие) приложения, Web-приложения и Web-сервисы, мобильные приложения, облачные приложения и др. Для каждой из этих разновидностей требуется разработка специфической структуры файлов исходного кода, а также конфигурационных файлов (configuration files), специфицирующих, например, полномочия безопасности кода, Web-конфигурации и др. Современные интегрированные среды автоматизируют создание различного рода проектов, предоставляя шаблоны исходного кода и генерируя автоматически необходимые для проекта конфигурационные файлы. Трудно представить в настоящее время программирование без использования готовых шаблонов кода, которое неизбежно будет чревато ошибками, - например, очень легко забыть вручную создать тот или иной файл, неотъемлемую часть проекта, либо упустить из вида какой-либо важный фрагмент кода (например, инициировать асинхронный вызов, но не предусмотреть парный к нему вызов, его завершающий). Поэтому поддержка интегрированными средами различных видов проектов особенно важна. Кроме того, набор возможных видов проектов в современных интегрированных средах является расширяемым, т.е. разработчик может ввести в среду при необходимости новый вид проекта. Например, при реализации нашего инструмента аспектно-ориентированного программирования Aspect.NET как расширения интегрированной среды Visual Studio мы ввели новый вид проекта - аспект (aspect) с соответствующим шаблоном кода
• Поддержка моделирования структуры программ на языке моделирования UML (Unified Modeling Language) [5]. Современная версия языка UML (2.x) обеспечивает построение моделей различного рода программ и соответствующих этим моделям диаграмм. Кроме того, UML поддерживает разработку моделей деятельности при разработке программ и взаимодействия разработчиков между собой (activity diagrams). Современные интегрированные среды поддерживают испрользование языка UML в двух напрвлениях: генерация модели и соответствующей диаграммы по исходному коду и, наоборот, генерация (шаблона) исходного кода по разработанной модели.