Модульное программирование. Характеристики модуля: размер, связность, сцепление, рутинность

3. Модульное программирование. Характеристики модуля: размер, связность, сцепление, рутинность 

 

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

Модуль – автономно компилируемая программная единица

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

Цели модульного программирования:

- упрощение разработки и реализации программ

- улучшение «читаемости» программ

- упрощение настройки и модификации программ

- упрощение работы с данными, имеющими сложную структуру

- избежание чрезмерной детализации алгоритмов

- более выгодное размещение программ в памяти ЭВМ

Модуль может получать и возвращать данные через общие  области памяти или параметры

Первоначально к модулям (еще понимаемым как подпрограммы) предъявлялись следующие требования: отдельная компиляция, одна точка  входа, одна точка выхода, соответствие принципу вертикального управления, возможность вызова других модулей, небольшой размер (до 50-60 операторов), независимость от истории вызовов, выполнение одной функции

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

Со временем, когда основные требования структурного подхода стали  поддерживаться ЯП, под модулем стали понимать отдельно компилируемую библиотеку ресурсов, и требование независимости модулей стало основным

Практика показала, что  чем выше степень независимости  модулей, тем:

- легче разобраться в отдельном модуле и всей программе и, соответственно, тестировать, отлаживать и модифицировать ее

- меньше вероятность появления новых ошибок при исправлении старых или внесении изменений в программу

- проще организовать разработку ПО группой программистов и легче его сопровождать

Не всякий программный  модуль способствует упрощению программы. Для оценки приемлемости выделенного  модуля используются некоторые критерии

Хольт предложил следующие общие критерии:

- хороший модуль снаружи проще, чем внутри

- хороший модуль проще использовать, чем построить

Майерс предложил использовать для оценки приемлемости программного модуля более конструктивные его характеристики – размер, прочность, сцепление с другими модулями, рутинность

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

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

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

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

- всегда следует использовать рутинный модуль, если это не приводит к не рекомендуемым сцеплениям модулей

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

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

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

Степень независимости модулей (как подпрограмм, так и библиотек) оценивают сцеплением и связностью

Сцепление, или связанность, модулей – мера их взаимозависимости

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

Типы сцепления  модулей:

- по данным: модули взаимодействуют через передачу параметров; каждый параметр – элементарный информационный объект. Это наиболее предпочтительный тип связанности модулей

- по образцу: один модуль посылает другому составной информационный объект (запись, структура). Это один из допустимых типов связанности модулей

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

- по общей области данных: модули ссылаются на одну и туже область глобальных данных. Это нежелательный тип сцепления модулей, так как, во-первых, ошибка в модуле, использующем глобальную область, может неожиданно проявиться в любом другом модуле; во-вторых, такие программы сложны для понимания, так как программисту трудно определить, какие именно данные используются конкретным модулем

- по содержимому: один из модулей ссылается внутрь другого. Это недопустимый тип сцепления, противоречащий принципу модульности, то есть представления модуля в виде «черного ящика»

Связность модуля – мера прочности соединения функциональных и информационных объектов внутри него. Это степень взаимосвязи элементов и направленности модуля на решение определенной задачи. Чем выше связность модуля, тем меньше «ручек управления» на модуле и тем он проще. При проектировании модулей нужно стремиться к высокой связности, так как чем выше связность, тем лучше спроектирован модуль. Размещение сильно связанных элементов в одном модуле уменьшает межмодульные связи и, соответственно, взаимовлияние модулей. В то же время помещение сильно связанных элементов в разные модули не только усиливает межмодульные связи, но и усложняет понимание их взаимодействия. Объединение слабо связанных элементов также уменьшает технологичность модулей, так как такими элементами сложнее мысленно манипулировать

Виды связности  модулей в порядке убывания уровня:

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

- последовательная: объекты модуля выполняют подзадачи, для которых выходные данные одной из подзадач являются входными для другой (открыть файл, прочитать запись, закрыть файл)

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

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

- временная: объекты модуля привязаны к конкретному промежутку времени (например, модуль, осуществляющий инициализацию процесса). Элементы модуля связаны только тем, что они должны выполняться в определенное время

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

- случайная (по совпадению): связь между элементами модуля мала или отсутствует. Такой модуль имеет самые низкие показатели технологичности

В программных системах должны присутствовать модули, имеющие следующие  три меры связности: функциональная, последовательная и информационная, так как другие типы связности  крайне нежелательны и осложняют  понимание и сопровождение системы

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

 

 

 

 

 

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

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

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

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