CC BY
296
УДК 004.4
Проектирование архитектуры программного комплекса для оценки факторов и управления показателями безопасности дорожного движения Designing the software suite architecture for monitoring, analysis, and forecasting of road
traffic safety
Овчаров Евгений Борисович,
заместитель генерального директора ЗАО «ПРОГНОЗ», доцент кафедры информационных систем и математических методов в экономике ПГНИУ, кандидат экономических наук
Добжанский Андрей Вячеславович, Заместитель руководителя направления решений для правоохранительных органов ЗАО
«ПРОГНОЗ» Некрасов Илья Борисович, ведущий специалист направления решений для правоохранительных органов ЗАО
«ПРОГНОЗ»
В статье рассматривается опыт по проектированию архитектуры программного комплекса, предназначенного для мониторинга, анализа и прогнозирования безопасности дорожного движения, а также оценки эффективности мер по повышению безопасности дорожного движения. Предлагаемые подходы позволят снизить нагрузку на сеть и оптимально масштабировать программный комплекс, решит проблемы с безопасностью и облегчит интеграцию.
Ключевые слова: разработка программных комплексов, функциональная
архитектура, технологическая архитектура.
Eugene B. Ovcharov
Deputy Chief Executive Officer, PROGNOZ JSC; Associate Professor of the Department of Information Systems and Mathematical Methods in Economics of the Perm State National
Research University; PhD in Economics Andrey V. Dobzhanskiy
Deputy Managing Director of Law Enforcement Agencies Solutions Division, PROGNOZ GSC
Ilya B. Nekrasov
Lead Specialist of Law Enforcement Agencies Solutions Division, PROGNOZ GSC
The article discusses an approach to designing the software suite architecture for monitoring, analysis, and forecasting of road traffic safety. Such software may be used to assess efficiency of measures undertaken to improve road traffic safety. This approach will help to reduce network load and make the software suite scalable; will solve tasks related to safety and ease the integration.
Key words: software suites development, functional architecture, technological
architecture.
Введение
Компания «Прогноз» разрабатывает программный комплекс для оценки факторов и управления показателями безопасности дорожного движения с использованием современных технологий обработки информации и методов математического моделирования. Работы выполняются при финансовой поддержке Минобрнауки России по государственному контракту от 24.10.2011 г. № 07.524.11.4010 в рамках ФЦП «Исследования и разработки по приоритетным направлениям развития научнотехнологического комплекса России на 2007-2013 годы»1.
Целью выполнения опытно-конструкторских работ является создание новых программных средств, обеспечивающих возможность мониторинга, анализа и прогнозирования безопасности дорожного движения, оценки эффективности мер по повышению безопасности дорожного движения.
1. Краткое описание задач программного комплекса
Комплекс предполагается применять для решения следующих задач:
1) формирование единого информационного ресурса, являющегося основой для решения задач мониторинга, анализа, моделирования и прогнозирования;
2) подготовка, ведение и предоставление нормативно-справочной информации о предметной области, в том числе о нормативных, паспортных и статистических данных;
3) оперативное получение информации в сфере безопасности дорожного движения;
4) формирование комплексной информации по основным характеристикам (условиям, причинам, факторам) дорожно-транспортных происшествий как в целом по стране, так и по субъектам РФ;
5) получение комплексной информации по административной практике подразделений дорожной полиции, оценка эффективности деятельности подразделений дорожной полиции;
6) обеспечение возможности оценки пороговых значений индикаторов ситуации в области обеспечения безопасности дорожного движения как с учетом оперативной и годовой информации, так и с помощью методов многомерного статистического анализа;
7) кластеризация и ранжирование административно-территориальных единиц страны по показателям безопасности дорожного движения, построение интегральных оценок уровня БДД в административно-территориальных единицах страны.
1 Федеральная целевая программа «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007—2013 годы» // http://fcpir.ru/catalog.aspx?CatalogId=259
2. Разработка архитектуры программного комплекса
Одним из важных этапов разработки программного обеспечения является проектирование. На этом этапе были проанализированы разные варианты архитектур и выделены наиболее оптимальные решения.
Архитектура - это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы2.
Система - это набор компонентов, объединенных для выполнения определенной функции или набора функций.
Компонентом называется модульная часть системы, которая инкапсулирует ее содержимое.
В архитектуре программного комплекса выделяется функциональная и технологическая архитектура.
2.1 Функциональная архитектура
Функциональная архитектура системы базы данных характеризует состав функциональных компонентов системы, их функции, взаимосвязи, средства взаимодействия друг с другом, а также роли функциональных компонентов в их взаимодействиях.
Общая архитектура представлена ниже (Рисунок 1). Функциональная архитектура приведена на Рисунок 2. Функциональная архитектура включает в себя подсистемы и программные компоненты.
IEEE 1471-2000™ Conceptual Framework for Architectural Description // http://www.iso-architecture.org/42010/cm/cm-1471-2000.html
Средства актуализации
Подсистема
администрирования
Министерства и ведомства, ействованные в предупреждении и ликвидации ЧС
Федеральное дорожное агентство
Рисунок 1. Общая архитектура ПК
Рисунок 2. Функциональная архитектура ПК Ключевым компонентом программного комплекса является централизованное хранилище данных (ЦХД), которое обеспечивает сбор и консолидацию информации. ЦХД
состоит из следующих компонент: оперативный склад данных (ОСД), сегмент накопления данных (СНД), Е^, витрины данных (ВД), инструменты OLAP.
Оперативный склад данных обеспечивает хранение первичной необработанной информации. Данные в нем размещаются в виде реляционных таблиц. ОСД наполняется средствами ЕТЬ, которые обеспечивают автоматическую и/или автоматизированную загрузку данных из разных источников (корпоративных баз данных, файлов данных и т.п.), а также данных, полученных с помощью ручного ввода. При наполнении ОСД производится проверка данных на основании минимального набора простых правил.
Сегмент накопления данных обеспечивает хранение очищенных данных. Очистка осуществляется посредством ЕТЬ-процедур, которые выгружают данные из ОСД, преобразовывают по заданным алгоритмам, производят выверку.
Витрины данных представляют собой организованные в виде многомерных структур (кубов) данные. Они являются тематическим срезом сегмента накопления данных. Витрина наполняется в соответствии с определенными правилами средствами ЕТЬ.
Такая сложная структура ЦХД обеспечивает возможность работы с разнообразными источниками информации, проводить многоступенчатую фильтрацию данных.
Подсистема нормативно-справочной информации (НСИ) содержит справочную информацию программного комплекса, необходимую для решения аналитических задач обеспечения безопасности дорожного движения. Справочники программного комплекса едины для всех компонент и используются в ЦХД, подсистемах мониторинга, моделирования и прогнозирования, аналитической подсистеме, подсистеме визуализации.
Подсистема НСИ включает в свой состав программную компоненту «База данных НСИ», которая обеспечивает хранение элементов справочников с поддержкой атрибутного состава и иерархии элементов, а также программную компоненту «Измерения», которая обеспечивает возможность формирования иерархического представления справочников с поддержкой атрибутного описания элементов.
Разделение основного пользовательского функционала на три подсистемы вызвано существенными различиями в подходах к обработке данных. Подсистема мониторинга предназначена для анализа оперативных данных за месяц, в течение года. Аналитическая подсистема предназначена для анализа данных в разрезе нескольких лет и содержит больший объем разнообразных аналитических подходов. Подсистема мониторинга содержит разнообразные модели для проведения многовариантных расчетов и поиска оптимальных мер по повышению уровня БДД. Несмотря на все различия, внутренняя архитектура и функционирование подсистем мониторинга, аналитической и моделирования схожи. Каждая из подсистем (аналитическая, мониторинга, моделирования и прогнозирования) содержит в своем составе промежуточную
компоненту, обеспечивающую ее функциональность, и компоненту взаимодействия с
ЦХД.
При помощи интерфейса компоненты, обеспечивающей функциональность, пользователь задает параметры для получения информации.
Компонента формирует запрос на основе указанных пользователем параметров и передает его компоненте взаимодействия с ЦХД. Программная компонента взаимодействия с ЦХД получает от компоненты, обеспечивающей функциональность подсистемы, запрос на получение данных из ЦХД. Запрос направляется в подсистему ЦХД, в компоненту «Витрина данных» или «Сегмент накопления данных», в зависимости от запрашиваемой информации. Полученный ответ от подсистемы ЦХД направляется в компоненту, обеспечивающую функциональность, для предоставления результирующей информации пользователю. С помощью промежуточной компоненты формируются тематические отчеты.
Подсистема визуализации может представлять данные ЦХД в виде элемента деловой графики. При помощи интерфейса компонент «Регламентные отчеты» или «Аналитические панели» пользователь задает параметры для получения информации. Соответствующая компонента преобразует эти параметры в запрос на получение данных и передает его в программную компоненту взаимодействия с ЦХД. Программная компонента взаимодействия с ЦХД получает от компоненты «Регламентные отчеты» или «Аналитические панели» запрос на получение данных из ЦХД. Запрос направляется в подсистему ЦХД, в компоненту «ВД» или «СД», в зависимости от запрашиваемой информации. Полученный ответ от подсистемы ЦХД направляется в компоненту, вызвавшую запрос, для предоставления результирующей информации пользователю. Получив в ответ результаты запроса, компонента «Регламентные отчеты» или «Аналитические панели» предоставляет результаты расчета пользователю. Пользователь настраивает в компоненте «Аналитические панели» визуализацию полученной информации при помощи блоков представления информации путем указания вида представления данных (таблица, график, карта), расположения блока на странице, определения состава блоков на странице. Подсистема визуализации дает возможность пользователю не ограничиваться начальным набором отчетов, а настраивать отображение работы комплекса под свои потребности.
Все компоненты программного комплекса взаимодействуют с подсистемой администрирования, которая регламентирует доступ к данным, разграничивает доступ к объектам и функциям комплекса. Ядром подсистемы является Менеджер безопасности, обеспечивающий аутентификацию и авторизацию пользователя. Все значимые события ПК должны фиксироваться в Журнале.
Такая архитектура программного комплекса позволяет обеспечить выполнение всех его функций, гибкость в использовании и разработке.
2.2 Технологическая архитектура На сегодняшний день существуют два способа технологической организации программных комплексов: двухзвенная и трехзвенная архитектуры.
Двухзвенная (двухуровневая) архитектура В двухзвенной архитектуре всего два типа «звеньев»: сервер баз данных, на котором находятся БД и СУБД, и рабочие станции, на которых находятся клиентские приложения. Клиентские приложения обращаются к СУБД напрямую (
Рисунок 3).
Первый уровень - клиентские компьютеры с прикладными программами, с помощью которых пользователи обращаются по сети к базе данных. Второй уровень -сервер с размещенной на нем базой данных.
Двухуровневая архитектура получила распространение с начала 1990-х годов на фоне роста рынка персональных компьютеров и снижения спроса на мэйнфреймы.
Благодаря двухуровневой архитектуре снижается нагрузка на информационную сеть, поскольку передаются только запросы и ответы на них. Другой важнейший принцип клиент-серверной архитектуры заключается в том, что информация вводится в систему только один раз. Благодаря этому отпадает необходимость дублирования одних и тех же данных работниками различных подразделений предприятия, что резко снижает риск ошибок в информационной системе.
Сервер
Рисунок 3. Двухзвенная архитектура
Плюсы:
совместный доступ к данным; относительная экономия на оборудовании; возможность масштабирования.
Минусы:
проблемы с безопасностью; сложность интеграции;
доступно только вертикальное масштабирование.
Трехзвенная (трехуровневая) архитектура Трёхзвенная архитектура предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных (
Рисунок 4).
Рисунок 4. Трехзвенная архитектура
Клиент - это интерфейсный компонент, который представляет первый уровень. Он не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности).
Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики.
Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД.
Трехуровневая архитектура была впервые реализована в 1995 году в продуктах корпоративного управления семейства Solstice компании Sun Microsystems.
В отличие от традиционных двухуровневых систем (клиентские компьютеры -сервер с базой данных) управленческие комплексы, основанные на трехуровневой архитектуре, включают в себя также сервер приложений. На нем размещается бизнес-логика и выполняется вся обработка данных. А компьютеры пользователей предоставляют возможность посылать запросы и получать обработанную информацию, то есть работают, по сути, в режиме «тонкого клиента», терминала.
Такая архитектура позволяет снизить нагрузку на сеть, а в качестве автоматизированных рабочих мест использовать маломощные компьютеры (в двухуровневой архитектуре расчеты ведутся на клиентских компьютерах, поэтому системные требования к ним достаточно высоки).
Плюсы:
- безопасность;
- интегрируемость;
- масштабируемость.
Минусы:
- дополнительные расходы на администрирование;
- низкая «мобильность».
Для объединения достоинств обоих подходов разрабатываемый программный комплекс содержит элементы, как клиент-серверной архитектуры, так и трехзвенной (См. Рисунок 5).
Рисунок 5. Общая техническая схема разрабатываемого программного комплекса
Рабочие места с инструментами моделирования (продвинутые пользователи) и рабочие места администратора функционируют в связке с сервером базы данных. В качестве рабочих мест обычных пользователей возможно использование более простых компьютеров. Количество рабочих мест продвинутых пользователей и администраторов невелико, следовательно, имеется возможность экономии при внедрении.
Кроме этого, такой подход позволит снизить нагрузку на сеть и оптимально масштабировать программный комплекс, решит проблемы с безопасностью и облегчит интеграцию.
Заключение
Проектирование архитектуры при разработке программного обеспечения имеет первоочередное значение - как для технического, так и маркетингового успеха проекта.
Разрабатываемый программный комплекс призван восполнить указанный пробел в классе систем мониторинга, анализа, моделирования и прогнозирования дорожно-
транспортных происшествий, анализа последствий и статистической оценки результатов ДТП.
За счет интеграции в рамках одного программного комплекса большого количества функциональных возможностей и инструментов будут достигаться лучшие функциональные и потребительские показатели. Структура ЦХД предоставляет возможность работы с разнообразными источниками информации, обеспечивает многоступенчатую фильтрацию данных. Разделение основного пользовательского функционала на три подсистемы вызвано существенными различиями в подходах к обработке данных. Несмотря на это, внутренняя архитектура и функционирование подсистем мониторинга, аналитической и моделирования схожи. Подсистема визуализации дает возможность пользователю не ограничиваться начальным набором отчетов, а настраивать отображение работы комплекса под свои потребности.
В качестве технологической архитектуры выбрана комбинация из традиционных трехзвенной и двухзвенной архитектуры. Такой подход позволит пользоваться преимуществами обоих подходов. Смешанная технологическая архитектура обеспечит безопасность и облегчит внедрение программного комплекса.
Литература
1. Федеральная целевая программа «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007— 2013 годы» [Электронный ресурс]// [Сайт] [Дата публикации: 2007]. URL: http://fcpir.m/catalog.aspx?CatalogId=259 (Дата обращения: 01.07.2012).
2. IEEE 1471-2000™ Conceptual Framework for Architectural Description [Электронный ресурс]// [Сайт] [Дата публикации: 2006]. URL: http://www.iso-architecture.org/42010/cm/cm-1471-2000.html (Дата обращения: 01.07.2012).
