16. Методы программирования: структурный, модульный, объектно-ориентированный. Достоинства и недостатки методов программирования.

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

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

Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно-ориентированного подхода, которое Гради Буч сформулировал следующим образом: объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований.

Буч отмечает также ряд следующих преимуществ объектно- ориентированного подхода:

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

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

3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

4. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.

К недостаткам объектно-ориентированного подхода относятся некоторое снижение производительности функционирования ПО и высокие начальные затраты. Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и дополнительными финансовыми затратами. Безусловно, объектно-ориентированная модель наиболее адекватно отражает реальный мир, представляющий собой совокупность взаимодействующих (посредством обмена сообщениями) объектов. Но на практике в настоящий момент продолжается формирование стандарта языка объектно-ориентированного моделирования UML, и количество CASE-средств, поддерживающих объектно-ориентированный подход, невелико по сравнению с поддерживающими структурный подход. Кроме того, диаграммы, отражающие специфику объектного подхода (диаграммы классов и т.п.), гораздо менее наглядны и плохо понимаемы непрофессионалами. Поэтому одна из главных целей внедрения CASE-технологии, а именно снабжение всех участников проекта (в том числе и заказчика) общим языком "для передачи понимания", обеспечивается на сегодняшний день только структурными методами. Преимущества, которые предоставляет модульное программирование. Во-первых, как уже отмечалось, это возможность писать модули на разных языках программирова-ния. Во-вторых, модуль является естественной единицей локализации имен: как уже говорилось, внутри модуля на Ассемблере все имена должны быть различны (уникальны),1 что не очень удобно, особенно когда модуль большой по объему или совместно пишется разными программистами. А вот в разных модулях Ассемблера имена могут совпадать, так как имена, как и в блоке программы на языке Паскаль, локализованы в модуле на Ассемблере и не видны из другого модуля, если только это не указано явно с помощью специальных директив.

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

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

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

• Во-первых, модули не являются совсем уж независимыми друг от друга: между ними суще-ствуют связи, то есть один модуль иногда может использовать переменные, константы и программный код другого модуля. Необходимость связей между модулями естественно вы-текает из того факта, что модули совместно решают одну общую задачу, при этом каждый модуль выполняет свою часть задачи, получая от других модулей входные данные и пере-давая им результаты своей работы. Заметим, что все такие связи между модулями на Ас-семблере должны быть явно заданы при описании этих модулей.1

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

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