Введение
При проектировании сложноорганизованной интеллектуальной транспортной системы (ИТС) необходимо выявить объекты предметной области (ПрО), отнести их к классам, соблюдая разумную степень детализации, определить интерфейсы классов и иерархию наследования, установить регламент отношений между классами. Проект ИТС должен, с одной стороны, соответствовать решаемой задаче, с другой – быть общим, чтобы учесть все требования к системе, которые могут возникнуть в будущем. Необходимо избежать или, по крайней мере, свести к минимуму необходимость перепроектирования [4]. Во многих объектно-ориентированных системах можно встретить шаблоны, состоящие из классов и взаимодействующих объектов, с помощью которых решаются конкретные задачи проектирования, существующие во многих системах. Обобщение и классификация таких задач и наиболее удачных путей их решения привело к появлению паттернов – образцов, шаблонных моделей, формализованных описаний часто встречающихся задач проектирования, эффективных, в определенном контексте, типовых решений проектной (программной) проблемы [7].
1. Паттерны проектирования ИТС
Под паттерном проектирования в рамках проектирования ИТС будем понимать описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте. Каждый паттерн ИТС описывает некую повторяющуюся проблему и ключ к ее разгадке, причем таким образом, что этим ключом можно пользоваться при решении самых разнообразных задач. Паттерн проектирования именует, абстрагирует и идентифицирует ключевые аспекты структуры общего решения, которые и позволяют применить его для создания повторно используемого проекта ИТС.
В современной программной инженерии создание программных продуктов, равно как и сами эти продукты, опирается на экспликацию интеллектуальной роли программно-технических понятий. В этом смысле архитектура ИТС [4] включает структурно-функциональные компоненты, которые по отдельности или в определенных сочетаниях призваны отобразить интеллектуальные единицы общей схемы проектирования и технологические составляющие, с помощью которых рассматриваемые интеллектуальные единицы порождаются и увязываются между собой.
2. Архитектурные паттерны интеллектуальной транспортной системы
Интеллектуальная транспортная система представляет собой многоуровневую, сложноорганизованную сеть взаимодействующих друг с другом подсистем [1]. Структурные элементы ИТС организуются в отдельные уровни с взаимосвязанными обязанностями таким образом, что на нижнем уровне располагаются низкоуровневые службы и службы общего назначения, а на более высоких – объекты уровня логики приложения. При этом взаимодействие и связывание уровней происходит сверху вниз (рис. 1).
Уровень представления охватывает все, что имеет отношение к общению пользователя с системой. К главным функциям верхнего уровня представления относится отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте домена (бизнес-логики) и источника данных. Источник данных являет собой подмножество функций, обеспечивающих взаимодействие со сторонними системами. Примером данного подхода может служить модель взаимодействия открытых систем (OSI – Open System Interconnection) [3].
Рисунок 1. Иерархия архитектурных уровней ИТС
Гибридность и многофункциональность ИТС требует определения механизма взаимодействия нескольких разнородных подсистем, их интеграции в единое пространство данных и функционалов. Концепция интеграции систем по данным характерна для традиционных систем «клиент-сервер», к которым относится ИТС, основным системообразующим фактором которой является интегрированная база данных (БД) коллективного доступа [5]. Интегрирующей средой является система управления БД (СУБД) со стандартным интерфейсом доступа к данным, к которым обращаются все приложения, объединенные в информационную систему. Изменения, произведенные в одном из приложений, автоматически отражаются в другом. За корректность данных отвечает многопользовательская СУБД ИТС. Функции прикладной обработки размещаются в клиентских программах [2]. Преимуществом совместного использования больших объемов данных является отсутствие необходимости передавать данные из одной подсистемы в другие, что, безусловно, уменьшает степень связывания.
Паттерн, обеспечивающий хранение данных в центральной БД, доступной всем подсистемам, – «Репозиторий данных», является пассивным элементом, а управление им возложено на подсистемы. В ИТС, использующей репозиторий, резервное копирование, обеспечение безопасности, управление доступом и восстановление данных централизованы, поскольку входят в систему управления репозиторием [4]. Недостатком интегрированного хранения является необходимость согласования всех подсистем со структурой репозитория, т.к. к разным подсистемам предъявляются различные требования по безопасности, восстановлению и резервированию данных, а в паттерне «Репозиторий данных» ко всем подсистемам применяется одинаковая политика.
Объектно-центрический паттерн «Интеграция корпоративных информационных систем» основан на стандартах объектного взаимодействия CORBA, COM/DCOM, .NET и пр. и является композицией типов объединения систем по данным. Концепция интеграции заключается в объединении подсистем ИТС вокруг общедоступных распределенных объектов предметной области ИТС со стандартными интерфейсами. Характерными особенностями данного подхода являются:
- унифицированный язык спецификации интерфейсов объектов;
- отделение реализации компонентов от спецификации их интерфейсов;
- общий механизм поддержки взаимодействия объектов.
Интегрирующей средой является супервизор объектных запросов с интерфейсом в стандарте CORBA или DCOM. Общая архитектура системы формируется на основе распределенных объектов и является n-звенной.
Паттерн «Интеграция на основе единой понятийной модели предметной области» основан на интеграции разнородных подсистем ИТС в рамках единой системы. Решением проблемы данного типа интеграции является разработка общесистемного языка взаимодействия компонентов, основанного на единой понятийной модели, описывающей объекты ПрО, их взаимосвязи и поведение. Единая понятийная модель ПрО ИТС представляет собой базу метаданных, хранящую описания интерфейсных бизнес-объектов каждого из компонентов и отношения между этими объектами [6]. Между интегрируемыми компонентами и их описаниями в базе метаданных поддерживается постоянное соответствие. Преобразование сообщений на обобщенном языке в вызовы функций той или иной интегрирующей среды обеспечивается дополнительной интегрирующей оболочкой с единым интерфейсом, который предназначен только для обмена сообщениями.
Структура взаимодействия компонентов интегрирующей среды имеет различные конфигурации «конвейер», «звезда» (рис. 2), смешанный.
Рисунок 2. Структура взаимодействия компонентов интегрирующей среды
«Звезда» характеризуется наличием центрального компонента – супервизора, управляющего взаимодействием подсистем в рамках интеллектуальной транспортной системы в целом. Интегрирующая среда содержит платформу для исполнения сценариев транзакции, базовый функционал по взаимодействию приложений, службы протоколирования и мониторинга состояния интегрирующей среды.
Обобщенный паттерн ИТС представляет собой архитектурный паттерн синтеза системы, описывающий макромодель топологии и взаимодействия подсистем ИТС, а также шаблон построения каждого модуля системы. Обобщенный паттерн ИТС составляет основу проектирования системы и используется на каждом этапе ее разработки: от проектирования концепции ИТС в целом до разработки отдельной подсистемы, решающей узкий круг задач. Обобщенный паттерн ИТС описывает требования и интерфейсы для подсистем, входящих в состав ИТС, обеспечивая их интеграцию и взаимное функционирование.
3. Паттерн «Абстрактная фабрика ИТС»
Задача. Создание семейства взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов.
Решение. Создать абстрактный (родовой) класс, в котором объявлен интерфейс для создания конкретных классов.
Пример А. Объектно-ориентированная модель класса «ИзмерениеИнтенсивности» движения транспортных потоков будет определяться структурой наследования и агрегации (рис. 3).
Построенная модель характеризуется наличием трех классов: дуга графа улично-дорожной сети (УДС), на которой производится измерение интенсивности движения, количество единиц транспортных средств определенного вида, время измерения интенсивности, включающее дату, время начала и окончания измерения. Поскольку разные измерения могут конструироваться на одних и тех же объектах классов «ПериодВремени», а объекты этих классов, в свою очередь, на одних и тех же объектах класса «ДатаВремя», конструирование осуществляется на основе паттерна с использованием разделяемых страт, определяющих общие части для различных результатов измерений «расположенных» на дуге графа.
Пример В. На рис. 4 представлен фрагмент таксономического дерева классов предметной области с регламентом отношений наследования и агрегирования. Абстрактными классами фабрики ИТС продекларированы классы: «Базовый объект ПрО», «Объект на карте», «Элемент УДС», «Объект на дороге», «Дорожно-транспортное происшествие», «Транспортный поток» и др.
4. Паттерн «Создатель»
Задача. В архитектуре «клиент-сервер» клиент не обладает достаточными знаниями о том, как создавать объекты на сервере. Клиент имеет только набор интерфейсов серверных объектов и ссылку на заместителя серверного объекта-одиночки (паттерны «Одиночка» и «Заместитель»).
Рисунок 3. Диаграмма класса «ИзмерениеИнтенсивности»
Решение. Наилучшим выходом в этой ситуации является применение паттерна «Создатель» [7]. Основное назначение – выявление объекта-создателя, который связан со всеми созданными им объектами. В качестве объекта-создателя в данном случае будет выступать объект-одиночка.
Пример А. Система интеллектуального анализа состояния пространственно-координированных объектов. Паттерн ИТС «Создатель анализатора пространственно-координированных данных» инкапсулирует методы создания объектов, алгоритмов и моделей, а также вспомогательных объектов. На рис. 5 изображена диаграмма классов, показывающая применение порождающего паттерна проектирования «Создатель».
Создателем в данном случае является класс «АнализаторДанных», который реализует интерфейс «IАнализаторДанных». Клиентский элемент управления «УровеньАварийностиЭлУпр» ссылается только на интерфейсы серверных классов. Клиент, используя интерфейс «IАнализаторДанных», создает на сервере единственный экземпляр класса «АнализаторДанных», и последующее создание объектов возлагается на него. Паттерн «Создатель анализатора пространственно-координированных данных» обеспечивает низкую степень связности.
Рисунок 4. Фрагмент диаграммы классов ПрО
Рисунок 5. Паттерн «Создатель анализатора пространственно-координированных данных»
Заключение
Проектируемая архитектура ИТС изобилует паттернами. Использование механизмов выявления типичных взаимодействий объектов системы делает ее архитектуру компактной, простой и понятной. Сообразное использование паттернов проектирования дает разработчику ИТС неоспоримые преимущества [4]. Формальные методы теории паттернов, применяемые на каждом уровне проектирования ИТС, отличаются высокой степенью гибкости и позволяют моделировать связи, соединения и преобразования подобия логических объектов реального мира.
Рецензенты:
Титов Борис Александрович, доктор технических наук, профессор, заведующий кафедрой организации и управления перевозками на транспорте, ФГБОУ ВПО «Самарский государственный аэрокосмический университет имени академика С.П. Королева (национальный исследовательский университет)», г.Самара.
Хайтбаев Валерий Абдурахманович, доктор экономических наук, профессор кафедры организации и управления перевозками на транспорте, ФГБОУ ВПО «Самарский государственный аэрокосмический университет имени академика С.П. Королева (национальный исследовательский университет)», г.Самара.