Учебное пособие по курсу «Технология программирования»

Вид материала

Содержание

1. Краткая история технологии программирования

Подобный материал:

1 2 3 4 5 6 7 8 9 10

1. Краткая история технологии программирования

(О законности термина «технология программирования»)

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

Параллель между кино и программами гораздо более широкая, чем многим может показаться, например: и кино и программы являются уникальными творческими объектами. Можно провести параллели как между самими объектами (кино – программа), так и между технологиями производства. По многим причинам в нашу задачу не входит проведение этой параллели.

Конечно, во введении нет возможности разобраться во множестве вопросов. Но, произнося термин «технология программирования» и утверждая существование производства программ, необходимо ясно представлять, что такое программа и программирование. Нам надо знать, когда собственно появилось производство программ? Мы хотим быть инженерами! Роль ремесленника представляется для нас убогой (не следует забывать, что у многих ремесленников есть чему научиться). Роль свободного художника не всякому по плечу, да и количество необходимых свободных художников исчисляется единицами.

Итак, технология – [гр. techne – искусство, ремесло, наука + logos – понятие, учение] — совокупность знаний о способах и средствах проведения производственных процессов. (сл. “Словарь иностранных слов”, стр. 688, 1955). Подчеркнём: производственных процессов. Естественно слышать “технология обработки металлов”, “технология химических процессов”, однако “технология программирования” – несколько ненормальное сочетание. Никто не преполагает существование “технологии математики” или “технологии литературы”. Обычно, к этим областям знаний понятие “технология” не применяется. Сейчас для нас это очевидно: в этих областях нет производства. Несмотря на то, что вычислительные центры при предприятиях появились более сорока лет назад, термин производство программ обрёл право на жизнь сравнительно недавно. Это было примерно тогда, когда широкий круг пользователей стал спрашивать, где можно приобрести программы? Тем не менее, производство программ существовало уже более тридцати лет.

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

Программа: также совершенно естественно определяется, как последовательность команд выполняемых центральным процессорным устройством (ЦПУ).

Отметим, что мы говорим не процессор, а центральное процессорное устройство. Во-первых, ранние ЭВМ имели центральное процессорное устройство, а не процессор. Первый процессор появился только в 1970г., а первая ЭВМ работала уже в 1943г. (Марк –1: Говард Эйкен). [Конрад Цузе – 1941]. Во-вторых, под ЦПУ понимается очень широкий класс устройств, основное свойство которых, варьировать тип, сорт, вид выходной продукции в зависимости от настройки или последовательности выполняемых команд. Собственно эта настройка или конкретная последовательность команд и являлась для этого ЦПУ программой. Роль человека при работе с этими устройствами сводилась к «вводу» программы и запуску устройства, ну и, безусловно, был процесс создания программы.

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

Однако появление уникальных технических устройств (1941 – 1943 г.г.) – ещё не появление технологии работы на них. Появление технологии программирования достаточно уникально. В определённом смысле сама «технология программирования» появилась существенно раньше появления ЭВМ! (электронных вычислительных машин).

Ещё в 1808г. Жаккар Жозеф Мари изобрёл способ задания характеристик ткани для ткацких станков. Выполнялось это при помощи особого приспособления для ткацкого станка. Принципиально оно состояло из особой доски с отверстиями. Для каждого вида ткани набиралась своя доска, которая устанавливалась на ткацком станке. Безусловно, жаккардова доска является программой, управляющей работой ткацкого станка. Процесс разработки структуры этой доски, процесс её набора очень сильно напоминает процессы программирования. Саму программу можно было реально потрогать. Конечно, ни у кого не возникал вопрос о правомерности существования термина «технология программирования». В те времена никто не рассматривал жаккардову доску, как программу.

В конце XIX века Холлерит изобрел сортировальные машины и придумал «перфокарту». На перфокартах можно было перфорировать ограниченный круг информации, только цифры и знаки «+»и «». Сортировальные машины могли «считывать» перфокарты, сортировать их, складывать или вычитать заданные колонки. Что и как складывать, сортировать и вообще какие действия с какими колонками выполнять задавалось при помощи коммутационных досок. Сортировальная машина непосредственный предшественник ЭВМ. Она уже была электрической. Коммутационная доска представляла собой рамку с набором гнёзд для подключения штекеров. Программа задавалась при помощи штекеров соединённых проводами.
Разработка схемы коммутационной доски и являлось программированием для расчетов, выполняемых на сортировальных машинах.

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

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

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

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

Если мы хотим, чтобы компьютер был универсальным и эффективным устройством, то компьютер должен иметь:

Арифметико-логическое устройство или центральное процессорное устройство, выполняющее арифметические и логические действия.

Устройство управления, организующее процесс управления программой.

Запоминающее устройство или память для хранения программ и данных.

Внешние устройства для ввода-вывода информации.

Главное в этих принципах то, что программа и данные не различаются и могут храниться на одних и тех же устройствах. Важно, что и программа, и данные могут обрабатываться одним устройством. Мало того, что этот принцип позволил существенно упростить устройство ЭВМ, он же, фактически, «разрешил» существование таких программ, как трансляторы, ведь, что такое программа, как не входные данные для транслятора. Именно с машины Неймана понятия программа и программирование приобретают то наполнение и смысл, какой мы привыкли понимать. Но остался ли смысл в термине «технология программирования»?

Итак, давайте рассмотрим процесс программирования и понятие программа для машины фон Неймана.

Вспомним, как работает процессорное устройство. С заданного адреса памяти ЦПУ выбирает заданное число бит, обычно, один байт или восемь бит.. Эта цепочка бит интерпретируется, как команда. Отметим, что длина цепочки бит задаёт максимальное число возможных команд. Если мы выбираем восемь бит, то число возможных команд будет 256. Реальное число команд будет меньше. Таким образом, существуют состояния байта, которые не могут интерпретироваться как команда процессора. Если выбирается подобное состояние байта, то возникает прерывание (раньше возникал останов) «недопустимая команда», иначе продолжается выполнение команды.

Дальше число выбираемых бит зависит от команды. Наиболее короткие регистровые команды, а наиболее длинные команды типа память – память: сложить содержимое выбираемое с адреса А1 с содержимым выбираемым с адреса А2 и направить результат по одному из этих адресов или по адресу А3. Отметим, что длина команды накладывает ограничение на величину адреса, а следовательно и на величину памяти, которая может использоваться.

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

Разумеется, если мы обратимся к деталям, то всё окажется не так просто, но сейчас нам нужна основная схема. А из этой схемы видно, что программа это последовательность команд ЦПУ/процессора. Для того, чтобы написать программу необходимо: распределить в памяти данные; определить адрес начала программы; записать последовательно, начиная с этого адреса, коды команд. Технические условия задаются типом ЦПУ. То есть для правильного программирования необходимо знать устройство конкретной ЭВМ и её систему команд. Такое программирование называется программированием в коде. Вопрос содержания термина «технология программирования» не вызывает сложностей.

Программирование в коде никуда не делось. Оно существует и поныне и чаще всего используется при программировании технических контролёров.

Достоинства и недостатки:

Грамотный программист писал эффективные и короткие программы. Например, Брукс вспоминает случай, когда некий программист, он не приводит его имени, сумел реализовать в коде транслятор с Fortrana, уместив его в 4K памяти (! – сравните с сегодняшними параметрами)

Технические возможности машины использовались в полном объёме.

Программы можно было ввести непосредственно с пульта ЭВМ и с него влиять на работу программы. По ходу работы программы можно было даже изменить саму программу.

На этом достоинства кончаются и начинаются недостатки.

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

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

Программы в коде непереносимы. Это естественно, так как они написаны для конкретной ЭВМ в её системе команд.

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

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

Переход с одной машины на другую у опытного программиста занимал примерно полгода. На обучение программированию в коде новичка уходило до года.

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

Постановка, программирование, отладка, эксплуатация/сопровождение.

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

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

Основная идея была следующей: раз человек ошибается, а кодирование программы однообразный и достаточно рутинный процесс, нельзя ли заставить кодировать программу саму ЭВМ. Оказывается можно: в 1958г. Джон Бэкус реализовал первый транслятор с Fortrana.

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

Появление трансляторов принесло качественные изменения в технологию программирования. Во-первых, появился не один новый класс программ – трансляторы, а целых три: вместе с трансляторами появились редакторы связей и загрузчики. Во-вторых, программы перестали быть чисто техническим объектом.
В-третьих, с появлением трансляторов стала явственно ощущаться необходимость в наличии неких комплексов программ, управляющих работой ЭВМ.

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

Транслятор это программа, переводящая один класс утверждений в другой. Это в общем правильное определение 40 лет назад звучало по-другому и, конечно же, в него вкладывался другой смысл: транслятор, это программа переводящая предложения алгоритмического языка в код машины. Даже в этом определении не говорится об исполняемом коде. Транслятор не мог сгенерировать сразу исполняемый код. Проблема всё та же – распределение памяти ЭВМ. Для генерации исполняемого кода требовалось знать начальный адрес загрузки программы. Нижние адреса большинства машин использовались в некоторых технических целях, что также необходимо было учитывать при генерации кода. Но, очень важно, Fortran имел оператор CALL ИМЯ,
вызывающий подпрограммы, а также заголовок для подпрограммы: SUBROUTINE.
Предполагалось, что подпрограммы могут быть оттранслированы отдельно от программы их вызывающей. Отсюда видно, что транслятор не мог знать заранее, где находятся уже оттранслированные подпрограммы, и, главное, транслятору не были известны адреса загрузки подпрограмм; да и подпрограммы один раз должны быть загружены с одного адреса, а другой раз с другого. Выход из этой ситуации был очень простой: транслятор все программы транслировал в некие объекты, адрес загрузки которых был ноль. Эти объекты содержали исполняемый код и даже могли бы выполняться при загрузке с нулевого адреса, до первого вызова подпрограммы. Чтобы объект, получаемый в результате работы транслятора, можно было выполнить, следовало изменить все адреса его на величину адреса загрузки, а также согласовать адреса вызова подпрограмм. Логично всю эту работу было поручить ЭВМ, то есть потребовался новый класс программ: редактор связей.

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

Объект, получаемый транслятором в результате трансляции, называется объектный модуль. Объектные модули не могли выполняться непосредственно на машине. Программа разрешающая все внешние ссылки объектных модулей называется редактор связей. Кроме того, тогда редактор связей настраивал программу на конкретный адрес загрузки, получая на выходе загрузочный модуль. Теперь чаще всего говорят исполняемый модуль (EXE – модуль). Загрузочный модуль и был тем самым исполняемым кодом, он мог выполняться на машине.

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

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

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

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

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

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

Что делает учёный сделавший открытие или доказавший теорему: публикует суть своего открытия или доказательство теоремы, то есть поступает прямо противоположным образом! Тогда, если программы математические объекты, то программы следует публиковать.

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

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

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

Успокоившись, таким образом, по поводу содержания термина “технология программирования”, вернёмся в шестидесятые года и вспомним или выясним, как происходил выход программиста на машину. Отметим, что ЭВМ тогда были очень громоздки, нередко занимали более 200 м² площади, могли функционировать в довольно узких температурных пределах и т.п. Один из авторов книг по программированию совершенно серьёзно приводит следующую ситуацию: программист, вышедший на вычислительный центр (ВЦ), первым делом спрашивает: где ящик с Fortranom. Именно ящик. Поскольку Fortran представлял собой колоду перфокарт, выкрашенных, допустим, в зелёный цвет, и хранившуюся в ящике. Отыскав транслятор, программист вводил его с устройства ввода перфокарт и запускал за ним уже свою колоду с программой, окрашенной, как правило, в светло-коричневые тона (цвет картона). В результате работы транслятора, на устройстве вывода перфокарт выводилась колода объектного модуля, окрашенного, допустим в белый цвет. Теперь разыскивался ящик с редактором и вся процедура повторялась, при этом программист добавлял все необходимые объектные модули подпрограмм: результатом работы редактора был, допустим, загрузочный модуль выведеный на колоду красного цвета. Наконец, если ранее не произошло какого-либо критического события, наступала очередь загрузчика. Немудрено, что кодировщики кодов могли достаточно долго игнорировать появление алгоритмических языков.

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

В конце шестидесятых фирма IBM анонсировала выпуск ЭВМ новой архитектуры – IBM/360, поставляемой с операционной системой DOS. (не путать с современной DOS для ПЭВМ; для IBM/360 поставлялась совсем другая DOS). Это был третий виток в технологии программирования. Интересно сравнить характеристики системы с нынешними персональными монстрами.

Младшая модель IBM 360, так называемая модель 20, имела 128К оперативной памяти. Поставлялась с двумя-четырьмя дисководами (внешними), каждый объёмом 7мгб; двумя-четырьмя ленточными накопителями – на одну бобину магнитной ленты можно было записать примерно 28Мгб; перфокарточными вводом и выводом и пишущей машинкой, как выходным устройством операционной системы; впрочем, с пишущей машинки можно было выполнять и ввод команд системы. Рекомендуем сравнить эти характеристики, хотя бы с характеристиками IBM PC XT.

Операционная система занимала 10К оперативной памяти и могла работать одновременно с тремя программами. При этом с операционной системой поставлялось несколько наиболее распространённых алгоритмических языков: обычно, Fortran; Cobol; Algol и позже PL/1. Кроме того, обязательно поставлялся Assembler. При этом система поставлялась с полным комплектом документации. Рекомендуем сравнить с сегодняшней ситуацией в программировании.

Не следует забывать, что такая машина занимала примерно пол-этажа среднего здания, требовала установки искусственного климата и была ЭВМ группового пользования. Обслуживающий персонал составлял примерно 10-12 электроников (при двухсменной загрузке); три – пять системных программистов; шесть – восемь операторов и от десяти и более проблемных программистов; кроме того, был ещё и штат администрации.

Именно с приходом системы IBM/360 программирование стало по настоящему промышленным производством программ. Система IBM вытеснила с рынка все ранее существовавшие ЭВМ и этим унифицировала рынок и косвенным образом стандартизовала программирование.

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

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

Программисты научились писать большие программные комплексы. Не трансляторы или редакторы связей; тогда трудоёмкость этих программ измерялась цифрами порядка 10 человеко-лет. Речь идёт об операционных системах, трудоёмкость которых тогда оценивалась в несколько сотен человеко-лет. Организация работ по разработке большого программного комплекса представляла серьёзную проблему, которая актуальна до сих пор. Достаточно ознакомиться с результатами работы фирмы MicroSoft. Впрочем, это отдельный разговор.

Развитие техники шло в сторону увеличение используемых ресурсов и удешевления технической базы. Тем не менее, оставались достаточно дорогие ресурсы, среди которых была оперативная память (сейчас оперативная память также представляет дорогой ресурс). Появилась идея виртуальной памяти. Потом стало ясно, что если программно можно моделировать память, то точно также можно моделировать любое техническое устройство и саму ЭВМ тоже. Таким образом шестая версия операционной системы ОС/360 полностью базировалась на идее виртуальной машины. Сама же виртуальная память получила аппаратную поддержку, что существенно ускорило работу операционной системы. Идея виртуального устройства ясно показывает, что любое устройство можно реализовать программно, хотя чаще это называется моделированием. Справедливо и обратное: любая программа может быть реализована аппаратно!

Четвёртый этап начался с широким приходом персональных электронных вычислительных машин (ПЭВМ). При этом можно выделить два подэтапа: DOS – период – это период до выброса на рынок операционной системы Windows – 95 и Windows – период – который длится и поныне. (Здесь и далее имеется в виду именно DOS для ПЭВМ, если не будет явно оговорено противное).

На рынке снова появились ЭВМ различных конструкций: от чисто игровых – Spectrum, до профессиональных – Risc – архитектура: Sun; IBM RISC 6000. Наиболее распространёнными были (и остаются) два клона: Macintosh и ПЭВМ на основе процессора Intel: IBM XT и затем IBM AT. Некоторое время полагали, что ПЭВМ так и останется в «любительской» сфере, что привело ко множеству неверных инженерных решений в конструкции ЭВМ (желающих ознакомиться с этими проблемами отсылаем к курсу «архитектура ЭВМ»). Жизнь, однако, показала другое: произошло внедрение ПЭВМ в производство. Появление ПЭВМ в производстве привело к широкому использованию сетевых технологий.

С точки зрения технологии программирования четвёртый этап характеризуется следующими явлениями:

Появлением, так называемых, «коробочных» программных продуктов.
Победным шествием языка C, а затем C++.
Внедрением ООП (объектно – ориентированное программирование) в широкую практику;
Появлением визуального программирования;
Внедрением сетевых технологий.
Появлением многокомпонентного программирования.

Далее, мы достаточно подробно рассмотрим все эти явления, но одно следствие всего вышесказанного отметим здесь. Программирование стало более доступным и внешне совсем простым. Появилось множество программных сред со средствами программирования. Молчаливо предполагалось, что любой (!) сможет этими средствами реализовывать для себя специфические задачи, возникающие в процессе обработки данных, что делает, в свою, очередь ненужным наличие программиста.. Практика показала, что 90% пользователей не собираются программировать. Оставшиеся 10% используют средства программирования на любительском уровне, что естественно, так как они не программисты. Таким образом, реально спрос на программистов лишь увеличился. Тем не менее, появление сред со средствами программирования привело к появлению класса программистов – любителей.

Как не раздражает некоторых «профессионалов» наличие любителей, следует понимать, что ненормально, как раз обратное – их отсутствие. Занятие становится профессией тогда, когда оформляются все три класса работников: любители – профессионалы – исследователи. В этом смысле, профессия «программист» завершила своё полное оформление лишь к восьмидесятым – девяностым годам XX века.

Вопросы к главе 1.

Выполнить краткий обзор истории технологии программирования.
Что такое машина фон Неймана? Основные принципы организации универсальной ЭВМ.
Что такое «программирование в коде» - основные принципы, достоинства и недостатки?
Что такое транслятор? Редактор связей? Загрузчик? Почему они существуют?
Что такое исходный, объектный, загрузочный модули? Почему они существуют?
Краткая характеристика архитектуры IBM/360 – сравните технические характеристики этой системы с техническими характеристиками современных ЭВМ.
Представьте, что вы программируете в коде: перечислите основные технологические моменты создания любой программы.
Что такое алгоритмический язык? Основные достоинства программирования на алгоритмическом языке? Недостатки?
Что такое операционная система? Почему они появились?
Что такое система команд ЭВМ? Чем ограничивается количество команд машины?
Что ограничивает размер байта? Что ограничивает длина команды машины?
Что такое программа для ЭВМ? К каким трём типам объектов можно отнести программу? Последствия этого.

Blog

Учебное пособие по курсу «Технология программирования»

Содержание

1. Краткая история технологии программирования