326 Глава
Модульное программирование
Модульный подход позволяет безболезненно производить модернизацию про-
граммы в процессе ее эксплуатации и облегчает ее сопровождение. Дополнитель-
но модульный подход позволяет разрабатывать части программ одного проекта на
разных языках программирования, после чего с помощью компоновочных средств
объединять их в единый загрузочный модуль.
Основная цель модульного подхода — простота и ясность реализуемых реше-
ний. Если вы затрудняетесь четко сформулировать назначение модуля, это гово-
рит о том, что один из предыдущих этапов декомпозиции задачи был проведен
недостаточно качественно. В этом случае необходимо вернуться на один или бо-
лее шаг назад и еще раз проанализировать задачу этапа, вызвавшего проблему. Это,
возможно, приведет к появлению дополнительных модулей в процессе функцио-
нальной декомпозиции.
При наличии в проекте сложных мест их нужно подробно документировать
с помощью продуманной системы комментариев. Комментарии должны быть яс-
ными в смысле отражения реализуемых идей и подчиняться некоторой системе —
частной, если разработчик — частное лицо, или корпоративной, действующей внут-
ри некоторого организованного коллектива разработчиков. По поводу системы
комментирования можно еще раз напомнить несколько широко известных идей.
Во-первых, желательно назначение всех переменных модуля описывать коммен-
тариями по мере их определения. Во-вторых, исходный текст модуля должен иметь
заголовок, отражающий назначение модуля и его внешние связи. Этот заголовок
можно назвать
модуля. В интерфейсной части с использо-
ванием комментариев нужно поместить информацию о назначении модуля, об осо-
бенностях функционирования, о входных и выходных аргументах, об исполь-
зовании внешних модулей и
а также о разработчике — для защиты
авторских прав.
В ходе разработки программы следует предусматривать специальные блоки
операций, учитывающие реакцию на возможные ошибки в данных или
действи-
ях пользователя. Это очень важный момент, означающий, что в алгоритме
граммы не должно быть тупиковых ветвей, в результате работы которых программа
«виснет» и перестает отвечать на запросы пользователя. Любые непредусмотрен-
ные действия пользователя должны приводить к генерации ошибочной ситуации
или к предупреждению о возможности возникновения такой ситуации.
Из этих положений видно, какое большое значение придается организации
управляющих информационных связей между структурными единицами програм-
мы (модулями), совместно решающими одну или несколько больших задач. При-
менительно к языку ассемблера можно рассматривать несколько форм организа-
ции управляющих связей.
Si Макроподстановки позволяют изменять исходный текст программы в соответ-
ствии с некоторыми предварительно описанными параметризованными
объектами. Эти объекты имеют формальные аргументы, замещаемые в процес-
се макрогенерации их фактическими аргументами. Такая форма образования
структурных элементов носит некоторый предварительный характер из-за того,
что процессы замены происходят на этапе компиляции и есть смысл рассмат-
ривать их только как настройку на определенные условия функционирования
программы.
Процедуры в языке ассемблера 327
Объединение в одну программу подпрограмм, написанных на ассемблере.
В языке ассемблера такие подпрограммы называют
процедурами. В отличие от
взаимодействие процедур осуществляется на этапе выполнения
программы.
ii Объединение в единый модуль на этапе компоновки подпрограмм, написан-
ных на разных языках программирования. Эта возможность реализуется бла-
годаря унифицированному формату объектного модуля, однозначным согла-
шениям о передаче аргументов и единым схемам организации памяти на этапе
выполнения.
Динамический (на этапе выполнения) вызов исполняемых модулей и дина-
мическое подключение библиотек (DLL-файлов) для операционной систе-
мы Windows.
В качестве основных информационных связей можно выделить следующие:
ii общие области памяти и общие программно-аппаратные ресурсы процессора
для связи модулей;
унифицированная передача аргументов при
вызове модуля (эту унификацию
можно представлять двояко: на уровне пользователя и на уровне конкретного
компилятора);
унифицированная передача аргументов при
возвращении управления из мо-
дуля.
Чуть позже мы подробно рассмотрим процессы, происходящие при передаче
аргументов. Сейчас в качестве некоторого итога приведенных ранее общих рас-
суждений перечислим средства языка ассемблера по осуществлению
ной декомпозиции программы:
Ii макросредства;
процедуры;
средства компилятора ассемблера в форме директив организации оперативной
памяти и ее сегментации.
Макросредства подробно рассмотрены в главе 14. Предварительное обсужде-
ние процедур проведено при обсуждении команд передачи управления в главе 10.
Но процедуры — это не просто механизм тривиальной передачи управления из
одной точки программы в другую. В частности, этот механизм тесно связан со сред-
ствами компилятора, поддерживающими организацию памяти и сегментацию.
Поэтому дальнейшее обсуждение будет посвящено более глубокому изучению
функциональной декомпозиции программ с использованием процедур и связан-
ных с ними средств компилятора.
Do'stlaringiz bilan baham: 
