Структура шаблона проектирования - Уровни (отрывок из книги)Buschmann F., Meunier R., Rohnert H., Sommerlad P., Stal M., Sommerlad P. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. - US: John Wiley, 1996.Шаблон уровней позволяет структурировать приложения, которые могут быть декомпозированы на группы подзадач, в которых каждая группа подзадач является особым уровнем абстракции. Пример Сетевые протоколы, вероятнее всего, являются наиболее известным примером многоуровневой архитектуры. Подобные протоколы состоят из множества правил и конвенций, которые описывают, как компьютерные программы, находящиеся на разных машинах, обмениваются сообщениями между собой. Формат, содержание и значения всех сообщений определены. Все сценарии описаны детально, как привило, путем предоставления последовательностей действий (charts). Протокол определяет соглашения на множество абстрактных уровней, классифицируя, начиная с деталей передачи бит, и заканчивая высокоуровневой логикой приложения. Следовательно, проектировщики используют несколько второстепенных протоколов (subprotocols) и объединяют их в уровни. Каждый слой сотрудничает определенным образом с последующим нижележащим уровнем, а также использует его сервисы. Международная организация стандартизации (ISO) определила такую модель, как семиуровневую модель OSI (OSI 7 Layer Model).
При проектировании протоколов использование многоуровневого подхода с практической точки зрения считается лучше, чем их проектирование в виде монолитного блока. Вследствие разграничения концептуально разных проблем по разным уровням, получились следующие выгоды: например, возможность вспомогательной разработки командами, а также возможность инкрементного кодирования и тестирования. Использование полунезависимых частей, также позволяет легко заменять отдельные части в будущем. Лучше реализованные технологии, такие как новые языки или алгоритмы, могут быть внедрены путем простой замены необходимого локализованного кода. В то время как OSI является важной эталонной моделью, TCP/IP, также известный как "Набор интернет протоколов" ("Internet protocol suite"), является общепринятым интернет протоколом. Мы воспользуемся TCP/IP для иллюстрации важной причины разбиения на уровни, а именно, повторное использование отдельных уровней в различных контекстах. Например, TCP может быть использован другими распределенными приложениями, такими как telnet и ftp. Контекст использования Большие системы, нуждающиеся в декомпозиции. Постановка задачи Представьте, что вы проектируете систему, чьей главной характеристикой является смесь, низкоуровневых и высокоуровневых вопросов, где высокоуровневые операции зависят от низкоуровневых операций. Некоторые части системы отвечают за реализацию низкоуровневых вопросов, таких как, аппаратные прерывания, ввод с датчиков, чтение бит из файла, или электрических сигналов с проводника. С другой стороны, здесь может присутствовать функциональность, видимая пользователю, такая как многопользовательский интерфейс компьютерной игры, или высокоуровневая политика управления трафиком телефонных звонков. Стандартный шаблон направления общения состоит из запросов, двигающихся с верхнего уровня на нижний уровень, и ответов на запросы, входящие данные или оповещения о событиях, протекающих на другой стороне. Подобные системы часто также нуждаются в некотором горизонтальном структурировании, которое ортогонально их вертикальному подразделению. Это тот случай, где несколько операций находятся на одинаковых уровнях абстракции, но они также в большой степени независимы друг от друга. Пример этого вы можете видеть на диаграмме, иллюстрирующей семиуровневую модель OSI там, где встречается слово "и". Спецификация системы подготавливает Вам описание высокоуровневых задач с некоторой степенью детализации, и указывать целевую платформу. Переносимость на другие платформы желательна. Некоторые внешние границы системы определяются априорно, такие как функциональный интерфейс, которому Ваша система должна соответствовать. Отображение высокоуровневых задач на платформу не просто, в большей степени потому, что они слишком комплексные, для того чтобы быть реализованными таким образом, чтобы напрямую использовать сервисы, которые предоставляются платформой. В таком случае необходимо искать компромиссы между следующими моментами:
Решение задачи С высокоуровневой точкой зрения проект должен быть максимально прост. Необходимо структурировать систему на подходящее число уровней, и затем расположить их друг над другом. Начните с самого нижнего уровня абстракции, и назовите его Уровень 1. Это основа Вашей системы. Двигайтесь вверх по лестнице абстракций, располагая Уровень J над Уровнем J-1 до тех пор, пока не достигнете абстракции верхнего уровня – назовите ее Уровень N. Отметьте, что это не описывает последовательность, в которой точно нужно проектировать уровни. Это также не описывает, должен ли Уровень J быть комплексной подсистемой, нуждающейся в дальнейшей декомпозиции, или должен ли он просто преобразовывать запросы от Уровня J+1 к запросам Уровня J-1и делает небольшие взносы себе. Однако это существенно, что в пределах отдельного уровня все составляющие компоненты работают на одном и том же уровне абстракции. Большинство сервисов, предоставляемым Уровнем J, состоят из сервисов, предоставляемых Уровнем J-1 Другими словами, сервисы каждого уровня реализуют свою стратегию путем комбинирования различными способами сервисов нижележащих уровней. В дополнение, сервисы Уровня J могут зависеть от других сервисов этого же уровня. |