Инструментальное ПО

4.4. Возникновение систем программирования

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

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

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

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

Поскольку процессу компиляции всегда соответствует типичная последовательность команд, разрабатывать для этой цели командный файл в операционной системе неэффективно и неудобно. Для написания подобных командных файлов пользователям компиляторов был предложен специальный командный язык, который обрабатывался интерпретатором команд компиляции – программой make (от английского глагола – строить, делать). Командный язык Makefile позволял в достаточно гибкой и удобной форме описать весь процесс создания программы от порождения исходных текстов до подготовки ее к выполнению [12].

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

Такая структура средств разработки существовала достаточно долгое время, а в некоторых случаях она используется и по сей день (особенно при создании системных программ). Ее широкое распространение было связано с тем, что сама по себе вся эта структура средств разработки была очень удобной при пакетном выполнении программ на компьютере, что способствовало ее повсеместному применению в эпоху mainframe с операционными системами типа Unix.

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

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

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

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

Создание интегрированных сред разработки стало возможным благодаря бурному развитию персональных компьютеров и появлению развитых средств интерфейса пользователя (сначала текстовых, а потом и графических). Их появление на рынке определило дальнейшие развитие такого рода технических средств. Пожалуй, первой удачной средой такого рода можно признать интегрированную среду программирования Turbo Pascal на основе языка Pascal производства фирмы Borland [19]. Ее широкая популярность определила тот факт, что со временем все разработчики компиляторов обратились к созданию интегрированных средств разработки для своих продуктов.

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

Дальнейшее развитие средств разработки также тесно связано с повсеместным распространением развитых средств графического интерфейса пользователя. Такой интерфейс стал неотъемлемой составной частью многих современных ОС и так называемых графических оболочек. Со временем он стал стандартом де-факто практически во всех современных прикладных программах. Это не могло не сказаться на требованиях, предъявляемых к средствам разработки программного обеспечения. В их состав были сначала включены соответствующие библиотеки, обеспечивающие поддержку развитого графического интерфейса пользователя и взаимодействие с функциями API (Application Program Interface, прикладной программный интерфейс) операционных систем [22]. А затем для работы с ними потребовались дополнительные средства, обеспечивающие разработку внешнего вида интерфейсных модулей. Такая работа была уже более характерна для дизайнера, чем для программиста.

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

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

Простая среда разработки включает в себя редактор текста, компилятор и/или интерпретатор, средства автоматизации сборки и отладчик. Когда эти компоненты собраны в единый программный комплекс, говорят об интегрированной среде разработки (Integrated development environment – IDE). Такая среда представлена одной программой, не выходя из которой можно производить весь цикл разработки. В состав комплекса, кроме перечисленных выше компонент, могут входить средства управления проектами, система управления версиями, разнообразные инструменты для упрощения разработки интерфейса пользователя, стандартные заготовки ("мастера"), упрощающие разработку стандартных задач, и др.

Обычно среда разработки включает в себя текстовый редактор, компилятор и/или интерпретатор, средства автоматизации сборки и отладчик. Иногда она также содержит средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов для использования при объектно-ориентированной разработке ПО. Хотя и существуют среды разработки, предназначенные для нескольких языков программирования, такие как Eclipse, NetBeans, Embarcadero RAD Studio или Microsoft Visual Studio, обычно среды разработки предназначается для одного определенного языка программирования – как, например, Visual Basic, Delphi, Dev-C++.

Иногда достаточно использовать только одну интегрированную среду разработки, но для больших проектов в среду разработки включаются разнородные продукты разных фирм, разных версий. Пример такого набора: файловый менеджер, набор вспомогательных утилит и пакетных файлов, С++Builder – как IDE, PLSQL Developer – для работы с СУБД Oracle, Cristal Reports – для создания отчетов, StarTeam – для ведения версий и поддержки коллективной работы.

Операционная среда разработки MS Visual Studio на сегодняшний день является предпочтительным выбором многих разработчиков, работающих на платформе Windows. В процессе своего развития MS Visual Studio имела несколько версий [27].

1. Visual Studio 97 – первая выпущенная версия Visual Studio. В ней впервые были собраны вместе различные средства разработки ПО. Система была выпущена в двух версиях: Professional и Enterprise. Она включала в себя Visual Basic 5.0, Visual C++ 5.0, Visual J++ 1.1, Visual FoxPro 5.0, впервые появилась среда разработки ASP – Visual InterDev. Visual Studio 97 была первой попыткой Microsoft создать единую среду для разработки на разных языках программирования: Visual C++, Visual J++, Visual InterDev и MSDN использовали одну среду, называемую Developer Studio. Visual Basic и Visual FoxPro применяли отдельные среды для разработки.
2. Visual Studio 6.0 вышла в июне 1998 г.. Это последняя версия Visual Studio, работающая на платформе Win9x. По-прежнему популярна среди программистов, использующих Visual Basic. Данная версия являлась основной средой разработки приложений под Windows от Microsoft, до появления платформы .NET.
3. Visual Studio .NET (кодовое имя Rainier; внутренняя версия 7.0) выпущена в феврале 2002 года (включает .NET Framework 1.0). Service Pack 1 для Visual Studio .NET (2002) выпущен в марте 2005 г.
4. Visual Studio .NET 2003 (кодовое имя Everett; внутренняя версия 7.1) появилась в апреле 2003 года (включает .NET Framework 1.1). Service Pack 1 для Visual Studio .NET 2003 выпущен 13 сентября 2006 г.
5. Visual Studio 2005 (кодовое имя Whidbey; внутренняя версия 8.0) выпущена в конце октября 2005 года, последняя официально работающая на Windows 2000 (включает .NET Framework 2.0). В начале ноября 2005 года также вышла серия продуктов в редакции Express: Visual C++ 2005 Express, Visual Basic 2005 Express, Visual C# 2005 Express и др.[ 29] 19 апреля 2006 г. редакция Express стала бесплатной. Service Pack 1 для VS2005 [30] и всех Express-редакций [31] выпущен 14 декабря 2006 года. Дополнительный патч для SP1, решающий проблему совместимости с Windows Vista выпущен 6 марта 2007 г.
6. Visual Studio 2008 (кодовое имя Orcas) выпущена 19 ноября 2007 г., одновременно с .NET Framework 3.5. Нацелена на создание приложений для ОС Windows Vista (но поддерживает и XP), Office 2007 и веб-приложений. Включает в себя LINQ, новые версии языков C# и Visual Basic. В студию не вошел Visual J#. С 28 октября 2008 года впервые доступна версия на русском языке.
7. Visual Studio 2010 (кодовое имя Hawaii, для Ultimate – Rosario) выпущена 12 апреля 2010 года вместе с .NET Framework 4.0. Visual Studio включает поддержку языков C# 4.0 и Visual Basic .NET 10.0, а также языка F#, отсутствовавшего в предыдущих версиях.

Среда Visual Studio 2010 позволяет эффективно создавать сложные приложения в течение короткого периода времени. Модель данной среды существенно богаче ранних версий и использует такие понятия, как решение (solution), проект, пространство имен (namespace) и сборка (assembly). Понятие проекта присутствует во многих средах, например, в среде Delphi. Файл проекта содержит перечисление исходных файлов и прочих ресурсов, из которых система будет строить приложение. В решение среды Visual Studio входят несколько проектов, которые могут быть зависимыми или независимыми друг от друга. Выделяется стартовый проект. Понятие сборки исходит из общеязыковой исполнительной среды CLR (Common Language Runtime). Среда CLR является наиболее революционным изобретением, с появлением которого процесс написания и выполнения приложений становиться принципиально другим.

Компилятор преобразует файлы с исходными кодами в коды на промежуточном языке MSIL (Microsoft Intermediate Language). Вместе с метаданными эти коды записывают PE-файлы (Portal Executable), имеющие расширение exe или dll в зависимости от типа проекта. Также может быть получен модуль с расширением netmodule, который не содержит метаданных.

Всего имеется 12 типов проектов. При загрузке PE-файлы "на лету" транслируются в команды реального процессора. Каркас Framework.NET, обеспечивающий выполнение программ, не входит в Visual Studio, а является настройкой над операционной системой. Это аналог виртуальной Java-машины.

Сборка является минимальной единицей для развертывания приложений. Каждый тип сборки характеризуется уникальным идентификатором, идентифицируется цифровой подписью автора и уникальным номером версии. Между сборками и пространствами имен существует следующее соотношение. Сборка может содержать несколько пространств имен. В то же время пространство имен может занимать несколько сборок. Сборка может иметь в своем составе как один, так и несколько файлов, которые объединяются в так называемом манифесте или описании сборки.

На уровне языка C# пространства имен, аналогично пакетам в Java, служат для структурирования проекта. Пространство имен включает один или несколько классов. В одном исходном файле может определяться несколько пространств имен и в тоже время одно пространство имен может определяться в нескольких файлах. И даже класс может располагаться в нескольких файлах (partial classes).

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

Интересной и перспективной представляется операционная среда Eclipse, разработанная в фирме IBM [34]. Первоначальной целью проекта было создание корпоративного стандарта IDE для разработки программ на разных языках под различные платформы. Потом проект был переименован в Eclipse и выделен в открытый доступ. Лицензия позволяет бесплатно использовать код и среду разработки и при этом создавать закрытые коммерческие продукты. Благодаря этому система получила широкое распространение и для многих организаций стала корпоративным стандартом для разработки приложений.

Экосистема Eclipse относится к консолидированным технологиям, годом широкого распространения которой является 2007-й. Система реализована на языке Java и изначально представляла собой полноценную интегрированную среду для языка Java. В дальнейшем стали поддерживаться и другие языки. Первые версии были неудобны, поскольку целевой продукт вынуждено включал лишнюю функциональность. Начиная с третьей версии была переработана архитектура всей системы с целью максимального разделения модулей и взаимосвязи между ними. При этом модули Eclipse, образованные из согласованных наборов классов, давали функциональность целых подсистем, таких как подсистемы помощи, обновления продукта, обучения, презентации, многоязыковой поддержки и множество других. Разрабатывая приложение, теперь можно постепенно наращивать функциональность, подключая уже готовые бесплатные компоненты. В терминологии Eclipse эти компоненты называются "подключаемыми модулями", или "плагинами" (Plugins). Такая технология становится типичной для развитых операционных сред. Платформа на основе этой технологии получила название RCP (Reach Client Platform), а приложения, соответственно, названы RCP-приложениями.

Графический интерфейс Eclipse построен с применением графической библиотеки SWT, которая опирается на графику используемой операционной системы. Предусмотрена возможность создания настраиваемых стилей, которые позволяют произвольно менять как внешний вид приложения, так и поведение составляющих его компонентов. Многооконный интерфейс MDI, реализованный в ОС Windows еще в версии 3.1, заменен на альтернативный интерфейс, основанный на закладках. Этот интерфейс похож на интерфейс MS Visual Studio, но имеет и отличия. Режимы работы могут объединяться в одну панель либо размещаться каждый в отдельной панели. Имеется встроенный механизм чередования панелей или механизм "быстрых" панелей, когда они не занимают место на экране, а вызываются кнопками по необходимости.

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

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

Такая, сложная на первый взгляд, организация интерфейса оказывается удобной именно благодаря использованию проекций. Проекцию можно рассматривать как набор визуальных компонент для выполнения конкретно поставленных задач. Например, проекция "Java" содержит необходимый набор для разработки java-приложений, а проекция "CVS" предназначена для оперирования удаленным репозиторием проектов при коллективной разработке. Каждая проекция имеет свой набор меню и панелей инструментов, состав которых можно настраивать и сохранять. Начальный макет проекции определяется разработчиком, но его можно изменять, открывая и закрывая панели и встраивая их в различные места окна рабочей среды.

Основные визуальные компоненты рабочей среды – панели и редакторы.

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

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

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

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

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