45. Сопряжение между модулями. Критерии оценки сопряжения. Виды сопряжения

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

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

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

Соединения между программными модулями также должны быть как можно проще.

Самые распространенные виды сопряжения описаны ниже.

Простое сопряжение посредством данных-параметров Два модуля сопряжены таким способом, если между ними передаются только элементарные типы данных, причем передаются через списки параметров. Этот вид сопряжения нормален и приемлем.

Простое сопряжение посредством объекта. Модуль сопряжен с объектом этим способом, если он создает экземпляр данного объекта. С этим видом сопряжения также все в порядке.

Сопряжение посредством объекта-параметра Два модуля сопряжены друг с другом объектом-

параметром, если Объект 1 требует, чтобы Объект 2 передал ему Объект 3. Этот вид сопряжения более сильный, чем тот вид, при котором Объект 1 требует от Объекта 2 только примитивных типов данных, потому что Объект 2 должен обладать информацией об Объекте 3.

Семантическое сопряжение Самый коварный тип сопряжения имеет место тогда, когда один модуль использует не какой-то синтаксический элемент другого модуля, а некоторые семантические знания о внутренней работе этого модуля. Некоторые примеры такого вида сопряжения описаны ниже.

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

Необходимо создавать модули, слабо зависящие от других модулей. Отношения

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

Объем связи характеризует число соединений между модулями. Чем их меньше, тем лучше, поскольку модуль, имеющий более компактный интерфейс, легче связать с другими модулями. Метод, принимаю- [Введите текст]

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

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

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

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

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

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

Чтобы третий модуль мог обратиться к модулю LookupVacationBenefitO, он должен

знать о существовании класса Employee. Он мог бы подделать объект employee, используя лишь два поля, но тогда он должен был бы знать внутренние детали работы метода LookupVacationBenefitO'. ему была бы необходима уверенность в том, что метод LookupVacationBenefitO использует только два этих поля. Такое решение было бы небрежным и безобразным. Второй вариант мог бы заключаться в таком изменении метода LookupVacationBenefitO, чтобы вместо объекта employee он принимал должность сотрудника и дату его приема на работу. В обоих случаях первоначальный модуль оказывается на самом деле гораздо менее гибким, чем казалось сначала.

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

Модульность проекта системы

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

68

«черный ящик»: вы знаете, что в него поступает и что из него выходит, но не знаете, что происходит внутри. Черный ящик имеет такой простой интерфейс и такую ясную функциональность, что для любых конкретных входных данных можно точно предсказать соответствующие выходные данные. Концепция модульности связана с сокрытием информации, инкапсуляцией и другими эвристическими принципами проектирования. Если для использования модуля нужно учитывать сразу несколько аспектов: механизм внутренней работы, изменения глобальных данных, неясную функциональность, — сила абстракции исчезает, и модуль перестает облегчать управление сложностью.

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

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

46. Эталоны для контроля работы ПО

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

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

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

Это сравнение с эталонным результатом можно делать по завершению работы ПО, а можно делать непрерывно (точнее квазинепрерывно). Учитывая периодичность работы ПО в составе систем управления, период проведения контроля целесообразно совместить с периодом работы ПО системы.

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

Таким образом, защита от ошибок должна строится на их как можно более раннем обнаружении. Для этого работу ПО надо постоянно контролировать. Слова «постоянно» для дискретных систем с ЦВМ означают

[Введите текст]