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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 24.04.2023

Просмотров: 347

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Введение

В связи с тем, что производительность и доступность ЭВМ (Электронных вычислительных машин) постоянно повышается, прямо пропорционально повышается и сложность выполняемых ими задач и количество программ, которые необходимы для ее функционирования. Ведь с точки зрения конечного пользователя эффективность любой вычислительной машины или операционной системы, написанной для нее, исчисляется количеством приложений, написанных под нее. Так, конечно, было не всегда. До конца 70-тых годов понятия персональный компьютер вообще не существовало как класс. В данном случае такая машина как Altair рассматриваться не будет это был предел математиков энтузиастов. Мы же в контексте данного курсового проекта будем рассматривать, хоть и косвенно, эру появления персональных компьютеров. Она приходится на начало 80-х и длится до наших дней. На то время, абсолютное большинство людей воспринимало персональный компьютер как дорогую игрушку. Связанно это было с тем, что большинство людей не были ни математиками ни уж тем более программистами. Таким образом, появилась необходимость производителям ПК того времени задуматься и о программном обеспечении к их продукту. Более того, необходимо было привлекать и сторонние компании к разработке программ под конкретный компьютер или архитектуру. Стоит правда отметить, что понятия архитектуры и совместимости ПО появились ближе к 1985-му году.

В связи с данными обстоятельствами количество задач, выполняемых рядовым программистом, возросло в разы. Более того программное обеспечение от ныне должно быть дружелюбным к конечному пользователю так как он не обязан учить тот же язык Basic или тем более Assembler для того, чтобы рассчитать свои расходы на продукты или поиграть в Тетрис. Это и породило основную проблему, в программировании ошибки неизбежны, задач в рамках реализации одного проекта достаточно много, а времени на разработку мало. Ведь производителю важно количество продаж здесь и сейчас.

Для решения подобного рода задач и были разработаны первые IDE (Integrated development environments) Которые включали в себя как редактор кода, так и сборщик кода, и его отладчик.

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


Теоретические основы

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

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

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

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

получить от компилятора результаты его работы в виде набора объектных файлов;

подать весь набор полученных объектных файлов вместе с необходимыми библиотеками подпрограмм на вход компоновщику;

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

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

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

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


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

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

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

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

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

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


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

  • Глобальный поиск по всем файлам создаваемого проекта.
  • Отображение ошибок в консоли самой интегрированной среды и возможность быстро перейти к ее источнику.
  • Возможность быстрого рефакторинга исходного кода.
  • Авто дополнение исходного кода
  • Возможность быстрой отладки исходного кода.

Первые интегрированные среды разработки были текстовыми и управлялись с помощью горячих клавиш и командной строки. Одной из первых IDE с графическим интерфейсом была Turbo Pascal созданная компанией Borland для популярного на то время языка программирования высокого уровня Pascal. Она имела оконный интерфейс и использовала графические возможности операционной системы MS DOS, которая и была установлена на большинстве IBM совместимых компьютерах. Кроме возможности сборки и компиляции кода данная среда имела встроенный отладчик. На рисунке 1.1. представлено главное рабочее окно Turbo Pascal.

Рисунок 1.1. Основное рабочее окно среды Turbo Pascal.

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

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


    1. Редакторы исходного кода

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

В отличии от обычных текстовых редакторов редакторы исходного кода имеют более широкий функционал. Как правило они имеют подсветку синтаксиса для множества языков программирования и позволяют использовать авто дополнение кода для их стандартных функций. Как и в случае с интегрированными средами многие программы данного класса имеют возможность расширения с помощью сторонних модулей и даже взаимодействуют с компиляторами и отладчиками. Но, в отличии от интегрированных сред разработки потребляют меньше ресурсов. Таким образом, некоторые разработчики программного обеспечения предпочитают использовать редакторы кода вместо интегрированных средств разработки и отлаживать разрабатываемое приложение вручную. Стоит отметить, что в большинстве своем данная тенденция касается разработчиков, которые, используют в своей работе языки программирования, которые, не требуют пере сборки проектов после внесения каких-либо изменений в исходный код приложения это такие языки как: HTML, PHP, JavaScript и т. д. Однако такой подход имеет свои недостатки к примеру нет глобального поиска определенной части кода по всем файлам проекта. Редактор может искать только в тех файлах, которые в данный момент открыты или только по одному каталогу. Так же нет возможности получить авто дополнение кода по тем функциям, классам или методам, которые, были унаследованы из других файлов проекта и абсолютно невозможно посмотреть данные, с которыми наследуемый метод работает. Что во многом ведет к большим время затратам при написании исходного кода программы и дальнейшей его отладке. Так же повышается вероятность ошибок в конечном программном обеспечении.

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

    1. Обзор современных интегрированных сред разработки