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

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

Содержание

7. К вопросу технологических скачков в программировании.
Смена технологии программирования

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

1 2 3 4 5 6 7 8 9 10

7. К вопросу технологических скачков в программировании.

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

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

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

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

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

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

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

Распределение памяти под данные и программу.
Согласование расположения в памяти программы и соответственно данных.
Соглашение о вызовах подпрограмм и их расположении в оперативной
памяти и на внешних носителях.
Соглашение в передаче/приёме параметров.
Соглашение об использовании некоторых общих объёмов памяти.

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

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

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

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

Отсюда перечислим основные признаки технологического скачка:

1. Наличие новых приёмов, идей, средств в программировании.

2. Наличие новых технических средств или качественное изменение старых. Например, резкое снижение стоимости памяти позволило за те же самые цены увеличить оперативную память ЭВМ.

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

4. ^ Смена технологии программирования!

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

Потребовалось появление системы IBM 360 с совершенно новой архитектурой ЭВМ, операционной системой, наличием нескольких трансляторов с разных языков. Резко сменилась технология разработки и отладки программ и, конечно, увеличилась производительность труда. Теперь она стала составлять около десяти операторов языка в день. Заметим, что мы измеряем производительность труда всё время, сравнивая её с производительностью программирования в коде. Очень важно, что в новых условиях упростилась отладка программного обеспечения и его сопровождение. В связи с фактической монополизацией рынка впервые появилась возможность торговать программным обеспечением. Впервые появились вопросы взаимодействия программ, написанных на разных языках, правда, пока только на уровне исходных модулей и компоновки на уровне объектных модулей.

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

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

Что такое структурное программирование?

Сам термин, как и набор правил, был сформулирован Дейкстрой. Он предложил, вкратце, следующее:

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

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

3. Провести последовательно принцип: один вход – один выход. Это приводит к тому, что запрещаются к использованию неструктурные конструкции языка. То есть такие операторы, как типичный трёхвыходной IF в FORTRANe (но другого IF в FORTRANe нет – логический IF применяется достаточно редко) или оператор ENTRY. Последовательное проведение этого принципа в жизнь оказалось весьма затруднительным. Если с одним входом всё было просто, то с одним выходом сложнее. Это привело к появлению типичных структурных конструкций: break и continue. Но если continue всего лишь маскирует множественность входа в цикл (оператор for в языке C имеет не менее двух входов!), то оператор break смешивает все точки выхода в одну. Типичная проблема структуриста: с какого break он попал на оператор, следующий за циклом. Конечно, проблема решалась просто, например, заведением переменной, которая принимала значение номера break с последующим анализом этой переменной. Но всё это ненужным образом удлиняло программу, да к тому же выполнялись действия, обусловленные синтаксисом языка (!), а не нуждами алгоритма. Этот принцип привёл появлению ещё одного псевдоструктурного оператора: switch. Принципиально этот оператор маскирует как множественность входов, так и множественность выходов. Однако сама конструкция оказалась очень удобной, почему и выжила. Наконец у нас есть оператор return: внешне абсолютно структурный, а по функциям, позволяющий нарушить принцип как одного входа, так и одного выхода.

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

4. Наконец, самый пожалуй известный принцип структурного программирования. Дейкстра заметил, что хаотическое использование оператора goto резко усложняет как понимание программы, так и её отладку и значительно снижает её надёжность. Ну, снижение надёжности  следствие усложнения отладки, так что здесь этого обсуждать не будем. Ну и раз оператор goto такой плохой предложил вообще запретить использование оператора goto. К чести Дейкстры, надо заметить, что он доказал теорему, что без goto можно программировать или написать любую программу. Показал, что удаление goto из арсенала программиста увеличивает длину программы и привёл пример, когда это увеличение составляло 400%. Другими словами – он предложил ограничить использование goto, а не выбрасывать этот оператор. Это последующие структуристы, сославшись на Дейкстру, выбросили goto из программирования. Известно, что роялисты всегда правее короля.

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

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

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

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

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

Собственно же технологический скачок в программировании, сначала просто никто не заметил. Появление объектного языка SmallTalk рассматривалось, как появление ещё одного языка и не более. То есть, объектно-ориентированное программирование появилось несколько раньше требований времени. Тогда, фактически, отсутствовали задачи, которые можно было решить только с помощью объектного – ориентированного программирования. Задачи-то, конечно, были, не было потребности их решать. С другой стороны ООП, также увеличивает программы и соответственно время их выполнения, что приводит к повышенным запросам к возможностям техники, а технические возможности не изменились. Лишь тогда, когда потребовалось решать задачи, которые плохо решались в рамках процедурного программирования и появилась техника, отвечающая повышенным требованиям  появилось ООП.

Таким образом, следующим технологическим скачком было появление персоналок. История повторяется. Персоналки серьёзными программистами сначала рассматривались как обычные игрушки, затем как некие внешние устройства к mainframam. Однако персоналки принесли новые принципы архитектуры ЭВМ. Как только персоналки становятся достаточно мощными, параллельно появляется ряд машин с RISC – набором команд, или RISC-машины: это машины клона Sun, IBM RISC 6000 и т.п.

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

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

Гради Буч [4] пишет: «По-видимому, структурное проектирование, а вместе с ним процедурное программирование подошли к своему пределу. По всей видимости, рамки процедурного программирования, ограничиваются объёмом программы порядка 100 000 строк» (обращаю ваше внимание: структурное проектирование, но процедурное программирование!).

Потребовалось решение нескольких проблем.

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

2. Требовались некие структуры, которые бы явно отражали иерархическое строение большинства сложных данных.

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

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

Сейчас мы рассматриваем появление ООП в свете технологических скачков в программировании. Мы ещё раз подчёркиваем, что уже Simula-67 содержал необходимый аппарат, который был модифицирован и унаследован языком SmallTalk.

Легенда гласит, что Бьёрн Страуструп для реализации идей своей докторской диссертации избрал сначала Smalltalk, но выбранный транслятор был очень медленным и тогда, чтобы успеть вовремя Бьёрн Страуструп на языке Cи отобразил структурами понятие класса, защитил диссертацию в срок, а уж потом предложил новый язык – Cи++.

Нам надо понять является ли ООП технологическим скачком в программировании или нет. Принципиально на лицо все признаки технологического скачка: новые приёмы в технологии, качественное изменение техники, именно последнее, кстати, позволило «всплыть» ООП. Смена в технологии программирования есть? Да, несомненно! Увеличение производительности труда? Последнее, большинство практиков может оспаривать, так как они достаточно плавно перешли на ООП (часть, конечно, осталась в рамках процедурного программирования), и большинство «не заметили» увеличения производительности труда. Однако, если мы сравним «ручное» написание оконной системы под Windows и создание программы даже под Visual Cи++, не говоря уже о Cи++Buildere, то ускорение будет значительное. Согласно нашей концепции ООП будет технологическим скачком.

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

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

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

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

Программная среда должна обеспечивать непрерывную работу в течении длительного времени: месяцами.

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

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

Оказалось, что обеспечить соответствие всем этим требованиям в рамках чисто ООП почти невозможно. На слуху появилось новое понятие компонентное или многокомпонентное программирование. По-другому, ещё говорят программирование с использованием Active X, или программирование с использованием объектов Corba., или ООП с использованием компонентных моделей. Однако терминология здесь ещё не устоялась. Конечно, компонентные модели базируются на ООП, но надо иметь в виду, что это нечто другое.

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

1. Рассмотрение всего в терминах объектов приводит к увеличению размера программы, а значит и к увеличению времени её выполнения. Именно это задержало победное шествие ООП: появилось оно в общем уже 1967г. – но заговорили о нём только в девяностых годах, когда возможности техники позволили игнорировать некоторое увеличение потребности в ресурсах.

2. Разработка программы становится многоступенчатой: отладка собственно классов – написание программы, использующей классы.

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

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

5. При работе требуется достаточно глубокое знание всех используемых классов. Часть же классов используется косвенно. Хотя современные визуальные средства и позволяют просмотреть иерархию классов, всё равно остаётся вопрос, почему средний программист вынужден знать всех предков используемого класса?

6. Несмотря на все достоинства, следует признать, что ООП всё-таки сложнее процедурного программирования, а, следовательно, и тяжелее усваивается средним программистом.

Кроме того, существует и чисто технологические трудности.

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

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

Алгоритмизация прекрасно справляется с задачами до определённой сложности. В программах это означает, что процедурное программирование может быть использовано при реализации программ объёмом примерно до 100 000 строк. Не совсем умно писать программу решения квадратного уравнения в терминах ООП, хотя и можно. С другой стороны, любая интерактивная графическая система или текстовый процессор, лучше реализуются именно с применением ООП. Другими словами: ООП не отрицает алгоритмизации, а «стоит» на её плечах. (Здесь очень полезно вспомнить, что на пике шумихи структурного программирования, наиболее горячие структуристы призывали запретить (!) не структурное программирование). Таким образом, ООП включает в себя процедурное программирование, как один из приёмов выполнения нижнеуровневых процедур, реализующих взаимодействия объектов. Грамотный программист часть задач будет решать процедурно, а часть задач с применением ООП. Всякому приёму своё место и время.

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

1. Что такое технологический скачок? (в программировании). Перечислите признаки технологического скачка.

2. Как вы понимаете структурное программирование? Опишите.

3. Является ли ООП технологическим скачком?

4. Краткая история ООП.

5. Перечислите основные недостатки ООП с точки зрения программиста.

6. Что такое ООП?

7. Соотношение ООП и процедурного программирования.

8. Назовите и характеризуйте основные технологические скачки в программировании.

9. Можно ли обойтись без оператора goto ?

10. Перечислите основные структурные конструкции языка “Cи++”.

11.Продемонстрируйте необходимость «технической поддержки» при технологическом прорыве.

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

Blog

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

Содержание

7. К вопросу технологических скачков в программировании.