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

Предложена в 1970-х годах Э. Дейкстрой[12] и другими.

В соответствии с данной методологией любая программа строится без использования оператора goto из трёх базовых управляющих структур:

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

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

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

По мнению Бертрана Мейера, (одного из ведущих учёных в области программной инженерии)[13] «Революция во взглядах на программирование, начатая Дейкстрой, привела к движению, известному как структурное программирование, которое предложило систематический, рациональный подход к конструированию программ. Структурное программирование стало основой всего, что сделано в методологии программирования, включая и объектное программирование».

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

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

Таким образом была (до известной степени) решена проблема возрастания сложности программных комплексов.

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

1. Большой объем кода (миллионы строк)

2. Большое количество связей между элементами кода

3. Большое количество разработчиков (сотни человек)

4. Большое количество пользователей (сотни и тысячи)

5. Длительное время использования

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

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

Основные принципы и идеи структурного программирования изложены ниже:

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

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

2. Логика любой программы должна опираться на минимальное количество следующих достаточно простых базовых (основных, типовых) управляющих (алгоритмических, логических) структур (конструкций) (БАС): ветвление (или развилка); повторение (или цикл); следование. В скобках приведены различные встречающиеся в литературе названия этих понятий. Первая из структур программируется с помощью полной и сокращённой формы оператора if и вспомогательного оператора выбор (switch на языке Си, case в Pascal и др.). Основными операторами цикла являются оператор цикла с предусловием (while) и с постусловием (do … while на языке Си, repeat … until в Pascal и др.). Несмотря на широкое использование оператора for и его различных модификаций (например, в Visual Basic), этот оператор следует отнести к вспомогательным операторам, так как его всегда можно заменить оператором while. Для программной реализации структуры “следование” не существует оператора. Во всех языках программирования команды выполняются последовательно в том порядке, как они записаны, если не используются операторы, меняющие этот естественный порядок.

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

При этом структурированный алгоритм (программа) должны представлять собой композицию из последовательных или вложенных друг в друга перечисленных выше базовых алгоритмических структур. Например, сначала может быть записан цикл for, а затем вне этого цикла — оператор if. Вложенность БАС имеет место, например, если внутри цикла while встречается оператор выбора switch или наоборот, в одной или в нескольких ветвях if может быть оператор цикла.

3) Важным и самым сложным является следующий принцип. Каждая из БАС должна иметь один вход и один выход. Поэтому структурное программирование в литературе часто называют программированием без оператора goto, который нарушает это требование. Большинство авторов считают плохим стилем программирования, если часто без необходимости используется данный оператор. В то же время запретить его использование было бы неправильно. Иногда этот оператор помогает проще запрограммировать сложные алгоритмы. Например, может возникнуть необходимость в операторе goto, если надо выйти из самого внутреннего цикла за пределы всех циклов при условии, что уровень вложенности их достаточно большой (например, 4 вложенных цикла).

И ещё одно правило, которое должно соблюдаться проектировщиками ПО. Должна соблюдаться строгая дисциплина планирования и документирования, поддержка соответствие кода проектной документации.

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

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

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

В связи с этим был выдвинут и реализован принцип модульного программирования.

Модульное программирование. Главный принцип модульного программирования состоял в выделении таких фрагментов и оформлении их в виде модулей. Каждый модуль снабжался описанием, в котором устанавливались правила его использования – интерфейс модуля.

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

Интерфейс задавал связи модуля с основной программой – связи по данным и связи по управлению. При этом возможность повторного использования модулей определялась количеством и сложностью этих связей, или насколько эти связи удалось согласовывать с организацией данных и управления основной программы. Связи между модулями при использовании данной технологии осуществляются через специальный интерфейс, в то время как доступ к реализации самого модуля (телам подпрограмм и некоторым «внутренним» переменным) запрещен. Эту технологию поддерживают современные версии языков Pascal и С (C++), языки Ада и Modula.

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

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

 

Рис.1.5. Архитектура программы, состоящей из модулей

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

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

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

При увеличении размера программы обычно возрастает сложность межмодульных интерфейсов, и с некоторого момента предусмотреть взаимовлияние отдельных частей программы становится практически невозможно. Для разработки программного обеспечения большого объема было предложено использовать объектный (объектно-ориентированный) подход. Родоначальниками этого подхода были Буч(Booch)[14] и Рамбо (Rumbaugh)[15]

    Теоретические разработки и внедрение этого подхода составляет сущность третьего этапа развития технологий проектирования, активное развитие которого приходится на период с середины 80-ых до конца 90-ых годов 20-го столетия.

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

Объектная структура программы впервые была использована в языке имитационного моделирования сложных систем Simula (60-е годы XX в.), в специализированном языке моделирования Smalltalk (70-е годы XX в.), а затем в новых версиях универсальных языков программирования, таких, как Pascal, C++, Modula, Java.

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

Рис.1.6. Архитектура программы при объектно-ориентированном программировании

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

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

2. Наследование – возможность вывода нового класса из старого с частичным изменением свойств и методов

3. Полиморфизм – определение свойств и методов объекта по контексту

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

В отделе 3 частично изменились правила начисления зарплаты. В этой ситуации при объектно-ориентированном подходе из класса «Зарплата» выводится класс «Зарплата 1», который наследует неизменившиеся правила начисления зарплаты и переопределяет изменившиеся. Здесь при расчете зарплаты объектам «Отдел 1» и «Отдел 2» будет передаваться объект «Зарплата», а объекту «Отдел 3» - объект «Зарплата 1». При таких изменениях:

1. Срабатывает принцип наследования: код «Зарплата», «Отдел 1» и «Отдел 2» остаются без изменения, а код «Зарплата 1» изменяется ровно настолько, насколько это необходимо.

2. Срабатывает принцип полиморфизма: код «Отдел 3» также не изменяется – он продолжает считать, что работает с объектом «Зарплата».

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

Бурное развитие технологий программирования, основанных на объектном подходе, позволило решить многие проблемы. Так были созданы среды, поддерживающие визуальное программирование, например, Delphi, C++ Builder, Visual C++ и т.д. При использовании визуальной среды у программиста появляется возможность проектировать некоторую часть, например, интерфейсы будущего продукта с применением визуальных средств добавления и настройки специальных библиотечных компонентов. Результатом визуального проектирования является заготовка будущей программы, в которую уже внесены соответствующие коды.

Использование объектного подхода имеет много преимуществ, однако его конкретная реализация в объектно-ориентированных языках программирования, таких, как Pascal, C++, Java, C#  и других имеет существенные недостатки, к которым относятся:

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

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

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

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

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

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

Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model — компонентная модель объектов), и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture — общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы и различаются лишь особенностями их реализации.

Технология СОМ фирмы Microsoft является развитием технологии OLE (Object Linking and Embedding — связывание и внедрение объектов), которая использовалась в ранних версиях Windows для создания составных документов. Технология СОМ определяет общую парадигму взаимодействия программ любых типов: библиотек, приложений, операционной системы, т. е. позволяет одной части программного обеспечения использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах на одном компьютере или на разных компьютерах. Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM — распределенная (то есть сетевая) СОМ). Она располагает двоичным интерфейсом и поэтому каждый раз при поддержке нового языка программирования отображения описания интерфейса на языке IDL (Interface Definition Language).

Активное развитие компонентного подхода началось с середины 90-ых годов 20-го столетия и продолжается до нашего времени. Этот период считается четвёртым этапом развития технологии программирования.

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

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