В основе того или иного языка программирования лежит некая руководящая идея, вызванная потребностями или, чаще всего, кризисом в области программирования и создания программного обеспечения, которая оказывает существенное влияние на стиль программирования и помогает преодолеть указанный кризис [9]. Рассмотрим вкратце историю появления и развития основных стилей программирования и процедурных алгоритмических языков.
ВВЕДЕНИЕ 3
1. ЦЕЛЬ МОДУЛЬНОГО ПРОГРАММИРОВАНИЯ 6
2. ОСНОВНЫЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО МОДУЛЯ 7
3. ПРОЕКТИРОВАНИЕ МОДУЛЯ 11
3.1. ФУНКЦИОНАЛЬНАЯ ДЕКОМПОЗИЦИЯ 12
3.2. МИНИМИЗАЦИИ КОЛИЧЕСТВА ПЕРЕДАВАЕМЫХ ПАРАМЕТРОВ 12
3.3. МИНИМИЗАЦИИ КОЛИЧЕСТВА НЕОБХОДИМЫХ ВЫЗОВОВ 13
4. МЕТОДЫ РАЗРАБОТКИ СТРУКТУРЫ МОДУЛЬНОЙ ПРОГРАММЫ 16
4.1. МЕТОД ВОСХОДЯЩЕЙ РАЗРАБОТКИ 16
4.2. МЕТОД НИСХОДЯЩЕЙ РАЗРАБОТКИ 18
4.3. КОНСТРУКТИВНЫЙ И АРХИТЕКТУРНЫЙ ПОДХОДЫ 19
4.4. ДРУГИЕ МЕТОДЫ РАЗРАБОТКИ СТРУКТУРЫ МОДУЛЬНЫХ ПРОГРАММ И ИХ ОБЩАЯ КЛАССИФИКАЦИЯ 22
Концепция модульной структуры образовательной программы и выделение новых профилей подготовки.
5. КОНТРОЛЬ СТРУКТУРЫ МОДУЛЬНОЙ ПРОГРАММЫ 25
ЗАКЛЮЧЕНИЕ 26
СПИСОК ЛИТЕРАТУРЫ: 27
Работа состоит из 1 файл
4.2. Метод нисходящей разработки
Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева.
Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке.
При этом первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при «естественном» состоянии информационной среды, при котором начинает выполняться эта программа. При этом те модули, к которым может обращаться головной, заменяются их имитаторами (так называемыми заглушками).
Каждый имитатор модуля представляется весьма простым программным фрагментом, который, в основном, сигнализирует о самом факте обращения к имитируемому модулю, производит необходимую для правильной работы программы обработку значений его входных параметров (иногда с их распечаткой) и выдает, если это необходимо, заранее запасенный подходящий результат. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются.
Для этого имитатор выбранного для тестирования модуля заменяется самим этим модулем и, кроме того, добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при «естественных» состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы.
Архитектура ПО. Введение
Таким образом, большой объем «отладочного» программирования при восходящем тестировании заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для того, чтобы подыгрывать процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Некоторым недостатком нисходящей разработки, приводящим к определенным затруднениям при ее применении, является необходимость абстрагироваться от базовых возможностей используемого языка программирования, выдумывая абстрактные операции, которые позже нужно будет реализовать с помощью выделенных в программе модулей. Однако способность к таким абстракциям представляется необходимым условием разработки больших программных средств, поэтому ее нужно развивать.
4.3. Конструктивный и архитектурный подходы
Особенностью рассмотренных методов восходящей и нисходящей разработок является требование, чтобы модульная структура программы была разработана до начала программирования (кодирования) модулей. Разработка модульной структуры программы и ее кодирование производятся на разных этапах разработки программного средства (ПС): первая завершает этап конструирования ПС, а второе — открывает этап кодирования. Однако эти методы вызывают ряд возражений: представляется сомнительным, чтобы до программирования модулей можно было разработать структуру программы достаточно точно и содержательно. На самом деле это делать не обязательно. Ниже описываются конструктивный и архитектурный подходы к разработке программ, в которых модульная структура формируется в процессе программирования (кодирования) модулей.
Конструктивный подход к разработке программы представляет собой модификацию нисходящей разработки, при которой модульная древовидная структура программы формируется в процессе программирования модулей. Разработка программы при конструктивном подходе начинается с программирования головного модуля, исходя из спецификации программы в целом.
При этом спецификация программы принимается в качестве спецификации ее головного модуля, который полностью берет на себя ответственность за выполнение функций программы. В процессе программирования головного модуля, в случае, если эта программа достаточно большая, выделяются подзадачи (внутренние функции), в терминах которых программируется головной модуль.
Это означает, что для каждой выделяемой подзадачи (функции) создается спецификация реализующего ее фрагмента программы, который в дальнейшем может быть представлен некоторым поддеревом модулей. Важно заметить, что здесь также ответственность за выполнение выделенной функции несет головной (может быть, и единственный) модуль этого поддерева, так что спецификация выделенной функции является одновременно и спецификацией головного модуля этого поддерева. В головном модуле программы для обращения к выделенной функции строится обращение к головному модулю указанного поддерева в соответствии с созданной его спецификацией. Таким образом, на первом шаге разработки программы (при программировании ее головного модуля) формируется верхняя начальная часть дерева, например, такая, которая показана на рис. 1.
Аналогичные действия производятся при программировании любого другого модуля, который выбирается из текущего состояния дерева программы из числа специфицированных, но пока еще не запрограммированных модулей. В результате этого производится очередное деформирование дерева программы.
Архитектурный подход к разработке программы представляет собой модификацию восходящей разработки, при которой модульная структура программы формируется в процессе программирования модуля. Но при этом ставится существенно другая цель разработки: повышение уровня используемого языка программирования, а не разработка конкретной программы.
Это означает, что для заданной предметной области выделяются типичные функции, каждая из которых может использоваться при решении разных задач в этой области, и специфицируются, а затем и программируются отдельные программные модули, выполняющие эти функции. Так как процесс выделения таких функций связан с накоплением и обобщением опыта решения задач в заданной предметной области, то обычно сначала выделяются и реализуются отдельными модулями более простые функции, а затем постепенно появляются модули, использующие ранее выделенные функции.
Такой набор модулей создается в расчете на то, что при разработке той или иной программы заданной предметной области в рамках конструктивного подхода могут оказаться приемлемыми некоторые из этих модулей. Это позволяет существенно сократить трудозатраты на разработку конкретной программы путем подключения к ней заранее заготовленных и проверенных на практике модульных структур нижнего уровня. Так как такие структуры могут многократно использоваться в разных конкретных программах, то архитектурный подход может рассматриваться как путь борьбы с дублированием в программировании. В связи с этим программные модули, создаваемые в рамках архитектурного подхода, обычно параметризуются для того, чтобы усилить применимость таких модулей путем настройки их на параметры.
4.4. Другие методы разработки структуры модульных программ и их общая классификация
В классическом методе нисходящей разработки рекомендуется сначала все модули разрабатываемой программы запрограммировать, а уж затем начинать нисходящее их тестирование. Однако такой порядок разработки не представляется достаточно обоснованным: тестирование и отладка модулей может привести к изменению спецификации подчиненных модулей и даже к изменению самой модульной структуры программы, так что в этом случае программирование некоторых модулей может оказаться бесполезно проделанной работой. Более рациональным является другой порядок разработки программы, известный в литературе как метод нисходящей реализации. В этом методе каждый запрограммированный модуль начинают сразу же тестировать до перехода к программированию другого модуля.
Все эти методы имеют еще различные разновидности в зависимости от того, в какой последовательности обходятся узлы (модули) древовидной структуры программы в процессе ее разработки. Это можно делать, например, по слоям (разрабатывая все модули одного уровня, прежде чем переходить к следующему уровню).
При нисходящей разработке дерево можно обходить также в лексикографическом порядке (сверху вниз, слева направо). Возможны и другие варианты обхода дерева. Так, при конструктивной реализации для обхода дерева программы целесообразно следовать идеям Фуксмана, которые он использовал в предложенном им методе вертикального слоения. Сущность такого обхода заключается в следующем.
В рамках конструктивного подхода сначала реализуются только те модули, которые необходимы для самого простейшего варианта программы, которая может нормально выполняться только для весьма ограниченного множества наборов входных данных, но для таких данных эта задача будет решаться до конца. Вместо других модулей, на которые в такой программе имеются ссылки, в эту программу вставляются лишь их имитаторы, обеспечивающие, в основном, сигнализацию о выходе за пределы этого частного случая.
Затем к этой программе добавляются реализации некоторых других модулей (в частности, вместо некоторых из имеющихся имитаторов), обеспечивающих нормальное выполнение для некоторых других наборов входных данных. И этот процесс продолжается поэтапно до полной реализации требуемой программы.
Таким образом, обход дерева программы производится с целью кратчайшим путем реализовать тот или иной вариант (сначала самый простейший) нормально действующей программы. В связи с этим такая разновидность конструктивной реализации получила название метода целенаправленной конструктивной реализации. Достоинством этого метода является то, что уже на достаточно ранней стадии создается работающий вариант разрабатываемой программы. Психологически это играет роль допинга, резко повышающего эффективность разработчика. Поэтому этот метод является весьма привлекательным.
Подводя итог сказанному, на рис. 2 представлена общая классификация рассмотренных методов разработки структуры программы.
5. Контроль структуры модульной программы
В завершении процесса модульного программирования следует этап контроля структуры программы. Для этого можно использовать три метода:
- статический контроль
- смежный контроль
- сквозной контроль
Статический контроль состоит в оценке структуры программы, насколько хорошо программа разбита на модули с учетом значений рассмотренных выше основных характеристик модуля.
Смежный контроль сверху — это контроль со стороны разработчиков архитектуры и внешнего описания ПС. Смежный контроль снизу — это контроль спецификации модулей со стороны разработчиков этих модулей.
Сквозной контроль — это мысленное прокручивание (проверка) структуры программы при выполнении заранее разработанных тестов. Является видом динамического контроля так же, как и ручная имитация функциональной спецификации или архитектуры ПС.
Следует заметить, что указанный контроль структуры программы производится при классическом подходе. При конструктивном и архитектурном подходах контроль структуры программы осуществляется в процессе программирования (кодирования) модулей в подходящие моменты времени.
Заключение
Подводя итог, хочу сказать, что концепция модульного программирования полностью удовлетворяет поставленным целям. Несмотря на «эру» объектно-ориентированного программирования, эта технология активно используется и по сей день. Средства создания модулей заложены практически во всех языках высокого уровня. Модули применяются также и в низкоуровневом программировании, где понятность кода особенно актуальна.
Использование программных модулей значительно упрощает отладку кода, дает значительные преимущества при локализации ошибок, позволяет быстро и безболезненно внести необходимые изменения в нужные части программы. Также, при создании крупных проектов, данная технология позволяет задействовать большое количество специалистов, которые в свою очередь разобьются на более мелкие группы и будут решать конкретную узко поставленную задачу, доводя ее до «совершенства». При этом структурированность и иерархичность данного процесса является большим плюсом, т.к. скорость разработки приложения повышается в несколько раз. Взаимодействие между различными группами специалистов сводиться к минимуму, тем самым снимая возможные недопонимания.
Еще одним несомненным преимуществом является борьба с дублированием в программировании, что тоже значительно повышает скорость разработки.
Список литературы:
Источник: www.freepapers.ru
Большая Энциклопедия Нефти и Газа
При модульной структуре программы в процедуре имеется доступ только к аргументу. Поэтому практически невозможно изменить значение внешней ( глобальной) переменной с помощью присваивания некоторого значения формальному параметру. [4]
Язык ПЛ / М допускает использование модульной структуры программы , позволяющей автономно писать и транслировать отдельные модули и объединять их в одну программу на этапе редактирования. Это позволяет осуществлять по возможности большую изоляцию модулей друг от друга, но вместе с тем делает необходимой реализацию связи между ними. С этой точки зрения необходимо избегать использования глобальных переменных, что обеспечит большую изолированность модулей. Одним из способов, реализующих связь между отдельными модулями, является использование внешних программ вместо внутренних. [5]
Основная цель методологии состоит в разработке такой модульной структуры программы , которая отображала бы структуру реализуемой проблемы. В основе методологии лежит предложенное Джэксоном понятие инвариантных контуров обратных связей программы. [6]
Программная реализация модели может быть представлена в виде модульной структуры программы , структурной модели программы ( с детальной структурой каждого модуля) и, наконец, в виде текста программы на каком-либо языке программирования. [7]
Подробно рассмотрен принцип программирования, в основу которого положена модульная структура программ . Приведен ряд рекомендаций по использование системы с ВН. [8]
Основой для создания типовых программных решений модуля оперативного управления является модульная структура программ . Под модулем понимаются отдельные, способные самостоятельно функционировать части программы, которые выполняют законченную функцию и могут быть объединены в рабочую программу. [9]
Ниже рассматривается пример реализации некоторых функций управляющей программы для простейшей микропроцессорной системы, причем модульная структура программы позволяет легко изменять состав функций, а также адаптировать сами функции к различным внешним устройствам. Эти мониторы решают задачи управления терминалами, распределения оперативной памяти, сопряжения с внешними устройствами, поддержания возможности работы с файлами на гибком магнитном диске и, наконец, задачи отладки, к которым можно отнести рассматриваемый ниже пример. [10]
Программа может быть использована для решения широкого круга гидрогеологических задач, связанных с проблемами водоснабжения, осушения месторождений полезных ископаемых, истощения и искусственного восполнения эксплуатационных запасов подземных вод. К программе прилагается подробное и весьма качественное описание теоретических основ моделирования трехмерной фильтрации подземных вод в конечно-разностной постановке, физического и математического подходов к созданию модульных структур программы . Даны практические рекомендации по работе с программой, проиллюстрированные типовым тестом. [11]
Принципиальным отличием языка PDL от естественного языка является наличие внешнего синтаксиса, связанного со структурами управления, данных и систем, который включает небольшое число ключевых слов и позволяет оформлять текст программы в виде таблиц, удобных для печати. Внешний синтаксис определяет порядок следования и выполнения операций, организацию данных и доступа к ним и модульную структуру программы . Внутренний синтаксис имеет отношение к типам данных и операциям и выражается либо на естественном языке, либо на специализированных языках ( например, на языке математики), соответствующих рассматриваемой проблеме. [12]
Надежность ПО существенно зависит от установившейся тенденции достижения максимального быстродействия аппаратуры и минимальной стоимости. В силу противоречий между эффективностью и надежностью показатели надежности часто отбрасываются ради достижения эффективности. Например, зачастую пренебрегают защитными мероприятиями по той причине, что они снижают скорость выполнения программы; избегают применения модульной структуры программ из-за некоторого увеличения времени выполнения за счет передач параметров; ограничиваются контрольные функции компиляторов из-за дополнительного расхода времени на создание программ и делаются попытки использовать различные ухищрения программирования с целью сокращения времени работы программ. [13]
Описаны функции типового модуля, его назначение, параметры и область применения. Предложена структура входной и выходной информации, приведены формы входных и выходных табуляграмм, а также описаны алгоритмы решаемых задач и модульная структура программ . [14]
В основе программного обеспечения лежит модульный принцип. Преимущества модульного программирования заключаются в том, что составление программы сводится к синтезу ее из модулей, причем последние можно считать элементами проблемно-ориентированного языка. Отладка программ упрощается тем, что в момент объединения модулей каждый из них уже отлажен. Благодаря модульной структуре программу можно легко изменить путем создания новых модулей, или преобразованием некоторых из уже имеющихся, или перестановкой модулей, определяющих процесс обработки данных. Модульная структура программ облегчает организацию работы больших коллективов программистов и эксплуатацию программ. [15]
Источник: www.ngpedia.ru
Структурное и модульное программирование
Структурное программирование иногда называют еще «программированием без go to». Рекомендуется избегать употребления оператора перехода всюду, где это возможно, но чтобы это не приводило к слишком громоздким структурированным программам.
goto (перейти на) — оператор безусловного перехода (перехода к определённой точке программы, обозначенной номером строки либо меткой) в некоторых языках программирования. В некоторых языках оператор безусловного перехода может иметь другое имя (например, jmp в языках ассемблера).
Фундаментом структурного программирования является теорема о структурировании. Эта теорема устанавливает, что, как бы сложна ни была задача, схема соответствующей программы всегда может быть представлена с использованием ограниченного числа элементарных управляющих структур.
Базовыми элементарными структурами являются структуры: следование, ветвление и повторение (цикл), любой алгоритм может быть реализован в виде композиции этих трех конструкций.
Достоинства структурного программирования:
- повышается надежность программ (благодаря хорошему структурированию при проектировании, программа легко поддается тестированию и не создает проблем при отладке);
- повышается эффективность программ (структурирование программы позволяет легко находить и корректировать ошибки, а отдельные подпрограммы можно переделывать (модифицировать) независимо от других);
- уменьшается время и стоимость программной разработки;
- улучшается читабельность программ.
Модульное программирование
Модульное программирование является естественным следствием проектирования сверху вниз и заключается в том, что программа разбивается на части – модули, разрабатываемые по отдельности.
В программировании под модулем понимается отдельная подпрограмма, а подпрограммы часто называются процедурами или процедурами-функциями. Поэтому модульное программирование еще называется процедурным.
Модуль должен обладать следующими свойствами:
- один вход и один выход – на входе программный модуль получает определенный набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, т.е. реализуется стандартный принцип IPO (Input — Process — Output — вход-процесс-выход);
- функциональная завершенность – модуль выполняет перечень регламентированных операций для реализации каждой отдельной функции в полном составе, достаточных для завершения начатой обработки;
- логическая независимость – результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;
- слабые информационные связи с другими программными модулями – обмен информацией между модулями должен быть по возможности минимизирован;
- обозримый по размеру и сложности программный код.
Модули содержат определение доступных для обработки данных, операции обработки данных, схемы взаимосвязи с другими модулями.
Каждый модуль состоит из спецификации и тела. Спецификации определяют правила использования модуля, а тело – способ реализации процесса обработки.
Принципы модульного программирования программных продуктов во многом сходны с принципами нисходящего проектирования: сначала определяются состав и подчиненность функций, а затем — набор программных модулей, реализующих эти функции.
Источник: it-black.ru