Модульность
Декомпозиция подсистем на модули
Известны два типа моделей модульной декомпозиции:
- модель потока данных;
- модель объектов.
В основе модели потока данных лежит разбиение по функциям.
Модель объектов основана на слабо сцепленных сущностях, имеющих собственные наборы данных, состояния и наборы операций. Очевидно, что выбор типа декомпозиции должен определяться сложностью разбиваемой подсистемы.
Модуль – фрагмент программного текста, являющийся строительным блоком для физической структуры системы. Как правило, модуль состоит из интерфейсной части и части-реализации.
Модульность – свойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей. По определению Г. Майерса, модульность– свойство ПО, обеспечивающее интеллектуальную возможность создания сколь угодно сложной программы [52]. Проиллюстрируем эту точку зрения.
Пусть С(х) – функция сложности решения проблемы х, Т(х) – функция затрат времени на решение проблемы х. Для двух проблем р1 и р2 из соотношения С(р1)> С(р2) следует, что
Т(р1)>Т(р2). (1.1)
Этот вывод интуитивно ясен: решение сложной проблемы требует большего времени. Далее. Из практики решения проблем человеком следует:
С(р1+ р2)>С(р1)+С(р2).
Отсюда с учетом соотношения (1.1) запишем:
Т(р1+ р2)>Т(р1)+Т(р2) (1.2)
Соотношение (1.2) – это обоснование модульности. Оно приводит к заключению «разделяй и властвуй» – сложную проблему легче решить, разделив ее на управляемые части. Результат, выраженный неравенством (1.2), имеет важное значение для модульности и ПО. Фактически, это аргумент в пользу модульности.
Однако здесь отражена лишь часть реальности, ведь здесь не учитываются затраты на межмодульный интерфейс. Как показано на рис. 1.11, с увеличением количества модулей (и уменьшением их размера) эти затраты также растут.
Рис 1.11 Затраты на модульность
Таким образом, существует оптимальное количество модулей Opt, которое приводит к минимальной стоимости разработки. Увы, у нас нет необходимого опыта для гарантированного предсказания Opt. Впрочем, разработчики знают, что оптимальный модуль должен удовлетворять двум критериям:
- снаружи он проще, чем внутри;
- его проще использовать, чем построить.