Определение среды разработки. Современные средства разработки приложений

Алексей Федоров, Наталия Елманова

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

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

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

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

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

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

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

Средства разработки, ориентированные на конкретные СУБД

Лет десять-двадцать назад во многих приложениях, использующих базы данных, функции клиентского API вызывались из кода, написанного на одном из языков программирования, чаще всего на C. Достаточно взглянуть на описание API клиентской части почти любой серверной СУБД - и вы найдете немало примеров наиболее типичных фрагментов кода, например, для регистрации пользователя, выполнения запросов и т.п. Однако достаточно быстро разработчикам СУБД стало ясно, что трудозатраты, связанные с написанием подобного кода, можно существенно сократить, собрав в библиотеки наиболее типичные фрагменты кода и наиболее часто встречающиеся элементы пользовательского интерфейса (пусть даже и для алфавитно-цифровых терминалов), оформив эти библиотеки в виде отдельного продукта и добавив к нему среду разработки и утилиты проектирования пользовательских форм для просмотра и редактирования данных, а также отчетов. Именно так и появились первые средства разработки, ориентированные на конкретные СУБД, такие, например, как Oracle*Forms (предшественник нынешнего Oracle Forms Developer ).

Продукты этого класса на рынке средств разработки имеются и сегодня. Почти все производители серверных СУБД производят и средства разработки приложений. В подавляющем большинстве случаев современные версии этих средств разработки поддерживают доступ к СУБД других производителей как минимум с помощью одного из универсальных механизмов доступа к данным (ODBC, OLE DB, BDE). Однако доступ к "своей" СУБД обычно осуществляется максимально эффективным способом, то есть с помощью клиентских API, объектов, содержащихся в библиотеках клиентской части серверных СУБД, специальных классов для доступа к данным этой СУБД либо за счет реализации драйверов для универсальных механизмов доступа к данным, способной учитывать специфические особенности данной СУБД.

В отдельную категорию можно выделить среды разработки настольных СУБД. В статье данного цикла, посвященной настольным СУБД, мы уже отмечали, что подавляющее большинство настольных СУБД, доживших до сегодняшнего дня, таких как Microsoft Visual FoxPro , Microsoft Access, Corel Paradox, Visual dBase, поддерживают доступ к серверным СУБД, как минимум, с помощью универсальных механизмов доступа к данным, что позволяет условно отнести их и к категории средств разработки. Отметим, однако, что в настоящее время создание приложений в архитектуре "клиент-сервер" с их помощью - явление нечастое. Исключение, пожалуй, составляют пары Microsoft Access - MSDE, Microsoft Access - Microsoft SQL Server и Microsoft Visual FoxPro - Microsoft SQL Server. Здесь налицо результат грамотной политики Microsoft, стремящейся к максимальной совместимости своих продуктов и обеспечивающей наиболее безболезненную для пользователей замену своих настольных СУБД собственными же серверами баз данных (Access->MSDE->Microsoft SQL Server, FoxPro->Visual FoxPro->Microsoft SQL Server).

Средства разработки, универсальные по отношению к СУБД

Средства разработки, универсальные по отношению к СУБД (или претендующие на подобную универсальность), как правило, являются последователями обычных средств разработки приложений, не имеющих прямого отношения к базам данных. Типичные примеры таких средств разработки - Borland Pascal, Borland C++, Microsoft QuickC. Способные использовать библиотеки сторонних производителей, эти средства позволяли обращаться к функциям клиентских API, а с развитием универсальных механизмов доступа к данным (таких как ODBC) - и к функциям API библиотек, реализующих такие механизмы. Отметим, что нередко с помощью этих средств разработки создавались среды настольных СУБД (таких как dBase, FoxBase) или псевдокомпиляторы для языков семейства xBase (например, Clipper).

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

К первой категории относятся средства разработки, обладающие обширными библиотеками классов, большим количеством "мастеров" и кодогенераторов, но ориентированные на "ручное" создание кода и довольно редко применяемые для создания "стандартных" приложений для работы с базами данных (здесь под словосочетанием "стандартное приложение" мы подразумеваем приложение, имеющее непосредственный доступ к базе данных, с которым взаимодействует пользователь, то есть являющееся "классическим" клиентом серверной СУБД). Типичным (и единственным действительно популярным на рынке программного обеспечения) представителем этого класса продуктов является Microsoft Visual C++ . С помощью Microsoft Visual C++ и библиотеки MFC (Microsoft Foundation Classes) можно создавать любые приложения, если вы обладаете навыком, знаниями, умением и временем. Тем не менее приложения, обладающие сложным пользовательским интерфейсом (например, использующие базы данных), с его помощью разрабатывают не так часто (хотя примеры подобного его использования можно найти даже в отечественной литературе). В основном этот продукт применяется для создания клиентских приложений в случае предъявления к ним особых требований, таких, например, как высокая производительность, способность осуществлять какие-либо нестандартные операции и пр.

Ко второй категории относятся средства разработки с развитыми визуальными инструментами, позволяющие буквально "рисовать" пользовательский интерфейс, частично стирая различия между работой программиста и пользователя и удешевляя конечный продукт за счет привлечения к проектированию интерфейса разработчиков, обладающих не самой высокой квалификацией (если внимательно изучить программы курсов учебных центров, специализирующихся на обучении средствам разработки Microsoft, Borland и Sybase, то можно обнаружить, что продолжительность курса обучения, прослушав который обычный пользователь Windows должен научиться создавать клиентские приложения для серверных СУБД, составляет от 5 до 10 рабочих дней).

Именно эта категория средств разработки наиболее часто применяется при создании клиентских приложений. К наиболее популярным продуктам подобного класса следует отнести Microsoft Visual Basic , Borland Delphi , Sybase PowerBuilder и Borland C++ Builder . Среды разработки подобных продуктов весьма схожи внешне (с точностью до расположения окон на экране, устанавливаемого "по умолчанию"): как правило, среда разработки такого продукта содержит "заготовку" проектируемой формы (аналога окна), отдельную панель с пиктограммами элементов пользовательского интерфейса и иных используемых в приложении объектов, которые можно выбирать и помещать на форму, окно, в котором отображаются и редактируются свойства одного из выбранных на форме элементов (а иногда и список событий, на которые реагирует данный элемент), окно редактора кода, где можно вводить фрагменты кода, связанные с обработкой тех или иных событий, а также код, реализующий логику работы данного приложения. Как правило, современные средства разработки такого класса позволяют создавать простейшие приложения для редактирования данных практически без написания кода.

В последнее время очень популярным стало также создание приложений, использующих доступ к базам данных, но расположенных внутри обычных документов. В основу средств разработки подобных приложений положены макроязыки соответствующих редакторов. Наиболее типичным и практически единственным популярным представителем средств разработки этой категории является Visual Basic for Applications, сходный с перечисленными выше визуальными средствами разработки и отличающийся от них тем, что созданные с его помощью приложения содержатся внутри документов Microsoft Office и не отчуждаются от них.

Отметим, однако, что приведенное деление средств разработки на эти два класса весьма условно. Как мы уже говорили выше, практически все средства разработки приложений с базами данных, в том числе и ориентированные на конкретные СУБД, поддерживают как минимум один из универсальных механизмов доступа к данным. И практически все "универсальные" средства разработки приложений, если они принадлежат производителю каких-либо серверных СУБД, поддерживают "свои" СУБД лучше, чем СУБД сторонних производителей (это может выражаться, например, в особых библиотеках классов или компонентов для доступа к данному серверу, а также в наличии общих репозитариев объектов и моделей данных, а иногда и общих с клиентской частью серверной СУБД редакторов параметров доступа к данным или схем данных)

Классификация приложений, использующих базы данных

Приложения в архитектуре "клиент-сервер"

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

Для создания клиентских приложений в этом случае чаще всего применяются средства разработки, обладающие развитыми визуальными инструментами, такие как Microsoft Visual Basic, Borland Delphi, Sybase PowerBuilder, Borland C++Builder.

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

Распределенные приложения

Распределенные (или многозвенные) приложения обычно состоят из презентационных сервисов (или "тонких" клиентов, с которыми обычно взаимодействуют конечные пользователи), сервисов бизнес-логики, реализуемых в виде бизнес-объектов (или сервисов промежуточного слоя - middle tier; нередко для описания совокупности таких сервисов применяется термин middleware), и сервисов данных (обычно состоящих из сервера баз данных и механизмов доступа к данным). Сервисы бизнес-логики предназначены для получения введенных пользователем данных от презентационных сервисов, взаимодействия с сервисами данных для выполнения бизнес-операций (например, обработки заказов или расчета бухгалтерского баланса) и возврата результатов этих операций презентационным сервисам.

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

Некоторые из бизнес-объектов могут обращаться к сервисам данных, используя те или иные механизмы доступа к данным. Поскольку конечный пользователь не взаимодействует непосредственно с бизнес-объектами, последние обычно не обладают пользовательским интерфейсом в привычном понимании. Физически бизнес-объекты могут быть реализованы в виде сервисов операционной системы, консольных приложений либо Windows-приложений, а также в виде библиотек, загружаемых в адресное пространство специально предназначенного для этой цели серверного приложения (Web-сервера, сервера приложений, монитора транзакций и др.). Нередко один бизнес-объект обслуживает множество клиентов.

Для создания бизнес-объектов применяются как средства разработки с развитыми визуальными инструментами, так и средства разработки, ориентированные на "ручное" создание кода приложений (такие как Visual C++). Отметим, что новейшие версии почти всех наиболее популярных средств разработки Windows-приложений (Microsoft Visual Basic, Visual FoxPro и Visual C++, Borland Delphi и C++Builder, Sybase PowerBuilder) поддерживают создание различных типов бизнес-объектов (Web-приложений, ASP-объектов, COM-серверов и др.), за исключением, пожалуй, Microsoft Access - этот продукт рассчитан скорее на квалифицированных пользователей, нежели на разработчиков распределенных систем. Нередко для этой цели используются и средства создания Java-приложений (такие как Borland JBuilder).

Отметим, что, кроме перечисленных выше "универсальных" средств создания как приложений в архитектуре "клиент-сервер", так и бизнес-объектов для распределенных систем, на рынке средств разработки имеются и специализированные средства, предназначенные именно для создания бизнес-объектов (как правило, Web-приложений). Из средств разработки такого класса для платформы Windows наиболее популярен Microsoft Visual InterDev , первая версия которого появилась в 1998 году. Можно также упомянуть еще один интересный продукт, относящийся к той же категории средств разработки, - Borland IntraBuilder, появившийся двумя годами раньше, но почему-то, несмотря на растущую потребность в продуктах такого класса, не получивший дальнейшего развития. Средства разработки подобного класса, как правило, позволяют создавать приложения, динамически генерирующие HTML-код либо код на одном из скриптовых языков (VBScript или JavaScript), который передается Web-сервером в браузер пользователя в составе Web-страницы, и воспринимающие данные, введенные пользователем в HTML-форме и переданные браузером Web-серверу.

Заключение

В настоящей статье мы обсудили процесс создания приложений, использующих базы данных, а также различные категории средств, применяемых при их разработке. Мы убедились, что средства разработки можно условно разделить, с одной стороны, на инструменты, ориентированные на применение конкретных СУБД, инструменты, универсальные по отношению к СУБД, и среды настольных СУБД, применяемые для разработки приложений. С другой стороны, их можно разделить на средства, ориентированные на визуальное проектирование пользовательского интерфейса (к этой категории относятся Microsoft Visual Basic, Borland Delphi, Sybase PowerBuilder, Borland C++Builder), и на средства, ориентированные на написание кода приложения (Visual C++).

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

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

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

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

Интегрированная среда разработки (ИСР) – это система программных средств, используемая программистам для разработки программного обеспечения. В английском языке такая среда называется Integrated development environment или сокращённо IDE.

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

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

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

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

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

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

Наиболее распространёнными отладчиками являются:

- GNU Debugger – отладчик программ от проекта GNU;

- IDA – дизассемблер и низкоуровневый отладчик для операционных систем семейства Windows и GNU/Linux;

- Microsoft Visual Studio – среда разработки программного обеспечения, включающая средства отладки от корпорации Microsoft;

- OllyDbg – бесплатный низкоуровневый отладчик для операционных систем семейства Windows;

- SoftICE – низкоуровневый отладчик для операционных систем семейства Windows;

- Dr. Watson – стандартный отладчик Windows, позволяет создавать дампы памяти;

- WinDbg – бесплатный отладчик от корпорации Microsoft.

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

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

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

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

Большинство систем управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет большую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, так называемая «рабочая копия». Может быть получена последняя версия или любая из предыдущих, выбранная по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть получена оттуда в любое время. Сервер может использовать дельта-компрессию – способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных.

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

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

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

Другие возможности системы управления версиями состоят:

В создании разных вариантов одного документа-ветки, с общей историей изменений до точки ветвления и с разными – после неё.

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

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

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

Когда пользователь такой системы выполняет обычные действия, такие, как извлечение определённой версии документа, создание новой версии и тому подобное, он работает со своей локальной копией хранилища. По мере внесения изменений хранилища, принадлежащие разным разработчикам, начинают различаться, и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена патчами или так называемыми наборами изменений (англ. change sets) между пользователями.

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

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

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

branch (ветвь) – направление разработки, независимое от других. Ветвь представляет собой копию части (как правило, одного каталога) хранилища, в которую можно вносить свои изменения, не влияющие на другие ветви. Документы в разных ветвях имеют одинаковую историю до точки ветвления и разные – после неё.

check-in, commit, submit – создание новой версии, публикация изменений. Распространение изменений, сделанных в рабочей копии, на хранилище документов. При этом в хранилище создаётся новая версия изменённых документов.

C heck-out, clone – извлечение документа из хранилища и создание рабочей копии.

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

M erge, integration (слияние) - объединение независимых изменений в единую версию документа. Осуществляется, когда два человека изменили один и тот же файл или при переносе изменений из одной ветки в другую.

R epository (хранилище документов) - место, где система управления версиями хранит все документы вместе с историей их изменения и другой служебной информацией.

R evision (версия документа). Системы управления версиями различают версии по номерам, которые назначаются автоматически.

T ag, label (метка) – которую можно присвоить определённой версии документа. Метка представляет собой символическое имя для группы документов, причём описывает она не только набор имён файлов, но и ревизию каждого файла. Ревизии включённых в метку документов могут принадлежать разным моментам времени.

T runk, mainline (ствол) – основная ветвь разработки проекта. Политика работы со стволом может отличаться от проекта к проекту, но в целом она такова: большинство изменений вносится в ствол; если требуется серьёзное изменение, способное привести к нестабильности, создаётся ветвь, которая сливается со стволом, когда нововведение будет в достаточной мере испытано; перед выпуском очередной версии создаётся «релизная» ветвь, в которую вносятся только исправления.

U pdate, sync (обновление, синхронизация) – синхронизация рабочей копии до некоторого заданного состояния хранилища. Чаще всего это действие означает обновление рабочей копии до самого свежего состояния хранилища. Однако при необходимости можно синхронизировать рабочую копию и к более старому состоянию, чем текущее.

W orking copy (рабочая копия) – рабочая (локальная) копия документов.

Рассмотрим возможности ИСР на примере наиболее доступных и популярных версий.

Eclipse (от англ. затмение) – свободная интегрированная среда разработки модульных кроссплатформенных приложений (рисунок 69). Развивается и поддерживается некоммерческой организацией Eclipse Foundation (http://www.eclipse.org/).

Первоначально Eclipse разрабатывалась фирмой «IBM» в качестве корпоративного стандарта ИСР для разработки на разных языках под платформы от данной компании. По сведениям «IBM», проектирование и разработка стоили 40 млн. долл. Исходный код был полностью открыт и сделан доступным после того, как Eclipse был передан для дальнейшего развития независимому от «IBM» сообществу.

В основе Эклипс лежат фреймворк OSGi и SWT/JFace, на основе которых разработан следующий слой – RCP (Rich Client Platform, платформа для разработки полноценных клиентских приложений). RCP служит основой не только для Эклипс, но и для других RCP-приложений, например, Azureus и File Arranger. Следующий слой – сам Эклипс, представляющий собой набор расширений RCP: редакторы, панели, перспективы, модуль CVS и модуль Java Development Tools (JDT).

Эклипс – в первую очередь, полноценная Java ИСР, нацеленная на групповую разработку: поддержка CVS входит в поставку Эклипс, активно развиваются несколько вариантов SVN-модулей, существует поддержка VSS и других. В силу бесплатности и высокого качества, Эклипс во многих организациях является корпоративным стандартом для разработки приложений.

Второе назначение Эклипс – служить платформой для разработки новых расширений, чем он и завоевал популярность: любой разработчик может расширить Эклипс своими модулями. Уже существуют C/C++ Development Tools (CDT), разрабатываемые инженерами QNX совместно с «IBM», и средства для языков COBOL, FORTRAN, PHP и прочие от различных разработчиков. Множество расширений дополняет среду Эклипс менеджерами для работы с базами данных, серверами приложений и др.

Рисунок 69 . Интерфейс главного окна Эклипс

Эклипс написана на Java, потому является платформо-независимым продуктом, за исключением библиотеки SWT, которая разрабатывается для всех распространённых платформ. Библиотека SWT используется вместо стандартной для Java библиотеки Swing. Она полностью опирается на нижележащую платформу (операционную систему), что обеспечивает быстроту и натуральный внешний вид пользовательского интерфейса, но иногда вызывает на разных платформах проблемы совместимости и устойчивости приложений.

Основой Eclipse является платформа расширенного клиента (RCP - от англ. rich client platform). Её компоненты:

OSGi (стандартная среда поставки комплектов (англ. bundles));

SWT (портируемый инструментарий виджетов);

JFace (файловые буферы, работа с текстом, текстовые редакторы);

Рабочая среда Эклипс (панели, редакторы, проекции, мастеры).

Другой популярной свободной ИСР является КДевелоп (http://www.kdevelop.org, рис. 70). КДевелоп (англ. KDevelop) - свободная среда разработки программного обеспечения для UNIX-подобных операционных систем. Проект стартовал в 1998 году. КДевелоп распространяется согласно лицензии GNU (General Public License).

Рисунок 70. Интерфейс KDevelop

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

Текущая стабильная версия поддерживает большое количество языков программирования, таких как Ада, Bash, C, C++, Фортран, Java, Pascal, Perl, PHP, Python, Ruby и SQL.

КДевелоп использует встроенный компонент – текстовый редактор – через технологию KParts. Основным редактором является Kate.

Функции КДевелоп:

Подсветка исходного кода с учетом синтаксиса используемого языка программирования, который определяется автоматически;

Менеджер проектов для проектов разного типа, таких как Automake, qmake для проектов базирующихся на технологиях Qt и Ant для проектов, базирующихся на Java;

Навигатор классов (Class Browser);

Front-end для GNU Compiler Collection;

Front-end для GNU Debugger;

Помощников для генерации и обновления определения классов и платформы (framework);

Автоматическая система завершения кода (Си/C++);

Встроенная поддержка системы документирования исходных кодов (Doxygen);

Одна из систем контроля версий: SCM, CVS, Subversion, Perforce и ClearCase;

Функция Quick Open позволяющая быстро перемещаться по файлам.

KDevelop представляет собой «подключаемую» архитектуру. Когда разработчик делает изменения, он должен лишь скомпилировать плагин. Предусмотрена возможность сохранения профилей, указывающих какие плагины должны быть загружены. KDevelop не поставляется со встроенным текстовым редактором, он подключается как плагин. KDevelop не зависит от языка программирования и от платформы, на которой он запускается, поддерживая KDE, GNOME и много других технологий (например, Qt, GTK+ и wxWidgets).

Встроенный отладчик KDevelop позволяет работать графически со всеми средствами отладки, такими как точки останова и трассировки. Он также может работать с динамически подгружаемыми плагинами, в отличие от консольного gdb.

На данный момент существует примерно от 50 до 100 плагинов для данной IDE. Среди наиболее полезных – persistent project-wide code bookmarks, Code abbreviations, позволяющие быстро разворачивать текст, Source formatter, который переформатирует текст для style guide до сохранения, поиск по регулярным выражениям и project-wide поиск/замена.

Последней рассматриваемой ИСР является Microsoft Visual Studio (Microsoft Visual Studio, рис. 71). По сути, Microsoft Visual Studio является линейкой продуктов компании «Майкрософт», включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств.

Рисунок 71. Интерфейс Microsoft Visual Studio

Microsoft Visual Studio включает один или несколько компонентов из следующих: Visual Basic.NET, Visual C++, Visual C#, Visual F#, Microsoft SQL Server, Visual InterDev, Visual J++, Visual J#, Visual FoxPro, Visual Source Safe.

Одним из главных преимуществ Майкрософт Визуал Студия является высокое качество документирования процесса разработки и описания возможных проблем в MSDN Library. Однако наиболее интересная для профессионала часть, посвящённая тонкостям разработки, существует только на английском языке.

Также компания «Майкрософт» предлагает бесплатный аналог продукта Visual Studio Express.

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

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

Различают три основных класса инструментальных средразработки и сопровождения ПС (рис. 16.1): ·

среды программирования, ·

рабочие места компьютерной технологии,·

инструментальные системы технологии программирования.

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

Рис. 16.1. Основные классы инструментальных сред разработки и сопровождения ПС.

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

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

Различают следующие классы инструментальных сред программирования (см. рис. 14.2): ·

среды общего назначения,·

языково-ориентированные среды.

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

Рис.16.2. Классификация инструментальных сред программирования.

Языково-ориентированная инструментальная среда программирования предназначена для поддержки разработки ПС на каком-либо одном языке программирования и знания об этом языке существенно использовались при построении такой среды. Вследствие этого в такой среде могут быть доступны достаточно мощные возможности, учитывающие специфику данного языка. Такие среды разделяются на два подкласса: ·

интерпретирующие среды, ·

синтаксически-управляемые среды.

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

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

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

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

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 применяли отдельные среды для разработки.
Visual Studio 6.0 вышла в июне 1998 г.. Это последняя версия Visual Studio, работающая на платформе Win9x. По-прежнему популярна среди программистов, использующих Visual Basic. Данная версия являлась основной средой разработки приложений под Windows от Microsoft, до появления платформы.NET.
Visual Studio .NET (кодовое имя Rainier; внутренняя версия 7.0) выпущена в феврале 2002 года (включает.NET Framework 1.0). Service Pack 1 для Visual Studio .NET (2002) выпущен в марте 2005 г.
Visual Studio .NET 2003 (кодовое имя Everett; внутренняя версия 7.1) появилась в апреле 2003 года (включает.NET Framework 1.1). Service Pack 1 для Visual Studio .NET 2003 выпущен 13 сентября 2006 г.
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 и др. 19 апреля 2006 г. редакция Express стала бесплатной. Service Pack 1 для VS2005 и всех Express-редакций выпущен 14 декабря 2006 года. Дополнительный патч для SP1, решающий проблему совместимости с Windows Vista выпущен 6 марта 2007 г.
Visual Studio 2008 (кодовое имя Orcas) выпущена 19 ноября 2007 г., одновременно с.NET Framework 3.5. Нацелена на создание приложений для ОС Windows Vista (но поддерживает и XP), Office 2007 и веб-приложений. Включает в себя LINQ, новые версии языков C# и Visual Basic. В студию не вошел Visual J#. С 28 октября 2008 года впервые доступна версия на русском языке.
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 . Первоначальной целью проекта было создание корпоративного стандарта IDE для разработки программ на разных языках под различные платформы. Потом проект был переименован в Eclipse и выделен в открытый доступ . Лицензия позволяет бесплатно использовать код и среду разработки и при этом создавать закрытые коммерческие продукты. Благодаря этому система получила широкое распространение и для многих организаций стала корпоративным стандартом для разработки приложений.

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

Выбор среды разработки

Интегрированная среда разработки, ИСР (англ. IDE, Integrated development environment или integrated debugging environment) -- система программных средств, используемая программистами для разработки программного обеспечения (ПО) .

Среда разработки включает в себя:

Текстовый редактор;

Компилятор и/или интерпретатор;

Средства автоматизации сборки;

Отладчик.

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

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

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

IDE обычно представляет из себя единственную программу, в которой проводилась вся разработка. Она обычно содержит много функций для создания, изменения, компилирования, развертывания и отладки программного обеспечения. Цель среды разработки заключается в том, чтобы абстрагировать конфигурацию, необходимую, чтобы объединить утилиты командной строки в одном модуле, который позволит уменьшить время, чтобы изучить язык, и повысить производительность разработчика. Также считается, что трудная интеграция задач разработки может далее повысить производительность. Например, IDE позволяет проанализировать код и тем самым обеспечить мгновенную обратную связь и уведомить о синтаксических ошибках. В то время как большинство современных IDE является графическим, они использовались еще до того, как появились системы управления окнами (которые реализованы в Microsoft Windows или X11 для *nix-систем). Они были основаны на тексте, используя функциональные клавиши или горячие клавиши, чтобы выполнить различные задачи (например, Turbo Pascal). Использование IDE для разработки программного обеспечения является прямой противоположностью способа, в котором используются несвязанные инструменты, такие как vi (текстовый редактор), GCC (компилятор), и т.п.

На данный момент существуют несколько сред для разработки приложений на языке C#, основные из них приведены в таблице 1.1.

Таблица 1.1 - Сравнение сред разработки C#

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

Лицензия LGPL позволяет линковать с данной библиотекой или программой программы под любой лицензией, несовместимой с GNU GPL, при условии, что такая программа не является производной от объекта, распространяемого под (L)GPL, кроме как путём линкования. Главное различие между GPL и LGPL в том, что последняя позволяет и такое линкование с данным объектом других, которое создаёт производную от данного работу, если лицензия слинкованных объектов позволяет «модификации для внутреннего использования потребителем и обратную разработку для отладки таких модификаций». Т.е. LGPL, в отличие от GPL позволяет связывание библиотеки с любой программой, не обязательно свободной.

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

Geany -- свободная среда разработки программного обеспечения, написанная с использованием библиотеки GTK2. Доступна для следующих операционных систем: BSD, Linux, Mac OS X, Solaris и Windows. Geany распространяется согласно GNU General Public License. Geany не включает в свой состав компилятор. Вместо этого используется GNU Compiler Collection (или любой другой компилятор) для создания исполняемого кода.

Microsoft Visual Studio -- линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework и Microsoft Silverlight. Visual Studio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и как отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. Visual Studio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как например, Subversion и Visual SourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода на предметно-ориентированных языках программирования или инструментов для прочих аспектов цикла разработки программного обеспечения (например, клиент Team Explorer для работы с Team Foundation Server).

MonoDevelop -- свободная среда разработки, предназначенная для создания приложений C#, Java, Boo, Nemerle, Visual Basic .NET, Vala, CIL, C и C++. Также планируется поддержка Oxygene со стороны Embarcadero Technologies. Изначально это был порт SharpDevelop на Mono/GTK+, но с того времени проект далеко ушёл от своего начального состояния. MonoDevelop является частью проекта Mono.

SharpDevelop -- свободная среда разработки для C#, Visual Basic .NET, Boo, IronPython, IronRuby, F#, C++. Обычно используется теми, кто не хочет пользоваться Visual Studio .NET. Существует также форк на Mono/Gtk+ -- MonoDevelop. SharpDevelop 2.0 предоставляет интегрированный отладчик, который использует собственные библиотеки и взаимодействует с исполняющей средой.NET через COM Interop. Хотя SharpDevelop 2.0 (как и VS2005) использует файлы проекта в формате MSBuild, он по-прежнему может использовать компиляторы от.NET Framework 1.0 и 1.1, а также от Mono.

Для разработки необходимо активно использовать все средства языка программирования. Однако среда MonoDevelop использует собственный компилятор, который не полностью поддерживает язык С# в силу того, что является свободной мультиплатформенной разработкой, независимой от создателей языка. Хотя она и обеспечивает мультиплатформенность, но невозможно предсказать поведение языка в новых версиях. А одной из ключевых составляющих проекта является его отказоустойчивость и стабильность и в то же время мультиплатформенность не требуется (пользователей 1С на Linux исчезающе мало). Поэтому эта среда не подходит для разработки данного проекта.

SharpDevelop и Geany не имеют собственных компиляторов. Поэтому для разработки с использованием этих сред все равно придется использовать проприетарное ПО, что делает их использование оправданным лишь в некоторых случаях. Например на низкопроизводительных компьютерах или при сильно ограниченном бюджете проекта. Несмотря на то, что что они могут запускаться и работать в ОС Linux, данные среды разработки в силу отсутствия собственных компиляторов не смогут создать мультиплатформенное приложение, и разработка все равно ограничится операционными системами Windows.

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

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

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

Выбор среды разработки