![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Коммуникационно- прочный модуль.⇐ ПредыдущаяСтр 20 из 20
Это процедурно прочный модуль, в котором все функции модуля связаны по данным. Те же проблемы, что и у процедурно – прочного модуля, но они менее острые, т.к. связь по данным в одной функции ускоряет связь предложений этой функции и их разрыв менее вероятен, а иногда невозможен. 6. Информационная прочность – модуль выполняет несколько функций над одной и той же строкой данных, но каждая функция представляется отдельным входом в модуль. 7. Функциональная прочность – это когда модуль выполняет одну функцию – это то, к чему следует стремиться при проектировании модульной структуры ПО. Информационно - прочные модули следует рассматривать как физическое соединение нескольких функционально – прочных модулей. Модуль может соответствовать описанию нескольких типов прочности. В этом случае принято его относить к высшему типу прочности, определению которой он удовлетворяет. 28. Сцепление модулей Сцепление модулей является мерой взаимозависимости модулей по данным и определяется как способом передачи данных между модулями, так и свойствами передаваемых данных. Для достижения минимальной сложности программного комплекса необходимо добиться такого сопряжения между модулями, чтобы все данные чередовались между ними в форме явных и простых параметров. Виды сцеплений охарактеризуем в порядке уменьшения сцепления. 1. Сцепление по содержимому — модуль ссылается на данные (содержимое) другого модуля. Большинство языков программирования высокого уровня делает такое сцепление практически невозможным. 2. Сцепление по общей области — модули ссылаются на одну и ту же глобальную структуру данных. При этом основная проблема та, что имена глобальных переменных связывают модули на этапе их кодирования (программирования), а, следовательно, использование таких модулей в других программах или других контекстах затруднено или невозможно вообще. И кроме того, любые изменения в структуре глобальных данных влекут проверку (тестирование) всех сцепленных по общей области модулей. 3. Сцепление по управлению — один модуль управляет функционированием другого. При этом в вызываемый модуль передается значение управляющей переменной. Предполагается, что вызывающий модуль “знает” логику работы вызываемого, что уменьшает их независимость. 4. Сцепление по формату — модули ссылаются на одну и ту же структуру данных. Если модуль А вызывает модуль В и передает ему запись анкетных данных служащего и при этом как А так и В чувствительны к изменению структуры или формата записи, то А и В сцеплены по формату. Такого сцепления, по возможности, следует избегать, поскольку оно создает ненужные связи между модулями. 5. Сцепление по данным — передаваемые параметры — простые (неструктурированные) данные. Сцепление модулей может удовлетворять определению нескольких типов сцепления. В этом случае принято относить тип сцепления к самому жесткому типу, т.е. к меньшему по номеру из рассмотренных типов сцеплений. При разработке модульной структуры ПО следует стремиться к усилению связей в модуле и ослаблению их взаимодействия. При этом получение идеальных по прочности и сцеплению модулей не должно быть самоцелью. Нужно понимать, какие проблемы создают неидеальные модули и не забывать их задокументировать. В литературе /1/ предлагается для оценки приемлемости программного модуля использовать следующие характеристики: - размер модуля; - прочность модуля; - сцепление с другими модулями; - рутинность модуля (независимость от предыстории обращений к нему). Размер модуля измеряется числом содержащихся в нем программных операторов или команд. Рекомендуется создавать программные модули размером от нескольких десятков до нескольких сотен операторов. Прочность и сцепление как основополагающие принципы модульного программирования пояснены выше. Рутинность интуитивно понятна и означает, что в модуле не должно быть команд, которые изменяются в зависимости от обрабатываемых данных. Вывод: Подытожим обсуждение модульного программирования перечислением принципов Хольта: 1.Сложность взаимодействия модуля с другими модулями должна быть меньше сложности его внутренней структуры. 2.Хороший модуль снаружи проще, чем изнутри. 3.Хороший модуль проще использовать, чем построить.
|