Декомпозиция подсистем на модули

Известны два типа моделей модульной декомпозиции:

q модель потока данных;

q модель объектов.

В основе модели потока данных лежит разбиение по функциям.

Модель объектов основана на слабо сцепленных сущностях, имеющих собственные наборы данных, состояния и наборы операций.

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

Модульность

Модуль – фрагмент программного текста, являющийся строительным блоком для физической структуры системы. Как правило, модуль состоит из интерфейсной части и части-реализации.

Модульность – свойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей.

По определению Г. Майерса, модульность – свойство ПО, обеспечивающее интеллектуальную возможность создания сколь угодно сложной программы [52]. Проиллюстрируем эту точку зрения.

Пусть С(х) – функция сложности решения проблемы х, Т(х) – функция затрат времени на решение проблемы х. Для двух проблем р₁ и р₂ из соотношения С(р₁) > С(р₂) следует, что

T(p_l)>T(p₂). (4.1)

Этот вывод интуитивно ясен: решение сложной проблемы требует большего времени.

Далее. Из практики решения проблем человеком следует:

С(р₁+ р₂)>С(р₁) + С(р₂).

Отсюда с учетом соотношения (4.1) запишем:

T(p_l+p₂)>T(p_l) + T(p₂). (4.2)

Соотношение (4.2) – это обоснование модульности. Оно приводит к заключению «разделяй и властвуй» – сложную проблему легче решить, разделив ее на управляемые части. Результат, выраженный неравенством (4.2), имеет важное значение для модульности и ПО. Фактически, это аргумент в пользу модульности.

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

Рис. 4.11.Затраты на модульность

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

q снаружи он проще, чем внутри;

q его проще использовать, чем построить.