методологии программирования история развития

История развития методологий проектирования (программной инженерии)

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

С чего все начиналось

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

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

Однако, история развития проектного менеджмента как дисциплины относительно молода: ее относят к 30-м годам XX века и связывают с разработкой специальных методов координации инжиниринга крупных проектов в США — авиационных в «US Air Corporation» и нефтегазовых в фирме «Exon». В СССР в этот же период начала развиваться теория и практика поточной организации работ по реализации крупных строительных проектов.

Появление новой дисциплины

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

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

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

Методологии в программной инженерии

С этого момента программирование «обрастает» различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.). Разработка программного кода предваряется анализом и проектированием (первое означает создание функциональной модели будущей системы без учета реализации, для осознания программистами требований и ожиданий заказчика; второе означает предварительный макет, эскиз, план системы на бумаге).
Все эти и другие дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов и будем называть программной инженерией. Получается, что так мы обозначаем, во-первых, некоторую практическую деятельность, а во-вторых, специальную область знания. Или другими словами, научную дисциплину. Ведь для облегчения выполнения каждого отдельного проекта, для возможности использовать разнообразный положительный опыт, достигнутый другими командами и разработчиками, этот самый опыт подвергается осмыслению, обобщению и надлежащему оформлению. Так появляются различные методы и практики (best practices) – тестирования, проектирования, работы над требованиями и пр., архитектурных шаблонов и пр. А также стандарты и методологии, касающиеся всего процесса в целом. Вот эти-то обобщения и входят в программную инженерию как в область знания.
Таким образом методологии в программной инженерии являются одной из самых динамично развивающихся составляющих области знаний, т.к. несут в себе практическую составляющую.
Современная классификация методологий управление проектом или моделей жизненного цикла проекта согласно SWEBOK выглядит следующим образом.
Методологии управления проектами:

Подробнее о методологиях

Как видно из названия традиционные методологии построены на последовательном выполнении всех фаз проекта и конечный продукт будет получен только после выполнения всех этапов. Возвращение на предыдущий этап не предусмотрено и при появлении критических ошибок весь проект начинается сначала. Основным примером таких методологий разработки является каскадная модель или модель Водопад. Источником данной модели принято считать статью Уинстона Ройса вышедшею в 1970 году. Однако, сам Ройс описывал эту модель как пример противопоставленный итеративной модели, применимый только для очень простых проектов и сам пользовался итеративными методологиями. Так же Ройс писал, что в особо сложных местах проекта и при применении новых, ранее не используемых технологий, промежуточные этапы можно повторить дважды и заказчик по окончанию проекта получает вторую версию продукта. Такой подход нельзя назвать итеративным, но и однозначно последовательным тоже. На начальном периоде она сыграла ведущую роль как метод регулярной разработки сложного ПО. В 70x — 80x годах XX века модель была принята как стандарт министерства обороны США.
По мере развития методологий каскадная модель подвергалась жесткой критики со стороны всех исследователей, предлагавших свои методологии. Последовательное выполнение этапов разработки не дает изменить требования к программному продукту до самого релиза. Чем больше проект тем больше накапливается проблем в процессе проектирования. И реализация изменений в следующей версии продукта иногда становится не целесообразной. Продукт необходимо писать с 0. Таким образом стоимость работоспособной версии не оправдано сильно растет. А процент успешно завершенных проектов ничтожно мал. Однако, можно ли назвать традиционные методологии разработки отжившими свой век? Не совсем. Для проектов затрагивающих безопасность жизнедеятельности строго поставленные требования и высокая степень формализации является основополагающим и необходимым фактором.
Кроме того, несмотря, на модную сейчас критику традиционной модели, она играет важную роль, потому что налагает на процесс разработки требование крайне необходимой для него дисциплинированности, с помощью которой удается благополучно обходить неструктурированные процессы типа «пишем и правим». Данная модель внесла фундаментальный вклад в понимание процессов разработки ПО следующими утверждениями:

Спиральная модель ЖЦ стала следующим (после водопадной) этапом развития методологий разработки, поскольку она решает основную проблему каскадной модели. Каждая фаза водопадного процесса разработки в спиральной методологии завершается этапом прототипирования и управления рисками. Этап прототипирования после каждой фазы проекта позволяет определить, насколько текущее состояние проекта соответствует первоначальному плану. По итогам прототипирования выполняется либо переход к следующей фазе, либо возвращение на одну из предыдущих фаз. Однако фазы и последовательность фаз остаются линейными. Автором данной модели является Барри Боэм, опубликовавший в 1988 году статью «A Spiral Model of Software Development and Enhancement». Не смотря на то, что в SWEBOK данная модель выделена отдельно от итеративной, при описании моделей напрашивается вывод об отнесении спиральной методологии к семейству итеративных. Это обуславливается и возможностью изменения требований между этапами и выпуска прототипов продукта после каждого цикла. Возможно такое разделение связано с авторской принадлежностью методологий.

Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Упоминания о данной методологии начали появляться задолго до статьи У. Ройса и появления самой программной инженерии. Истоки концепции итеративной разработки прослеживаются в относящихся к 30-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта из Bell Labs. Важной вехой в истории является осуществленный в 50-е годы проект по разработке сверхзвукового реактивного самолета X-15. По мнению участников этих работ, применение данной методологии в значительной степени определило успех проекта.
Наиболее обсуждаемые сейчас гибкие методологии разработки (Agile методологии) относятся именно к итеративным моделям ЖЦ. При описании любой из гибких методологий упоминается принцип разделения на итерации. Однако, особенность данных методологий это упор на человеческий фактор, а не на документацию проекта, что никак не обозначается в описании итеративной и инкрементной методологии.

Гибкие методологии разработки начали появляться на фоне быстрорастущего усложнения технологий и всеобщей информатизации. Теперь заказчиком в большинстве случаев является лицо далекое от информационных технологий. Для такого заказчика главным является готовый продукт, а не фолианты документации. При экспоненциально растущем темпе развития информационных технологий сроки на разработку ПО сократились и стали жестче. Теперь нет времени на долгое планирование, написание документации и полновесное тестирование. Программный продукт может устареть еще до релиза. В противовес традиционным методологиям разработки итеративные методологии делят выполнение проекта на короткие итерации, ограниченные по времени. После каждой итерации заказчику продукта предоставляется результат. Предусмотрен откат на предыдущие итерации. Появление гибких методологий не привязано к конкретной дате, так как начиная с середины 90х годов начали появляться и внедряться практически параллельно. Это были методологии разработки такие как: Scrum (1995), экстремальное программирование (1996), Crystal Clear, Lean, Kanban и другие. Созданный в феврале 2001 года, Agile-манифест, провозгласил философию гибких методологий разработки и задал вектор развития данных методологий.

Современный этап развития методологий

Сейчас выбор методологии проектирования как никогда подвержен влиянию маркетинга. Все больше появляется консультантов по внедрению agile, коучеров, проводящих бесконечные тренинги, семинары, вэбинары, бесконечные встречи, конференции, круглые столы. Все эти мероприятия направлены на продажу внедрения в ИТ-компаниях за большие деньги приглашенными специалистами или повышения рейтинга компаний, которые уже внедрили гибкие методологии.
Гибкие методологии сейчас — это в большей степени свод знаний по организации работы людей с психологической точки зрения. Такие методологии помогают команде проявлять творческую составляющую, умение работать в команде, навыки коммуникации и прочее. Техническая сторона организации работ все больше уходит на второй план. Только ХР(Экстремальное программирование) имеет в своем арсенале такие инженерные практики как разработка через тестирование, метафоры и рефакторинг. Эти практики с успехом применяются в сочетании с другими методологиями. При некачественном внедрении Agile мы получаем то, что сейчас происходит на рынке IT продуктов. Рынок перенасыщен некачественными, нестабильными продуктами, не отвечающими требованиям не к функционалу, ни к интерфейсу. При этом, что скорость выпуска таких продуктов, благодаря пропагандируемому Agile принципу непрерывной интеграции, постоянно растет.

с набирающим обороты снижением качества выпускаемых IT продуктов стали появляться методологии, стремящиеся это качество повысить. Такой методологией стал DEvOps.
Термин «devops» был популяризирован на конференции «Дни DevOps» («DevOps Days») в 2009 году в Бельгии. С тех пор такая методология все больше набирает популярность.Это отчасти связано с тем, что принципы DevOPs пропагандируют не отказ от действующей в организации методологии, а сочетание с ней. Общая концепция DevOps заключается в усилении кооперации между группами разработки(DEVelopments) и эксплуатации(OPerations) в рамках одной организации, несущими ответственность за разработку ПО. Данная методология это без преувеличения новый виток эволюции методологий разработки поскольку ориентирована не только на удовлетворение требований заказчика в жестко определенные сроки, но и повышение качества и стабильности продукта.

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

Источник

2. Императивное программирование.

Императивное программирование — это исторически первая методология программирования, которой пользовался каждый программист, программирующий на любом из «массовых» языков программирования – Basic, Pascal, C.

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

Методы и концепции.

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

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

Традиционное средство структурирования — подпрограмма (процедура или функция). Подпрограммы имеют параметры и локальные определения и могут быть вызваны рекурсивно. Функции возвращают значения как результат своей работы.

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

Императивные языки программирования.Императивные языки программирования манипулируют данными в пошаговом режиме, используя последовательные инструкции и применяя их к разнообразным данным. Считается, что первым алгоритмическим языком программирования был язык Plankalkuel (от plan calculus), разработанный в 1945—1946 годах Конрадом Цузе (Konrad Zuse).

Большинствои из наиболее известных и распространенных императивных языков программирования было создано в конце 50-х — середине 70-х годов XX века. Это период 80-х и 90-х годов соответствует увлечениям новыми парадигмами, и императивных языков в это время практически не появлялось.

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

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

Рекомендации по литературе. Особенности императивного программирования изложены в огромном количестве книг. Наиболее систематично они приведены в работе «Универсальные языки программирования. Семантический подход» [Калинин, Мацкевич 1991].

2.1. Модульное программирование.

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

Концепции модульного программирования. В основе модульного программирования лежат три основных концепции:

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

Аксиома модульности Коуэна. Модуль — независимая программная единица, служащая для выполнения некоторой определенной функции программы и для связи с остальной частью программы. Программная единица должна удовлетворять следующим условиям:

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

синтаксическая обособленность, т. е. выделение модуля в тексте синтаксическими элементами;

семантическая независимость, т. е. независимость от места, где программная единица вызвана;

общность данных, т. е. наличие собственных данных, сохраняющихся при каждом обращении;

полнота определения, т. е. самостоятельность программной единицы.

Сборочное программирование Цейтина. Модули — это программные кирпичи, из которых строится программа. Существуют три основные предпосылки к модульному программированию:

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

потребность организационного расчленения крупных разработок;

возможность параллельного исполнения модулей (в контексте параллельного программирования).

Определения модуля и его примеры. Приведем несколько дополнительных определений модуля.

Модуль — это совокупность команд, к которым можно обратиться по имени.

Модуль — это совокупность операторов программы, имеющая граничные элементы и идентификатор (возможно агрегатный).

Функциональная спецификация модуля должна включать:

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

Разновидности модулей. Существуют три основные разновидности модулей:

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

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

a)задачи в языке программирования Ada;

b)кластер в языке программирования CLU;

c)классы в языках программирования C++ и Java.

3) «Большие” (логические) модули, объединяющие набор «средних» или «маленьких» модулей. Примеры «больших» модулей в языках программирования:

a)модуль в языке программирования Modula-2;

b)пакеты в языках программирования Ada и Java.

Набор характеристик модуля предложен Майерсом [Майерс 1980]. Он состоит из следующих конструктивных характеристик:

В модуле должно быть 7 (+/-2) конструкций (например, операторов для функций или функций для пакета). Это число берется на основе представлений психологов о среднем оперативном буфере памяти человека. Символьные образы в человеческом мозгу объединяются в «чанки» — наборы фактов и связей между ними, запоминаемые и извлекаемые как единое целое. В каждый момент времени человек может обрабатывать не более 7 чанков.

Модуль (функция) не должен превышать 60 строк. В результате его можно поместить на одну страницу распечатки или легко просмотреть на экране монитора.

2) прочности (связности) модуля;

Существует гипотеза о глобальных данных, утверждающая, что глобальные данные вредны и опасны. Идея глобальных данных дискредитирует себя так же, как и идея оператора безусловного перехода goto. Локальность данных дает возможность легко читать и понимать модули, а также легко удалять их из программы.

Связность (прочность) модуля (cohesion) — мера независимости его частей. Чем выше связность модуля — тем лучше, тем больше связей по отношению к оставшейся части программы он упрятывает в себе. Можно выделить типы связности, приведенные ниже.

Функциональная связность. Модуль с функциональной связностью реализует одну какую-либо определенную функцию и не может быть разбит на 2 модуля с теми же типами связностей.

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

Информационная (коммуникативная) связность. Модуль с информационной связностью — это модуль, который выполняет несколько операций или функций над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Эта информационная связность применяется для реализации абстрактных типов данных.

Обратим внимание на то, что средства для задания информационно прочных модулей отсутствовали в ранних языках программирования (например, FORTRAN и даже в оригинальной версии языка Pascal). И только позже, в языке программирования Ada, появился пакет — средство задания информационно прочного модуля.

3) сцепления модуля с другими модулями;

Сцепление (coupling) — мера относительной независимости модуля от других модулей. Независимые модули могут быть модифицированы без переделки других модулей. Чем слабее сцепление модуля, тем лучше. Рассмотрим различные типы сцепления.

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

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

Сцепление по простым элементам данных.

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

4) рутинности (идемпотентность, независимость от предыдущих обращений) модуля.

Рутинность — это независимость модуля от предыдущих обращений к нему (от предыстории). Будем называть модуль рутинным, если результат его работы зависит только от количества переданных параметров (а не от количества обращений).

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

В большинстве случаев делаем модуль рутинным, т. е. независимым от предыдущих обращений.

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

2.2. Структурное программирование.

Структурное программирование (СП) возникло как вариант решения проблемы уменьшения СЛОЖНОСТИ разработки программного обеспечения.

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

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

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

Подход базируется на двух основных принципах:

Последовательная декомпозиция алгоритма решения задачи сверху вниз.

Использование структурного кодирования.

Напомним, что данная методология является важнейшим развитием императивной методологии.

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

Методы и концепции, лежащие в основе структурного программирования. Их три

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

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

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

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

Следствие 1: Всякую программу можно привести к форме без оператора goto.

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

Практически на всех языках, поддерживающих императивную методологию, можно разрабатывать программы и по данной методологии. В ряде языков введены специальные заменители оператора goto, позволяющие облегчить управление циклами (например, Break и Continue в языке C).

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

Рекомендации по литературе. Одной из наиболее известных работ в этой области является статья «Заметки по структурному программированию» [Дейкстра 1975]. Методы структурного программирования подробно рассмотрены в книге «Теория и практика структурного прграммирования» [Лингер, Миллс, Уитт 1982]. Практику структурного программирования можно изучать по книге «Алгоритмы + структуры данных = программы» [Вирт 1985]. Философия визуального структурного программирования подробно изложена в работе [Паронджанов 1999].

3. Метод объектно-ориентированного программирования.

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

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

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

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

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

Основные методы и концепции ООП

Метод объектно-ориентированной декомпозиции – заключается в выделении объектов и связей между ними. Метод поддерживается концепциями инкапсуляции, наследования и полиморфизма.

Метод абстрактных типов данных – метод, лежащий в основе инкапсуляции. Поддерживается концепцией абстрактных типов данных.

Метод пересылки сообщений – заключается в описании поведения системы в терминах обмена сообщениями между объектами. Поддерживается концепцией сообщения.

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

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

Синтаксис и семантика

В синтаксисе чистых объектно-ориентированных языков все может быть записано в форме посылки сообщений объектам. Класс в объектно-ориентированных языках описывает структуру и функционирование множества объектов с подобными характеристиками, атрибутами и поведением. Объект принадлежит к некоторому классу и обладает своим собственным внутренним состоянием. Методы — функциональные свойства, которые можно активизировать.

В объектно-ориентированном программировании определяют три основных свойства:

Инкапсуляция. Это сокрытие информации и комбинирование данных и функций (методов) внутри объекта.

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

Большинство окружающих нас объектов относится к категориям, рассмотренным в книге [Шлеер, Меллор 1993]:

Реальные объекты – абстракции предметов, существующих в физическом мире;

Роли – абстракции цели или назначения человека, части оборудования или организации;

Инциденты – абстракции чего-то произошедшего или случившегося;

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

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

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

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

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

Пример описания в некотором абстрактном Pascal-подобном объектно-ориентированном языке класса «точка», являющегося наследником класса «координаты» может выглядеть так:

Type TCoordinates = class (TObject)

Constructor Init (_x, _y : integer);

Function GetX : integer;

Function GetY : integer;

Procedure SetX (_x : integer);

Procedure SetY (_y : integer);

Procedure Move (dx, dy : integer);

Destructor Done; virtual;

Function GetX : integer;

TPoint = class (TCoordinates)

Constructor Init (_x, _y, _Color : integer);

Function SetColor (_Color : integer);

Function GetColor : integer;

Constructor Init(_x, _y, _Color : integer);

Inherited Init(_x, _y);

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

Для поддержки концепции ООР были разработаны специальные объектно-ориентирован-ные языки программирования. Все языки OOP можно разделить на три группы.

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

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

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

4. Логическое программирование.

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

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

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

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

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

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

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

в качестве примеров языков логического программирования можно привести Prolog (название возникло от слов PROgramming in LOGic) и Mercury.

5. Функциональное программирование.

Функциональный подход к программированию появился в результате проведения фундаментальных математических исследований.

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

Что касается первой реализации, то она появилась в 50-х годах XX столетия в форме языка LISP, о котором речь пойдет далее.

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

Функциональный подход породил целое семейство языков, родоначальником которых, как уже отмечалось, стал язык программирования LISP. Позднее, в 70-х годах, был разработан первоначальный вариант языка ML, который впоследствии развился, в частности, в SML, а также ряд других языков. Из них, пожалуй, самым «молодым» является созданный уже совсем недавно, в 90-х годах, язык Haskell.

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

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

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

Благодаря реализации механизма сопоставления с образцом, такие языки функционального программирования как ML и Haskell хорошо использовать для символьной обработки.

Естественно, языки функционального программирования не лишены и некоторых недостатков.

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

Заметим, что под термином «функция» в математической формализации и программной реализации имеются в виду различные понятия.

Так, математической функцией f с областью определения A и областью значений B называется множество упорядоченных пар

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

Для формализации понятия «функция» была построена математическая теория, известная под названием ламбда-исчисления. Более точно это исчисление следует именовать исчислением ламбда-конверсий.

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

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

Рассмотрим эволюцию языков программирования, развивающихся в рамках функционального подхода.

Ранние языки функционального программирования, которые берут свое начало от классического языка LISP (LISt Processing), были предназначены, для обработки списков, т.е. символьной информации. При этом основными типами были атомарный элемент и список из атомарных элементов, а основной акцент делался на анализе содержимого списка.

Развитием ранних языков программирования стали языки функционального программирования с сильной типизацией, характерным примером здесь является классический ML, и его прямой потомок SML. В языках с сильной типизацией каждая конструкция (или выражение) должна иметь тип.

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

Следующим шагом в развитии языков функционального программирования стала поддержка полиморфных функций, т.е. функций с параметрическими аргументами (аналогами математической функции с параметрами). В частности, полиморфизм поддерживается в языках SML, Miranda и Haskell.

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

Семейство языков функционального программирования довольно многочисленно. Об этом свидетельствует не столько значительный список языков, сколько тот факт, что многие языки дали начало целым направлениям в программировании. Напомним, что LISP дал начало целому семейству языков: Scheme, InterLisp, COMMON Lisp и др.

Не стал исключением и изучаемый нами язык программирования SML, который был создан в форме языка ML Р. Милнером (Robin Milner) в MIT (Massachusetts Institute of Technology) и первоначально предназначен для логических выводов, в частности, доказательства теорем. Язык отличается строгой типизацией, в нем отсутствует параметрический полиморфизм.

Развитием «классического» ML стали сразу три современных языка с практически одинаковыми возможностями (параметрический полиморфизм, сопоставление с образцом, «ленивые» вычисления). Это язык SML, разработанный в Великобритании и США, CaML, созданный группой французских ученых института INRIA, SML/NJ – диалект SML из New Jersey, а также российская разработка – mosml («московский» диалект ML).

Близость к математической формализации и изначальная функциональная ориентированность послужили причиной следующих преимуществ функционального подхода:

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

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

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

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

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

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

Информация взята с источников:

Источник