1 Основы проектирования программных систем

Рис. 6-14. Система, управляемая прерываниями

Данный паттерн используется в жестких системах реального времени, где тре­буется немедленная реакция на события.
Декомпозиция подсистем на модули
После проектирования системной структуры и определения принципов унравления структурой следует вынолнить разделение подсистем на модули. Фактически эту работу можно считать введением в детальное проектирование, которое конкрети­зирует архитектурные решения. Задача декомпозиции — это задача определения внутреннего содержания каждой подсистемы (компонента). Результатом ее решения является формирование структуры нодсистемы — набора модулей и от­ношений их взаимодействия.
Известны два подхода и два тина моделей для декомнозиции подсистем на модули:

• 
  модель потока данных;
  
• 
  объектно-ориентированная модель.
  

В основе модели нотока данных лежит разбиение но функциям. При выборе этой модели нолучим набор функциональных модулей и определим связи между ними. Нанример, результат может быть похож на реализацию диаграммы потоков данных.
Объектно-ориентированная модель основана на объектах (слабо сценленных сущностях, имеющих собственные наборы данных, состояния, наборы онераций) и их описаниях — классах.
Применение модели потока данных в ходе проектирования рассмотрим в сле­дующей главе. Использование объектно-ориентированной модели будет подробно обсуждаться во многих последующих главах.
Какой тин декомпозиции следует выбирать? Ответ на этот вонрос зависит от большого количества факторов, в том числе и от сложности разбиваемой подси­стемы.
Разделение понятий
В 1972 году великий Э. Дейкстра ввел очень важный принцип нроектирования — разделение понятий (separation of concerns) [3]:
Любую сложную проблему проще понять,разделив ее на части, каждую из кото­рых можно решать и оптимизировать независимо.
Понятие — это черта (свойство, отличительная особенность), или поведение, которое определяется как часть модели требований к ПО. Разделяя понятия на небольшие и ноэтому более управляемые части, мы экономим усилия и время на решение проблемы. Проиллюстрируем эту точку зрения.
Пусть С(х) — функция сложности решения проблемы х, Т(х) — функция за­трат времени на решение нроблемы х. Для двух проблем р_{ и р₂ из соотношения С(р_{) > С(р₂) следует, что
Г(_А)>Г(_А). (6.1)
Этот вывод интуитивно ясен: решение сложной нроблемы требует большего времени.
Далее. Из практики решения проблем человеком следует
С(А+а)>^с(А) + ^с<А)-
Отсюда, с учетом соотношения (6.1), запишем
Г(а+^₂)> W + Г(р₂). (6.2)
Соотношение (6.2) — это обоснование модульности. Оно приводит к заклю­чению «разделяй и властвуй» — сложную проблему легче решить, разделив ее на управляемые части. Результат, выраженный неравенством (6.2), имеет важное значение для модульности и ПО. Фактически это аргумент в нользу модульности.
Разделение нонятий провозглашается во многих принцинах нроектирования, нанример в модульности, аснектах и пошаговой детализации. Каждый из этих принцинов мы обсудим в следующих разделах.
Модульность
Модульность — это наиболее общая демонстрация разделения понятий. Программ­ная система делится на именуемые и адресуемые компоненты, часто называемые модулями, которые затем интегрируются для совместного решения нроблемы.
Модуль — фрагмент программного текста, являющийся строительным блоком для физической структуры системы. Как нравило, модуль состоит из интерфейсной части и части-реализации.
Модульность — свойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей.
По определению Г. Майерса модульность — свойство ПО, обеспечивающее интеллектуальную возможность создания сколь угодно сложной программы [76]. Монолитное ПО, то есть состоящее из одного модуля, не поддается воспри­ятию программным инженером. Огромное количество альтернативных ветвей, множество ссылок, переменных, наконец, общая сложность во многих случаях недоступны для понимания. Вы вынуждены разбивать «монолит» на модули в расчете на упрощение понимания и, как следствие, на уменьшение стоимости создания ПО.
Возвращаясь к обсуждению разделения нонятий, заключаем, что путем после­довательного дробления ПО можно добиться, что затраты на разработку станут ничтожно малы. Однако это отражает лишь часть реальности — ведь здесь не учи­тываются затраты на дальнейшую интеграцию модулей. Как показано на рис. 6.15, с увеличением количества модулей (и уменьшением их размера) такие затраты также растут.






Стоимость