Рекомендации по разделению на уровни

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

Критерии объединения подсистем:

• Область видимости. Подсистемы могут зависеть только от подсистем того же или ближайшего более низкого уровня.
• Изменчивость.
  • На высших уровнях помещайте элементы, зависящие от требований пользователя.
  • На низших уровнях помещайте элементы, зависящие от платформы реализации (аппаратное обеспечение, язык программирования, операционная система, СУБД и т.д.).
  • На средних уровнях помещайте элементы наиболее менее зависимые от систем и сред реализации.
  • Добавляйте новые уровни если более мелкая структуризация этих общих категорий позволит лучше организовать модель.
• Общность. Элементы абстрактных моделей обычно помещаются на более низких уровнях модели. Чем меньше они зависят от конкретной реализации, тем ближе их уровни должны быть к средине.
• Число уровней. Для небольшой системы достаточно трех уровней. Для более сложной системы обычно достаточно 5-7 уровней. Для любого уровня сложности не следует использовать более 10 уровней. Эмпирические соотношения:

Подсистемы и пакеты в рамках одного уровня должны зависеть от подсистем только этого же уровня или ближайшего более низкого. Невыполнение этого правила приводит к ослаблению архитектуры и делает систему неустойчивой и сложной в сопровождении.

Исключения составляют подсистемы, требующие прямого взаимодействия со службами нижних уровней: необходимо явно определить способ работы с элементарными службами, использующимися большим числом компонентов системы, такими как печать, электронная почта и т.д. Ограничивать взаимодействие с более низкими уровнями, используя промежуточные уровни для простой передачи информации, не имеет смысла, если это кардинальными образом повлияет на эффективность программы.

Шаблоны разделения

Дополнительное разбиение верхних уровней системы может помочь лучше организовать модель. Далее приведены возможные критерии дополнительного разбиения:

• Организация пользователей. Организация подсистем может отражать организацию предприятия (например, она может соответствовать делению на отделы). Такое деление обычно выполняется на ранних этапах проектирования, т.к. существующая модель организации имеет четкую структуру. Этот прием организации обычно затрагивает только несколько верхних уровней служб, связанных с приложением,и часто отбрасывается по мере развития проектирования.
  • Разбиение на основе организации пользователей может служить хорошей исходной точкой для модели.
  • Структура организации пользователей не постоянна в долгосрочной перспективе (из-за реорганизации предприятия) и не должна служить долгосрочным основанием для разбиения системы. Внутренняя организация системы должна учитывать возможность ее развития и позволять сопровождать систему независимо от организации предприятия, которое она обслуживает.
• Области компетентности и/или навыки. Подсистемы могут быть организованы в соответствии с распределением обязанностей между группами разработчиков. Обычно такой прием применяется для средних и нижних уровней системы и отражает потребность в специализации навыков при разработке и поддержке сложных технологий инфраструктур. Примерами таких технологий являются системы управления сетью и распределенными вычислениями, базами данных, связью персонала, технологическим процессом. Разделение по областям компетентности может также применяться для высших уровней, когда для понимания и поддержки ключевых функций требуется владение предметной областью. Примеры предметных областей: управление телефонными вызовами, операции с ценными бумагами, обработка требований о выплате страхового возмещения, управление воздушным движением.
• Физическое распределение системы. Любой из уровней системы может быть дополнительно разделен "горизонтально" для отражения физического распределения выполняемых функций.
  • Такое разделение помогает наглядно представить взаимодействие через сеть при работе системы.
  • В то же время, при изменении модели развертывания, разделение по распределению осложняет внесение соответствующих модификаций в систему.

• Обеспечение секретности. Для некоторых приложений, особенно требующих специальные меры обеспечения безопасности, необходимо дополнительное деление в соответствии с разными уровнями доступа. Программное обеспечение, управляющее доступом к областям с ограниченным доступом, должно разрабатываться и поддерживаться работниками обладающими соответствующим допуском к секретным материалам. Если число работников, которые могут получить такой доступ, ограничено, функции, требующие такого доступа, необходимо выделить в подсистемы, разработка которых будет вестись независимо от других подсистем. Единственная видимая остальным часть таких подсистем - интерфейс к областям с ограниченным доступом.
• Опциональность. Неключевые функции, которые скорей всего будут необязательными и будут входить только в некоторые варианты системы, следует также организовывать в отдельные подсистемы, распространяемые и разрабатываемые независимо от основной части системы.