Выводы по третьему этапу.

Лекция 1

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

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

История развития вычислительной техники. История развития вычислительной техники более стара, чем это принято считать. Так, одним из первых примеров вычислительных машин, или компьютеров, можно назвать «механизм из Антикитеры» (см. более подробно историю открытия в [1]).  В 1900 году греческий ныряльщик Элиас Стадиатис  обнаружил на дне Эгейского моря, у берегов небольшого острова Антикитера (в другой транскрипции, Антикифера, Антикитира), расположенного между Пелопонесом и Критом, обломки странного механизма, поднятого с затонувшего судна.

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

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

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

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

В мае 1994 года американский исследователь Стив Крамер на ее примере продемонстрировал возможности «компьютера Древней Греции», предсказав солнечное затмение с точностью до 14 минут.

Механизм использовал геоцентрическую модель Птолемея, рассчитывая движение планет Солнечной системы, восходы и закаты по теории эпициклов. Были сделаны и предположения о его пользователях, и мастерах, которые изготовили эту модель: скорее всего, механизм был изготовлен некоторыми из учеников Архимеда примерно 150 лет до н. э. и продан жрецам Древнего Египта, где использовался для составления календарей, и расчёта праздников (см. подробнее [1]).

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

Далее, в средние века в трактатах аль-Хорезми появляется понятие об алгоритме.

Затем, крупный вклад в развитие вычислительной техники внёс Готфрид фон Лейбниц. Так, он придумал двоичную систему исчисления, обосновал её применимость для вычислительной техники, а также построил «пошаговый вычислитель», то есть, калькулятор.  Он также изобрёл философскую теорию «монадологию»,  имевшую для него большой мировозренческий смысл, но не нашедшую практического применения (вплоть до середины 20 века, когда развитие теоретической математики, метаматематики, с одной стороны, и развитие теории типов, теории моделей, теории множеств не оформилось в раздел «теории категорий», в которой также возникают монады – уже в виде математических абстракций, наподобие групп, колец, алгебр).

Затем развивается двоичная алгебра Джона Буля.

Чарльз Беббидж строит прообраз вычислительной машины, двух видов. Однако он затрудняется объяснить, как эта машина работает. Описание машины, как и теорию вычислений составляет графиня Ада Лавлейс. Одна из машин так и не была построена при жизни Чарльза Беббиджа, но Джордж Шойтц по описанию Беббиджа строит дифференциальный анализатор. Другая машина была построена сыном Беббиджа после его смерти.

В станках Жака Жаккарда, которые были изобретены примерно в это же время, рисунок, по которому работает ткацкий станок задаётся перфокартой. Ада Лавлейс уподобляет машину Беббидбжа станку Жаккарда: «… так же,  как станок ткёт ткацкий рисунок, машина Беббиджа ткёт структуру вычислений». Также Ада Лавлейс описывает память программ и данных, устройство АЛУ.

В истории описан первый этап развития вычислительной техники [2] – устройства-калькуляторы, устройства-арифмометры. Таким образом, устройство конкретного «арифмометра» изобреталось несколько раз, в период 1632-1890 годов.  Часть этих машин существовала только на бумаге, так и не будучи построенными.

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

Второй этап развития ВТ связан с появлением электронно-вычислительных машин, ЭВМ. Здесь уже были придуманы не только конкретные конструкции машин, но и общие теории вычислений (машина Тьюринга и лямбда-исчисление Алонзо Чёрча), а также архитектуры ЭВМ (архитектура фон Неймана с общей памятью; затем, Гарвардская архитектура). Также появились первые языки программирования высокого уровня (например, Plankalkul, LISP, FORTRAN).

Машина Тьюринга является универсальной логической моделью вычислительной машины. Аланом Тьюрингом была доказана теорема об эквивалентности любой вычислительной машины, построенной на основе архитектуры фон Неймана его «машине Тьюринга». Она оказалась удобной моделью для доказательства свойств алгоритмов, программ. Так, известна проблема останова: если на вход машине Тьюринга, управляемую определённой программой подать её саму, то математически неразрешимой (в смысле P=NP) является вопрос, отработает программа, или «зациклится».

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

Лямбда-исчисление Алонзо Чёрча являлось другой моделью вычислений (вместо машины Тьюринга), как вычисление «чистых функций» – и в дальнейшем послужило основой функционального программирования.  Была также доказана теорема об эквивалентности лямбда-исчисления и машины Тьюринга.

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

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

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

Эдсгер Дейкстра, столкнувшись с проблемами первых языков программирования типа FORTRAN, пишет работу «Оператор GOTO считать вредным» и предлагает идею структурного программирования.

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

Третий этап в развитии ВТ происходит, когда начинают появляться разнообразные языки программирования. Сначала возникает разделение на языки низкого (такого, как машинный код, или ассемблер) и высокого уровней. Затем, языки высокого уровня (ЯВУ) сами начинают разделяться по используемому набору концепций, идиом и подходов – или, парадигм программирования.

Так, различают следующие парадигмы программирования:

· императивную (выполнение программы, как последовательного алгоритма),

· функциональную (программа это вычисление «чистых функций» лямбда-исчисления Алонзо Чёрча)

· логическую (программа это рассуждения в логике предикатов)

и т. д.

Императивная, в свою очередь, делится на:

• Процедурную (например, FORTRAN или BASIC – в ранних версиях языков не существовало деления на процедуры, активно использовался оператор перехода GOTO, приводивший к «спагетти коду»)
• Структурную (использование GOTO ограничено – см. работу Э. Дейкстры «Оператор GOTO считается вредным», работы [3] Дейкстры, Хоара и т.п. как приложение – в этой работе была озвучена идея-прообраз модульного и объектно-ориентированного программирования)
• Модульную парадигму программирования  (если в структурном программировании структура задаётся на уровне функций и абстрактных типов данных, ADT, то в модульном – к тому же, на основании отношения импорта-экспорта модулей, которые являются единицами раздельной компиляции)
• Объектно-ориентированную парадигму

ООПпрограммирование является логическим развитием идей структурного программирования. Это концепция, направленная не на теорию программирования, как, например, функциональное – а на её практику. Согласно парадигме ООП программа представляется в виде набора объектов, имеющих тип класс и обладающих данными и поведением (то есть, классы содержат свойства, или ADT типы и методы, то есть, функции, связанные с классами). Между собой классы находятся в отношениях: наследования, инкапсуляции, полиморфизма. Различные ООП языки (например, SmallTalk, Simula, CLOS) характеризуются различными объектными моделями, показывающими, как именно реализован ООП подход  и эти три базовых принципа наследования, инкапсуляции, полиморфизма в конкретном языке. Так, например, в С++ есть понятие виртуальный метод, а в SmallTalk и CLOS – метаклассы. Это особенности реализации конкретной объектной модели, а не свойства языка в целом – возможно, хотя и трудоёмко реализовать в C++ метаклассы, а в CLOS – VTable диспетчеризацию. В некоторых языках, например Common Lisp можно реализовать без переделки ядра языка любую объектную модель, хотя большинство, например, Java – рассчитаны только на одну-единственную реализацию объектной модели «в ядре языка».

 Есть мультипарадигменные языки, такие, как Common Lisp, которые способны поддерживать несколько парадигм программирования (например: Common Lisp: функциональная, объектная; C++ : объектная, структурная, декларативная(шаблоны)).

Первый объектно-ориентированный (ОО) язык появился в 1967 году, Simula-67. Он применялся в датских университетах для преподавания и моделирования, однако его первые реализации были ненадёжны – медленны, и потребляли много ресурсов. Однако, модель объектов практически без изменений была использована в языке С++.

Второй ООП язык, SmallTalk был изобретён в середине 1970х, однако его реализации тоже были малопроизводительны. Однако он широко применялся для моделирования, например, в лаборатории Xerox PARC Labs, где были изобретены сеть Ethernet, лазерный принтер и графический интерфейс пользователя (GUI) – идея которого была применена Стивом Джобсом, посетившим лабораторию в проектах LISA и Macintosh).

В то же самое время, 1970х-1990х, для языков Lisp были реализованы две объектные модели: Flavors, с посылкой сообщений, как в SmallTalk, и CLOS.

Третьим ООП языком можно считать язык Eiffel. Этот язык был изобретён Бертраном Мейером в 1985 году как результат его преподавания курсов по ООП, где в качестве иллюстрации примеры приводились на языке Си.

Язык Си оказался неудобен, и Мейер начал заменять его псевдокодом, попутно составляя «теорию ООП». Были опубликованы книги, например [4].

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

Так, ООП модель SmallTalk используется в языке Objective C. Модель Simula – в C++, C#, Java, D, частично в Delphi.

Из примеров других реализаций объектных моделей языка можно привести языки Io, JavaScript с прототипно-ориентированным ООП, и объектную модель CLOS в языках Common Lisp и Dylan.

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

Выводы по третьему этапу.

Дальнейшее развитие ВТ проявлялось в развитии языков программирования.

Основной проблемой в их развитии являлась проблема структурирования сложности.

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

Первые ОО языки были разработаны, но их реализация была неэффективна.

Четвёртый этап развития ВТ состоит в том, что практика и теория программирования становятся более зрелыми.

В 1990-е возникает множество ОО языков программирования, существующие реализации становятся более практичными.

Развивается также «теория ООП», например, «Объектно-ориентированные анализ и проектирование приложений» Гради Буча, метод Eiffel и BON-нотация, работы Luca Cardeli по составлению системы типов, операционной семантики и исчисления объектов.

Возникают попытки переосмыслить полученный практический опыт с точки зрения теории, и такие понятия, как  паттерны проектирования и архитектура приложения, языки моделирования UML, BON и моделеориентированная архитектура ( MDA ), рефакторинг, разработка через тестирование (TDD, или Test - Driven Development ).

Развиваются и методики применения ООП и управления процессом разработки на практике: RAD Rapid Application Development – быстрая разработка программ;  его дальнейшее развитие, ALM Application Lifecycle Management ­– управление жизненным циклом приложения; строгие методологии разработки,  такие как: RUP, Rational Unified Process, и гибкие, такие как: XP, «Экстремальное программирование»,  SCRUM, Crystal, FDD и т.п.

С точки зрения практики, поворотным моментом являются понятия:

• шаблоны и обобщённые типы ( generics ) – типобезопасно задаётся общий алгоритм
• обобщённого программирования (на примере С++ библиотек STL и Boost, ATL/WTL) – библиотека задаёт алгоритм посредством шаблонов
• паттерны и антипаттерны – сложившиеся идиомы проектирования, лучшие практики, как проектировать правильно, и как неправильно (антипаттерны)
• юнит-тестирование (модульное), приёмочные тесты, автотестирование
• разработка через тестирование ( TDD ) – подход, когда сначала пишутся тесты, потом код, который проходит тесты, которые переделываются, когда в результате доработок код изменяется. Таким образом, тесты выступают в качестве документации, примеров по использованию остальной части программы. Это открывает возможность к
• рефакторингу – переработке старого, непонятного, громоздкого кода, который сложно поддерживать. Рефакторинг сохраняет поведение кода, улучшая его структуру и «понятность». Качеству «понятности» полностью соответствует
• «чистый код» – код, который написан настолько очевидно ясно, не запутанно, что его легко понимать, сопровождать и поддерживать (см. [5]).
• Гибкие методологии разработки – процесс разработки программы-прототипа ДО окончательного выяснения всех подробных требований. В ранних строгих процессах разработки разработка не начиналась до того, как ВСЕ требования к программе не будут выяснены, зафиксированы и не будут изменяться. Это имеет смысл, когда программу сложно переделать (например, прошивку для управления станком, роботом) и нужно сделать её правильно с первого раза – потому что накладные расходы на переработку огромны из-за других процессов (перевыпуск всех ПЗУ с новой прошивкой). В гибких методологиях процессов разработки это требование упрощается – набор требований может меняться по ходу разработки, и окончательно не зафиксируется никогда – потому что программу понадобится дорабатывать, перерабатывать под новые требования заказчика. Следовательно, этот процесс должен быть наиболее лёгок, гибок – а акцент смещается на разработку прототипа, демонстрирование прототипа заказчику и более плотную работу с заказчиком, уточнение требований и быстрый цикл обратной связи, планирование релизов и версий.