Термин «модуль» традиционно используется в двух смыслах (таблица 6.1).
Таблица 6.1 Понятие модуля
«Старое» понимание модуля
| «Новое» понимание модуля
|
Последовательность связанных фрагментов программы, обращение к которой выполняется по имени (процедура или функция)
| Автономно компилируемая программная единица
|
Требования к модулю:
|
• одна точка входа;
• одна точка выхода;
• соответствие принципу вертикального управления;
• возможность вызова других модулей;
• небольшой размер (до 50-60 операторов языка);
• независимость от истории вызовов;
• выполнение одной функции.
| • отдельная компиляция;
• независимость
|
Чем выше степень независимости модулей, тем:
• легче разобраться в отдельном модуле и всей программе и, соответственно, тестировать, отлаживать и модифицировать ее;
• меньше вероятность появления новых ошибок при исправлении старых или внесенииизменений в программу, т. е. вероятность появления «волнового» эффекта;
• проще организовать разработку программного обеспечения группой программистов и легче его сопровождать.
Таким образом, уменьшение зависимости модулей улучшает технологичность проекта.
Сцепление модуля - это мера его зависимости по данным от других модулей.
Сцепление по данным предполагает, что модули обмениваются данными, представленными скалярными значениями. При небольшом количестве передаваемых параметров этот тип обеспечивает наилучшие технологические характеристики программного обеспечения.
Сцепление по образцу предполагает, что модули обмениваются данными, объединенными в структуры. Этот тип также обеспечивает неплохие характеристики, но они хуже, чем у предыдущего типа, так как конкретные передаваемые данные «спрятаны» в структуры, и потому уменьшается «прозрачность» связи между модулями. Кроме того, при изменении структуры передаваемых данных необходимо модифицировать все использующие ее модули.
При сцеплении по управлению один модуль посылает другому некоторый информационный объект (флаг), предназначенный для управления внутренней логикой модуля. Таким способом часто выполняют настройку режимов работы программного обеспечения. Подобные настройки также снижают наглядность взаимодействия модулей и потому обеспечивают еще худшие характеристики технологичности разрабатываемого программного обеспечения по сравнению с предыдущими типами связей.
Сцепление по общей области данных предполагает, что модули работают с общей областью данных. Этот тип сцепления считается недопустимым, поскольку:
• программы, использующие данный тип сцепления, очень сложны для понимания при сопровождении программного обеспечения;
• ошибка одного модуля, приводящая к изменению общих данных, может проявиться при выполнении другого модуля, что существенно усложняет локализацию ошибок;
• при ссылке к данным в общей области модули используют конкретные имена, что уменьшает гибкость разрабатываемого программного обеспечения.
Рутинность модуля - это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему.
В настоящее время используют два способа декомпозиции разрабатываемого программного обеспечения, связанные с соответствующим подходом:
• процедурный (или структурный - по названию подхода);
• объектный.
Для процедурного способа декомпозиции модули зависящие от предыстории – недопустимы.