Проектирование модулей

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

Связность модуля

Связность модуля — это мера независимости его частей. Чем более зависимы части, тем выше связность.

Считается, что чем выше связность модуля, тем лучше результат проектирования.

При определении силы связности используется понятие типа связности:

Примечание: наименования и оценки у различных авторов отличаются, но не принципиально.

Описание типов связности:

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

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

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

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

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

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

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

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

Сцепление модулей

Сцепление модулей — это мера относительной независимости модулей. Эта характеристика является до некоторой степени обратной связности модулей.

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

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

Часто используют следующую меру сцепления:

Примечание: наименования и оценки у различных авторов отличаются, но не принципиально.

Описание типов сцепления:

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

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

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

4. Модули сцеплены по общем области, если они используют одну и ту же глобальную переменную (структуру данных). Очевидно, что это усложняет процесс отладки и модификации программ. Если модифицируются неявно заданные параметры, то определить нуждающиеся в корректировке модули достаточно затруднительно. Использование сцепления по общей области требует разработки документации, наглядно специфицирующей использование модулями общих областей.

5. Модули имеют сцепление по управлению, если какой-либо из них управляет вычислительным процессом внутри другого с помощью передачи флагом или переключателей, т.е. один из модулей «знает» внутреннюю структуру другого. Передача флага не всегда означает сцепление по управлению. Флаг может носить характер переменной-статуса состояния некоторого объекта или процесса (например, признак достижения конца файла). Но если флаг является указателем на функцию, которую необходимо выполнить в вызываемом модуле, то это признак сцепления по управлению. Замечание: поэтому использование связи по управлению на соответствующей иллюстрации в пункте «Структурные карты Константайна» предполагает, что параметры «Запрос об аренде» и «Разрешение аренды» являются именно управляющими флагами, а не флагами состояния.

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

7.Модули сцеплены по кодам(или по содержимому), если один модуль может передавать управление внутренним областям другого без обращения к некоторым точкам входа. Такое сцепление часто возникают при программировании на языках низкого уровня при оптимизации кода по критерию размера и/или времени выполнения. Фактически такое сцепление мало чем отличается от «сплошной» программы.

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

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

FLOW-формы

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

Следует заметить, что FLOW-формы активно используются не только на уровне описания алгоритма решения задачи, но и на этапе спецификации некоторого делового процесса. Например, с помощью FLOW-форм можно детализировать терминальные действия в схемах DFD.

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

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

Символы FLOW-форм:

Наименование	Обозначение	Пояснение
Обработка
Следование		Объединение нескольких следующих друг за другом блоков обработки
Решение (ветвление)		Если условие X истинно, то выполняется A, иначе B
Цикл со счетчиком		Выполнять A i раз, i = 1,2, … n
Цикл «пока» с предусловием		Выполнять A пока истинно X
Цикл «пока» с постусловием		Выполнять A пока X не станет истинным
Выбор (расширенное решение)		Если X=1, то выполнять A, если X=2, то выполнять B, если X=3, то выполнять C. Если X не равно ни одному их трех перечисленных значений, то выполнять D. Количество вариантов может быть произвольным. Блок “else” может быть опущен.

Пример вложения структур:

Данный фрагмент специфицирует вычисление суммарного числа замаскированных элементов в некоторой группе из n объектов.