ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.02.2024
Просмотров: 293
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Модуль имеет связность по совпадению, если его операторы объединяются произвольным образом.
Модули верхних уровней иерархической структуры программы должны иметь функциональную или последовательную связность. Для модулей обслуживания предпочтительнее коммуникативная связность. Если модули имеют процедурную, временную, логическую связность или связность по совпадению, это свидетельствует о недостаточно продуманном их проектировании. Необходимо добиваться функциональной связности проектируемых модулей.
Сцепление модулей
Сцепление модулей – это мера относительной независимости модулей. Сцепление влияет на сохранность модулей при модификациях и на понятность их исходных текстов. Слабое сцепление определяет высокий уровень независимости модулей. Независимые модули могут быть модифицированы без переделки других модулей.
Два модуля являются полностью независимыми, если в каждом из них не используется никакая информация о другом модуле. Чем больше информации о другом модуле в них используется, тем менее они независимы и тем более сцеплены. Чем очевиднее взаимодействие двух связных друг с другом модулей, тем проще определить необходимую корректировку одного модуля, зависящую от изменений, производимых в другом.
В таблице 2.7 содержатся типы сцепления модулей и соответствующие им степени сцепления.
Таблица 2.7 - Типы и степени сцепления модулей
| Сцепление | Степень сцепления |
| Независимое | 0 |
| По данным | 1 (слабое сцепление) |
| По образцу | 3 |
| По общей области | 4 |
| По управлению | 5 |
| По внешним ссылкам | 7 |
| По кодам | 9 (сильное сцепление) |
Независимое сцепление возможно только в том случае, если модули не вызывают друг друга и не обрабатывают одну и ту же информацию.
Модули сцеплены по данным, если они имеют общие простые элементы данных, передаваемые от одного модуля к другому как параметры. В вызывающем модуле определены только имя вызываемого модуля, типы и значения переменных, передаваемых как параметры. Вызываемый модуль может не содержать никакой информации о вызывающем. В этом случае изменения в структуре данных в одном из модулей не влияют на другой модуль. Например, в вызывающем модуле определена такая структура данных, как массив. В вызываемый модуль передается в качестве параметра элемент массива. При этом изменения в структуре данных вызывающего модуля не повлияют на вызываемый модуль.
Модули со сцеплением по данным не имеют общей области данных (общих глобальных переменных).
Если модули сцеплены по данным, то по изменениям, производимым в объявленных параметрах, легко можно определить модули, на которые эти изменения повлияют. Модули сцеплены по образцу, если в качестве параметров используются структуры данных (например, в качестве параметра передается массив). Недостаток такого сцепления заключается в том, что в обоих модулях должна содержаться информация о внутренней структуре данных. Если модифицируется структура данных в одном из модулей, то необходимо корректировать и другой модуль. Следовательно, увеличивается вероятность появления ошибок при разработке и сопровождении ПС.
Модули сцеплены по общей области, если они имеют доступ к общей области памяти (например используют общие глобальные данные). В этом случае возможностей для появления ошибок при модификации структуры данных или одного из модулей намного больше, поскольку труднее определить модули, нуждающиеся в корректировке.
Модули сцеплены по управлению, если какой-либо из них управляет решениями внутри другого с помощью передачи флагов, переключателей или кодов, предназначенных для выполнения функций управления. Таким образом, в одном из модулей содержится информация о внутренних функциях другого. Например, если модуль имеет логическую связность и при его вызове используется переключатель требующейся функции, то вызываемый и вызывающий модули сцеплены по управлению.
Модули сцеплены по внешним ссылкам, если у одного из них есть доступ к данным другого модуля через внешнюю точку входа. Таким путем осуществляется неявное влияние на функционирование другого модуля. Сцепление этого типа возникает, например, тогда, когда внутренние процедуры одного модуля оперируют с глобальными переменными другого модуля.
Модули сцеплены по кодам, если коды их команд объединены друг с другом. Например, для одного из модулей доступны внутренние области другого модуля без обращения к его точкам входа, то есть модули используют общий участок памяти с командами. Это сцепление возникает, когда модули проектируются как отдельные подпрограммы, путь через которые начинается в различных точках входа, но приводит к общему сегменту кодов. Например, некоторый модуль реализует функции синуса и косинуса c учетом того, что
Cos(x) = Sin(π/2 – x).
Путь через точки входа Sin и Cos ведет к общему участку команд модуля. Следует иметь в виду, что если модули косвенно обращаются друг к другу (например, связь между ними осуществляется через промежуточные модули), то между ними также существует сцепление.
Резюме
Различают независимое сцепление модулей, сцепление по данным, по образцу, по общей области, по управлению, по внешним ссылкам, по кодам. Сцепление модулей зависит от спроектированной структуры данных и способов взаимодействия между модулями. Необходимо использовать простые параметры и не применять общих областей памяти.
2.3 Модульная структура программных продуктов
Модульная структура программы представляет собой древо видную структуру, в узлах которой размещаются программные модули, а направленные дуги показывают статическую подчиненность модулей. Если в тексте модуля имеется ссылка на другой модуль, то их на структурной схеме соединяет дуга, которая исходит из первого и входит во второй модуль. Другими слова ми, каждый модуль может обращаться к подчиненным ему модулям. При этом модульная структура программной системы, кроме структурной схемы, должна включать в себя еще и совокупность спецификации модулей, образующих эту систему.
Функция верхнего уровня обеспечивается главным модулем; он управляет выполнением нижестоящих функций, которым соответствуют подчиненные модули.
При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее:
-
модуль вызывается на выполнение вышестоящим по иерархии модулем и, закончив работу, возвращает ему управление; -
принятие основных решений в алгоритме выносится на максимально высокий по иерархии уровень; -
если в разных местах алгоритма используется одна и та же функция, то она оформляется в отдельный модуль, который будет вызываться по мере необходимости.
Состав, назначение и характер использования программных модулей в значительной степени определяются инструментальными средствами.
Например, при разработке СУБД используются следующие программные модули:
-
экранные формы ввода и/или редактирования информации базы данных; -
отчеты; -
макросы; -
стандартные средства для обработки информации; -
меню для выбора функции обработки и др.
Методы разработки при модульном программировании
Спецификация программного модуля состоит из функциональной спецификации модуля, описывающей семантику функций, выполняемых этим модулем по каждому из его входов, и синтаксической спецификации его входов, позволяющей по строить на используемом языке программирования синтаксически правильное обращение к нему. Функциональная спецификация модуля определяется теми же принципами, что и функциональная спецификация программной системы.
Существуют разные методы разработки модульной структуры программы, в зависимости от которых определяется порядок программирования и отладки модулей, указанных в этой структуре. Обычно а литературе обсуждаются два метода: метод восходящей разработки и метод нисходящей разработки.
Метод восходящей разработки
Сначала строится древовидная модульная структура программы. Затем поочередно проектируются и разрабатываются модули программы, начиная с модулей самого нижнего уровня, затем предыдущего уровни и т. д. То есть модули реализуются в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же что каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные моду ли, а при тестировании использует уже отлаженные модули. Недостатки метода восходящей разработки заключаются в следующем:
-
на нижних уровнях модульной структуры спецификации могут быть еще определены не полностью, что может привести к полной переработке этих модулей после уточнения спецификаций на верхнем уровне; -
для восходящего тестирования всех модулей кроме головного, который является модулем самого верхнего уровня, приходится создавать вызывающие программы, что приводит к созданию большого количества отладочного материала, но не гарантирует, что результаты тестирования верны; -
головной модуль проектируется и реализуется в последнюю очередь, что не дает продемонстрировать его заказчику для уточнения спецификаций.
Метод нисходящей разработки
Как и в предыдущем метоле, сначала строится модульная структура программы в виде дерева. Затем проектируются и реализуются модули программы, начиная с модуля самого верх него уровня — головного, далее разрабатываются модули уровнем ниже и т. д. При этом переход к программированию какого-либо модуля осуществляется только в том случае, если уже запрограммирован модуль, который к нему обращается. Затем производится их поочередное тестирование и отладка в таком же нисходящем порядке. При таком порядке разработки про граммы вся необходимая глобальная информация формируется своевременно, т. с. ликвидируется весьма неприятный источник просчетов при программировании модулей. Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу, при этом все модули, к которым может обращаться головной, заменяются их имитаторами (так называемыми «заглушками» )- Каждый имитатор модуля является простым программным фрагментом, реализующим сам факт обращения к данному модулю с необходимой для правильной работы программы обработкой значений его входных параметров и с выдачей, если это необходимо, подходящего результата. Далее производится тестирование следующих по уровню модулей. Для этого имитатор выбранного для тестирования модуля заменяется самим модулем, и добавляются имитаторы модулей, к которым может обращаться тестируемый модуль. При таком подходе каждый модуль будет тестироваться в«естественных» состояниях ин формационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем «отладочного» программирования за меняется программированием достаточно простых имитаторов используемых в программе модулей.
Недостатком нисходящего подхода к программированию является необходимость абстрагироваться от реальных возможностей выбранного языка программирования и придумывать абстрактные операции, которые позже будут реализованы с помощью модулей. Однако способность к таким абстракциям является необходимым условием разработки больших программных средств.
Рассмотренные выше методы (нисходящей и восходящей разработок), являющиеся классическими, требуют, чтобы мо дульная древовидная структура была готова до начала программирования модулей. Как правило, точно и содержательно разработать структуру программы до начала программирования не возможно. При конструктивном и архитектурном подходах к разработке модульная структур формируется в процессе реализации модулей.