Приступая к разработке каждой программы ПС, следует иметь в виду, что она, как правило, является большой системой, поэтому мы должны при-нять меры для ее упрощения. Для этого такую программу разрабатывают по частям, которые называются программными модулями. А сам такой метод разработки программ называют модульным программированием. Программ-ный модуль это любой фрагмент описания процесса, оформляемый как са-мостоятельный программный продукт, пригодный для использования в опи-саниях процесса. Это означает, что каждый программный модуль програм-мируется, компилируется и отлаживается отдельно от других модулей про-граммы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, дек-ларированные в документации по этому модулю. Таким образом, программ-ный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний). Программы разбиваются на модули для того, чтобы: - упростить их разработку и реализацию; - облегчить чтение программ; - упростить их настройку и модификацию; - облегчить работу с данными, имеющими сложную структуру; - избежать чрезмерной детализации алгоритмов; - обеспечить более выгодное размещение программ в памяти ЭВМ.
Не всякий программный модуль способствует упрощению программы. Выделить хороший с этой точки зрения модуль является серьезной творче-ской задачей. Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт предложил следующие два общих критерия: - хороший модуль снаружи проще, чем внутри; - хороший модуль проще использовать, чем построить. Майерс предлагает для оценки приемлемости программного модуля использовать более конструктивные его характеристики: - размер модуля; - прочность модуля; - сцепление с другими модулями; - рутинность модуля (независимость от предыстории обращений к нему). Размер модуля измеряется числом содержащихся в нем операторов или строк. Модуль не должен быть слишком маленьким или слишком боль-шим. Маленькие модули приводят к громоздкой модульной структуре про-граммы и могут не окупать накладных расходов, связанных с их оформлени-ем. Большие модули неудобны для изучения и изменений, они могут сущест-венно увеличить суммарное время повторных трансляций программы при отладке программы. Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов. Прочность(связность) модуля - это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других моду-лей. Рутинность модуля - это его независимость от предыстории обраще-ний к нему. Модуль будем называть рутинным, если результат (эффект) об-ращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внут-реннего состояния этого модуля, изменяемого в результате предыдущих об-ращений к нему. Майерс не рекомендует использовать зависящие от пре-дыстории (непредсказуемые) модули, так как они провоцируют появление в программах хитрых (неуловимых) ошибок. Однако такая рекомендация явля-ется неконструктивной, так как во многих случаях именно зависящий от пре-дыстории модуль является лучшей реализаций информационно прочного мо-дуля. Поэтому более приемлема следующая (более осторожная) рекоменда-ция: - всегда следует использовать рутинный модуль, если это не при-водит к плохим (не рекомендуемым) сцеплениям модулей; - зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления; - в спецификации зависящего от предыстории модуля должна быть четко сформулирована эта зависимость таким образом, чтобы было возмож-но прогнозировать поведение (эффект выполнения) данного модуля при раз-ных последующих обращениях к нему. В связи с последней рекомендацией может быть полезным определе-ние внешнего представления (ориентированного на информирование челове-ка) состояний зависящего от предыстории модуля. В этом случае эффект вы-полнения каждой функции (операции), реализуемой этим модулем, следует описывать в терминах этого внешнего представления, что существенно упро-стит прогнозирование поведения данного модуля.
