ВУЗ:
Составители:
нужных фрагментов описания. При внесении в проект изменений потребуется
модифицировать и перекомпилировать сотни модулей. Отсюда можно понять, что
защита информации может обернуться и обратной стороной. Деление программы на
модули бессистемным образом гораздо хуже, чем отсутствие модульности вообще.
В традиционном структурном проектировании модульность связывается в первую
очередь с логической группировкой подпрограмм на
основе принципов взаимной связи и
общей логики. В объектно-ориентированном программировании ситуация несколько
иная: необходимо физически разделить классы и объекты, составляющие логическую
структуру проекта и явно отличающиеся от подпрограмм.
Модульность — это свойство системы, связанное с возможностью декомпозиции
ее на ряд тесно связанных модулей.
Таким образом, принципы абстрагирования, ограничения доступа и
модульности
являются взаимодополняющими. Объект определяет явные границы определенной
абстракции, а ограничение доступа и модульность создают барьеры между
абстракциями.
В процессе разделения системы на модули могут быть полезными два правила.
Первое состоит в следующем: поскольку модули служат в качестве элементарных и
неделимых блоков программы, которые могут использоваться в системе многократно,
распределение классов
и объектов должно создавать для этого максимальные удобства.
Второе правило вытекает из того факта, что многие компиляторы создают отдельный
сегмент кода для каждого модуля. Поэтому размер модуля должен быть соответственно
ограничен. Объявление функций в модуле может оказать большое влияние на
возможность их вызова из другого модуля, так как это связано
с разделением памяти
на страницы. Большое количество вызовов между сегментами загружает кэш-память и
снижает характеристики всей системы.
Следует сказать о нескольких других моментах. При коллективной разработке
программ распределение работы осуществляется, как правило, по модульному принципу
и правильное разделение проекта минимизирует связи между участниками проекта. При
этом более опытные программисты обычно
отвечают за интерфейс модулей, а менее
опытные — за остальную часть модулей. На более крупном уровне такие же
соотношения справедливы для предприятий-соисполнителей. В последнем случае
изменения в интерфейсе вызывают большое «напряжение» независимо от объема этих
изменений, что оказывает сильное влияние на проектирование интерфейса. Что касается
документирования проекта, то оно строится,
как правило, также по модульному
принципу. К сожалению, иногда требования по документированию считаются главными
при декомпозиции проекта (в большинстве случаев имея негативные последствия). Там,
где один модуль требует большого объема документирования, делается десять модулей.
Могут сказываться требования секретности: часть кода может быть несекретной, а
другая — секретной; последняя в виде отдельного модуля
(модулей).
Контрольные вопросы
1. Абстрагирование и ограничение доступа
2. Интерфейс.
3. Внутреннее строение.
4. Ограничение доступа.
5. Модульность.
