Лекци 14

Проектирование архитектуры системы. Классическая трехуровневая
архитектура
Типичная архитектура информационных систем, включающая интерфейс
пользователя и хранение данных на постоянным носителем, называется трехуровневой
архитектурой. При такой архитектуре приложение делится по вертикали на три уровня.

Уровень представления – окна, отчеты и т.д.

Уровень логики приложения – задачи и правила управления процессом.

Уровень данных – механизм постоянного хранения данных.
Неотъемлемой частью трехуровневой является вынесение логики приложения на
отдельный уровень. Уровень представления является относительно независимым от
выполнения основных задач приложения. Его объекты лишь направляют запросы на
средний уровень логики приложения, а средний уровень, в свою очередь, взаимодействует
с самым нижним уровнем хранения данных.
Эта архитектура существенно отличается от двухуровневой архитектуры, при
которой логика приложения включается в определения окон графического интерфейса.
Объекты графического интерфейса взаимодействуют непосредственно с базой данных, и
отдельного среднего уровня логики приложения не существует. Недостатком
двухуровневой архитектуры является невозможность представления логики приложения
посредством отдельных компонентов, обеспечивающих возможность повторного
использования объектов. При этом невозможно распространить логику приложения на
другой компьютер.
Чтобы справиться со сложностью, присущей большим программным системам,
необходимо сформировать определенный подход к разбиению системы на подсистемы и к
созданию общей архитектуры системы на основе критериев декомпозиции. После
выполнения декомпозиции и задания интерфейсов между подсистемами каждую
подсистему допустимо разрабатывать независимо.
Декомпозиция системы
Система разбивается на подсистемы, состоящие из объектов, которые
функционально зависят друг от друга. Подсистема должна минимально зависеть от других
подсистем. С другой стороны, степень связанности между объектами внутри одной
подсистемы обязана быть высокой. Подсистему удобно рассматривать как составной
объект, содержащий более простые объекты.
Во время анализа предметной области и декомпозиции системы акцент ставится на
разделении обязанностей. Каждая подсистема выполняет некоторую основную функцию,
которая мало зависит от функциональности других подсистем. Подсистему допустимо
разложить на более мелкие подсистемы, обеспечивающие выполнение части ее функций.
После того как будет определен интерфейс между подсистемами, их дальнейшее
проектирование можно вести независимо.
Подсистема обеспечивает сокрытие информации на более высоком уровне, чем
объект. Разбиение системы на подсистемы следует начинать с изучения прецедентов.
Основой подсистемы служит модель взаимодействия объектов в прецеденте, поскольку
они связаны друг с другом. Степень такой связанности достаточно высока, в отличие от
степени связанности с объектами из других прецедентов (она мала или отсутствует).
Объект, принимающий участие сразу в нескольких прецедентах, следует отнести к какойто одной подсистеме – обычно к той, с которой он теснее связан. Иногда подсистема
включает объекты из разных прецедентов. Чаще всего так бывает, когда в нескольких
прецедентах имеются общие, функционально связанные между собой объекты.
В некоторых приложениях, например в системах клиент-сервер, подсистемы легко
идентифицируются. Так, в банковской системе есть подсистема Банкомат, размещенная в
каждом банкомате, и центральная подсистема Банковской Сервер. Это пример разбиения
1
на подсистемы по географическому признаку, когда географическая удаленность
заложена в самом описании задачи. Территориальное распределение – очень веская
причина для выделения подсистем.
В других случаях не таких очевидно, что следует считать подсистемой. Поскольку
цель разбиения на подсистемы – объединить тесно связанные по функциональному
признаку объекты, то начать лучше всего с прецедентов. Объекты, участвующие в одном
и том же прецеденте, – это кандидаты на включение в общую подсистему, если только
они не являются территориально удаленными. Поэтому разбиение на подсистемы обычно
производят после выявления объектов, принимающих участие в прецеденте, и
изображения их на диаграммах взаимодействия.
Консолидированные диаграммы кооперации
При разработке аналитической модели были составлены диаграммы
взаимодействия для каждого прецедента. Консолидированная диаграмма кооперации
получается при объединении отдельных диаграмм.
Визуально консолидация происходит так: берется диаграмма кооперации для
первого прецедента, и на нее накладывается диаграмма кооперации для второго
прецедента. Затем поверх них располагают третью диаграмму и т.д. В каждом случае в
консолидированную диаграмму включаются новые объекты и сообщения, поэтому она
постоянно усложняется. На консолидированной диаграмме кооперации должны быть
представлены все сообщения.
Часто
на
диаграммах
кооперации
показывают
только
основную
последовательность, а альтернативные опускают. На консолидированной диаграмме
нужно отразить и сообщения, посылаемые при исполнении альтернативных
последовательностей.
Дополнительные
сообщения
необходимо
включить
в
консолидированную диаграмму, которая призвана дать полную картину всех
коммуникаций. Естественно, в таком случае информации оказывается гораздо больше.
Один из способов уменьшить объем сведений состоит в агрегировании: если один объект
посылает другому несколько отдельных сообщений, то они показываются не по
отдельности, а в составе одного агрегированного сообщения.
Если система большая, то консолидированная диаграмма сильно разрастается, так
что изображать все объекты на ней становится неудобно. Чтобы справиться с этим,
допустимо показывать объекты, а сообщения, которыми они обмениваются, помечать
агрегированными именами, о чем уже говорилось выше. На следующем рис. примерами
имен агрегированных сообщений являются Транзакции Банкомата, Ответы Банка и
События Клиента. Другой способ заключается в том, чтобы разработать
консолидированные диаграммы кооперации для каждой подсистемы и высокоуровневую
диаграмму кооперации подсистем, на которой будут показаны взаимодействия между
подсистемами.
2
1. Пример консолидированной диаграммы кооперации: подсистема Банкомат
3
Архитектура подсистем
Подсистемы можно изображать на диаграммах кооперации или на диаграммах
классов. Диаграмма классов подсистемы передает структурные отношен между
подсистемами.
Динамические взаимодействия между подсистемами можно изображать на диаграмме
кооперации подсистем, которая представляет собой высокоуровневую консолидированную
диаграмму кооперации. Структуру отдельной подсистемы лучше изобразить на ее
собственной консолидированной диаграмме кооперации отражающей все входящие в
подсистему объекты и их взаимодействия.
На рис. 2 приведен пример диаграммы кооперации подсистем в банков системе.
Имеются две подсистемы: Банкомат (существует в нескольких экземплярах) и Банковский
Сервер (существует в одном экземпляре).
рис 2. Пример проектирования подсистемы: высокоуровневая диаграмма кооперации
для банковской системы
Разделение обязанностей при проектировании подсистем
Чтобы обеспечить высокую степень связанности внутри одной подсистем и низкую
степень связанности между разными подсистемами, необходимо соблюдать следующие
рекомендации по декомпозиции системы, касающиеся разделения обязанностей.
Агрегированный/составной объект. Объекты, являющиеся частями одного и того же
агрегированного или составного объекта, следует помещать в одну систему и отделять от
объектов, которые не являются частями того же агрегата. Агрегирование, и композиция
являются отношениями типа целое/часть, но композиция - это более сильная форма
агрегирования. В случае композиции составной объект (целое) и входящие в него объекты
(части) создаются, живут и умирают вместе. Поэтому подсистема, содержащая составной
объект и его части, сильнее связана, чем подсистема, содержащая агрегированный объект.
Подсистема обеспечивает сокрытие информации на более высоком уровне
абстракции, нежели отдельный объект. Программный объект можно использовать для
моделирования реального объекта из предметной области. В частности, составной
4
программный объект моделирует составной объект, существующий в реальном мире.
Как правило, составной объект включает в себя группу объектов, те работают
совместно и скоординировано. Этим он напоминает сборную в производстве. Часто
приложению требуется несколько экземпляров составного объекта (а значит, и
каждого из составляющих его объектов). Отношение между составным классом и его
частями уместнее всего изображать на статической модели, поскольку диаграмма
классов позволяет показать кратность ассоциаций между целым и частями.
Агрегированная система вполне может представлять собой высокоуровневую
подсистему, содержащую составные подсистемы.
Примером составного класса служит класс Лифт (рис. 3). Каждый Лифт содержит
объекты Кнопка Лифта, Лампочка Лифта, один Мотор и одну Дверь. Существует несколько
экземпляров составного класса Лифт - по одному на каждый лифт. Другой пример составного
класса - Этаж. Он включает в себя объекты Кнопка Этажа (для вызовов лифта с верхних и
нижних этажей), два объекта Лампочка Этажа и два объекта Лампочка Направления.
Исключением являются первый и последний этажи, где есть только по одной кнопке и
лампочке. Имеется несколько экземпляров составного класса Этаж - по одному для каждого
этажа здания.
рис 3
ГЕОГРАФИЧЕСКОЕ положение. Если два объекта физически находятся в разных
местах, они должны принадлежать различным подсистемам. В распределенной среде
общение между разнесенными подсистемами может происходить только путем
обмена сообщениями.
Клиенты и серверы. Клиенты и серверы должны принадлежать разным подсистемам.
Эту рекомендацию можно считать частным случаем разбиения по географическому признаку,
поскольку клиенты и серверы обычно находятся в разных местах. Например, в банковской
системе есть много однотипных подсистем Банкомат, размещенных в конкретных
физических банкоматах на территории страны. Подсистема же Банковский Сервер находится
в одном месте возможно в Нью-Йорке.
Интерфейс пользователя. Обычно ПК пользователей являются частью крупной
распределенной конфигурации, поэтому наиболее гибким будет решение, при котором
объекты интерфейса пользователя находятся в отдельной подсистеме. Поскольку чаще всего
такие объекты являются клиентами, данную рекомендацию можно рассматривать как
частный случай рекомендаций, касающихся систем клиент-сервер.
Интерфейс с внешними объектами. Подсистема имеет дело с частью множества
актеров, показанных на модели прецедентов, и с частью множества внешних объектов
реального мира, изображенных на диаграмме контекста. Внешние объекты должны иметь
интерфейс только с одной подсистемой.
Область управления. Управляющий объект, а также те сущностные и интерфейсные
объекты, которыми он манипулирует напрямую, должны входить в одну подсистему.
5
Сущностные объекты. Сущностный объект сильнее связан с теми объектами,
которые его обновляют, чем с теми, которые извлекают из него данные. Поэтому в случае,
когда есть выбор, сущностный объект следует помещать в одну систему с обновляющими его
объектами.
Критерии разбиения на подсистемы
Выбор подсистем обычно диктуется приложением. Ниже будут описаны виды
подсистем, часто возникающие в приложениях.
Управление. Подсистема управления контролирует отдельный аспект всей системы.
Такая подсистема получает входную информацию из внешней сред и генерирует для нее
выходную информацию, обычно без вмешательства человека. Часто подсистема управления
зависит от состояния, и тогда в ней есть хотя бы один зависящий от состояния управляющий
объект. Иногда часть данных собирается другими подсистемами и используется подсистемой
управления. Наоборот, подсистема управления может предоставлять определенные данные
другим подсистемам.
Координатор. Если подсистем управления несколько, иногда требуется подсистема,
координирующая их действия. Если подсистемы управления абсолютно независимы, то
координация не нужна. В некоторых случаях подсистемы управления самостоятельно
координируют свою деятельность. Такое возможно, если координация сравнительно проста.
Но случается, что для координации необходимы значительные усилия, и тогда лучше
поручить это специальной подсистеме.
Примером служит подсистема Планировщик в системе управления лифтами. Здесь
каждый запрос, сделанный пассажиром, должен быть обслужен лифтом, в котором он
находится. Однако, если запрос поступает от человека, ожидающего на этаже, система вправе
сама решить, какой из имеющихся лифтов обслужит запрос. Если лифт уже на пути к этажу и
двигается в нужном вправлении, то никаких специальных действий не требуется. В
противном случае лифт нужно направить на этаж. Обычно решение принимается с учетом
близости лифта к этажу и направления движения. Принятие решения возлагается на
подсистему Планировщик (см. рис. 4). Когда Планировщик получает Запрос на
Обслуживание от Подсистемы Этажа, он решает, какому лифту передать запрос, после чего
посылает Запрос Планировщика выбранной Подсистеме Лифта.
Рис 4. Система управления лифтами
6
Сбор данных. Подсистема сбора данных накапливает информацию,
поступающую из внешней среды. Иногда она хранит сведения, прошедшие анализ и
предварительную обработку. В зависимости от приложения эта подсистема может
отвечать на запросы на получение исходных данных. В других случаях она передает
уже частично обработанную информацию: например, она способна передать
усредненное значение нескольких показаний датчика, преобразовав его инженерные единицы
измерения. Наконец, данные иногда напрямую выводятся во внешнюю среду. Возможны
также различные комбинации.
Анализ данных. Подсистема анализа данных классифицирует информацию и
предоставляет отчет либо визуально отображает данные, собранные другой подсистемой. В
принципе сбором и анализом данных может заниматься одна и также подсистема. В других
случаях поиск сведений осуществляется в реальном масштабе времени, а анализ
производится позже.
Сервер. Серверная подсистема предоставляет сервисы другим подсистема. Она
отвечает на запросы клиентских подсистем, но сама не инициирует никак запросов. Сервером
может считаться любой объект, обслуживающий запросы клиентов. В простейшем случае
объект-сервер может состоять всего из одного сущностного объекта. Более сложные серверы
включают два и более объектов, в том числе сущностные объекты, координаторы, которые
определяют, какой объект должен обслужить запрос клиента, и объекты бизнес-логики. Часто
сервер предоставляет сервисы связанные с одним или несколькими хранилищами данных,
либо доступ к базе данных или ее части. Сервер может быть также ассоциирован с
устройством ввода/вывода или набором таких устройств. В качестве примеров назовем файлсерверы и серверы печати.
Интерфейс пользователя. Подсистема интерфейса пользователя выступает в роли
клиента, предоставляя пользователю доступ к сервисам одного или нескольких серверов.
Таких подсистем может быть несколько, по одной для каждой категории пользователей.
Обычно подсистемой интерфейса пользователя является объект, составленный из нескольких
более простых интерфейсных объектов.
Подсистема ввода/вывода. В некоторых системах полезно сгруппировать все классы
интерфейсов устройств в одну подсистему ввода/вывода, поскольку для разработки таких
классов нужны специальные знания. Из-за этого создавать и сопровождать подсистему
ввода/вывода способны лишь немногие программисты.
Системные службы. Некоторые сервисы, например управление файлами и сетью, не
связаны с конкретной предметной областью, а предоставляются самой системой. Хотя такие
подсистемы обычно не являются частью приложения, о них нужно помнить. Системные
службы реализуются на уровне системы и используются прикладными подсистемами.
7