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

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

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

• чтобы уменьшить размеры модуля;

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

• чтобы избегать дублирования подзадачи, выполняемой более чем одним модулем;

• чтобы отделить собственно вычисления от управления (вызовы и принятия решения);

• чтобы обеспечить более широкую пригодность модулей для их использования в различных частях системы;

• чтобы упростить реализацию.

2) Принцип единства решения. Процесс любого решения состоит из двух частей: распознавания того, какое действие выбрать, и исполнения этого действия. Поскольку эти две составляющие решения различны, информационные объекты, используемые при распознавании и исполнении, также могут существенно различаться и, следовательно, могут быть недоступными в одном модуле. Такая ситуация получила название расщепления решения (decision split). Сильное расщепление решения (хотя иногда расщепления не удается избежать) обычно является симптомом плохой организации модулей. Исполнительная часть решения должна располагаться как можно ближе к распознавательной части, чтобы распознанной информации не пришлось долго “блуждать” для того, чтобы быть обработанной.

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

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

• Появляется возможность хранить тексты сообщений в отдельном файле, а не внутри кода модуля.

• Легче избежать дублирования сообщений.

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

4) Принцип отсутствия памяти. Когда вызванный модуль возвращает управление вызвавшему его модулю после выполнения своей функции, этот модуль “умирает”, оставляя после себя только результат. При повторном вызове он делает свою работу так, как будто бы он родился впервые. Модуль не помнит, что происходило в его предыдущих жизнях. Однако, существует тип модуля, который знает о своем прошлом благодаря так называемой памяти состояния. Память состояния (state memory) - это информационный объект внутри модуля, который продолжает существовать неизмененным между двумя вызовами модуля. Работа модуля с памятью состояния в общем случае непредсказуема, это означает, что, хотя модуль вызывался с одинаковыми фактическими параметрами, исполняться он может по-разному, и результаты его работы при разных вызовах могут быть различными. Сопровождение такого модуля резко усложняется.

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

6) Компромисс между ограниченностью и обобщенностью. Ограниченный модуль обладает, по крайней мере, одной из следующих характеристик:

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

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

• Он включает в себя условия о месте и способе его использования.

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

• Он выполняет нелепо обширную работу. Примером является модуль, формирующий расписание игр чемпионата по футболу, как по Грегорианскому, так и по Юлианскому календарю.

• Он имеет дело с слишком избыточными типами данных, их значениями и структурами. Например, использование числа типа REAL вместо INTEGER для того, чтобы следить за количеством болтов на складе, было бы чрезмерным обобщением.

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

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

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