Файл: Интегрированные среды разработки программ (Теоретический аспект интегрированных сред разработки программ).pdf

Введение

Актуальность исследования обусловлена следующими обстоятельствами.

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

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

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

Цель работы заключается в том, чтобы рассмотреть интегрированные среды разработки программ.

Задачи исследования:

-представить основные понятия;

-проанализировать системы управления версиями;

-выявить особенности терминологии систем управления версиями;

-выявить практический аспект интегрированных систем разработки программ.

Объект исследования: интегрированные среды разработки программ.

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

Методы исследования: анализ литературы по проблеме исследования, обобщение, сравнение, синтез.

1. Теоретический аспект интегрированных сред разработки программ

1.1. Основные понятия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основным процессом отладки является трассировка.

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

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

1.2.Системы управления версиями

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

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

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

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

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

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

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

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

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

- возможности узнать, кто и когда добавил или изменил конкретный набор строк в файле;

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

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

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

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

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

1.3.Терминология систем управления версиями

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

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

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

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

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