Информационно-компьютерная система службы видеонаблюдения

Выполнение CRUD операций с атрибутами категорий системы. Менеджер видеоархива имеет возможность добавлять новые атрибуты к существующим категориям системы, а также редактировать старые.

Выполнение CRUD операций с атрибутами наблюдательных пунктов. Менеджер видеоархива имеет возможность добавлять, удалять и редактировать атрибуты наблюдательных пунктов.

Выполнение CRUD операций над сущностями «Part» представляющими файл видеоархива.

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

2.1.5 Варианты использования системы для сущности «Администратор»

Диаграмма вариантов использования для актера «Администратор» системы представлена на рисунке 2.5.

Рисунок 2.5 - Диаграмма вариантов использования для актера «Администратор»

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

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

Выполнение CRUD операций над наблюдательными пунктами. Администратор системы имеет возможность добавлять, удалять и редактировать информацию о наблюдательных пунктах.

Выполнение CRUD операций над списком типов атрибутов. Администратор системы имеет возможность добавлять, удалять и редактировать типы атрибутов.

Выполнение CRUD операций над списком событий. Администратор системы имеет возможность добавлять, удалять и редактировать список событий. видеонаблюдение информационный компьютерный интерфейс

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

Выполнение CRUD операций над учетными записями пользователей. Администратор системы имеет возможность добавлять, удалять и редактировать учетные записи пользователей системы.

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

2.1.6 Варианты использования системы для сущности «Мобильный клиент»

Диаграмма вариантов использования для актера «Мобильный клиент» представлена на рисунке 2.6.

Рисунок 2.6 - Диаграмма вариантов использования для актера «Мобильный клиент»

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

2.2 Выбор технологий и инструментальных средств разработки

В данном пункте проводится выбор языка программирования, сред разработки IDE, сборщиков проектов, серверов приложений и сервлет-контейнеров, хранилищ данных и средств интеграции, средств для реализации бизнес-логики, слоя представления, безопасности.

2.2.1 Выбор языка реализации

Существуют клиентские и серверные языки web-программирования. Клиентские языки используются для написания программ, выполняемых на стороне клиента (браузер), а серверные - для программ, выполняемых на сервере.

Среди клиентских языков программирования стоит выделить JavaScript, которые, также как и HTML, лежит в основе многих веб-технологий.

Другие популярные клиентские языки, а точнее фреймворки - это Adobe Flash (язык Action Script) и Silver Light (любые .NET языки). Adobe Flash применяется веб-мастерами довольно долгое время. Основное применение этой технологии - интерактивные сайты и сервисы, онлайновые игры, мультимедийный контент, реклама. Silver Light - это новая технология, разработанная компанией Microsoft и позиционируемая как замена Adobe Flash. Не смотря на то, что с помощью Adobe Flash и Silver Light можно построить полностью весь сайт, этого делать не следует, потому, что современные поисковые системы не могут индексировать ни Adobe Flash ни Silver Light.

Серверные языки программирования могут быть условно разделены по операционной системе, на которой они работают, это операционные системы семейства Windows и Unix. Это разделение в некоторой степени условно, т.к. практически все популярные языки и фреймворки разработаны для обоих ОС и тем не менее, они редко используются на не родных ОС.

Если говорить про ОС Windows, то здесь лучше всего и быстрее всего работает технология ASP .NET, разработанная компанией Microsoft. С помощью ASP .NET можно создавать сайты любого уровня сложности - от самых простых, состоящих из нескольких страниц, до очень сложных, обрабатывающих миллионы запросов в день. Сайты Microsoft, написанные на ASP .NET, являются одними из самых посещаемых в Интернет. Здесь основным языком веб-программирования служит C#. Основной недостаток этой технологии - меньшее, по сравнению с Unix, количество дешевых хостингов и необходимость покупки серверной лицензии, в случае с выделенным хостингом.

Самым популярным языком веб-программирования является, безусловно, PHP. Его основными преимуществами являются: простой синтаксис, высокое быстродействие, поддержка большинством хостингов. К недостаткам этого языка можно отнести отсутствие JIT-компиляции, несовершенной и устаревшей моделью ООП, нестрогую типизацию.

Другой популярный язык веб-программирования на платформе Unix - язык Perl. Он имеет сложный и запутанный синтаксис и никогда не предназначался для веб, но тем не менее зачастую используется для создания небольших проектов.

В последние несколько лет высокую популярность приобрел язык Ruby и, в частности, фреймворк Ruby on Rails. С его помощью можно очень быстро создать сайт с требуемой функциональностью. Одним из существенных недостатков Ruby является низкое быстродействие.

Наиболее подходящим языком веб-программирования для реализации поставленной задачи является технология Java, так как она является бесплатным кроссплатформенным языком программирования, для которого существует множество различных бесплатных реализаций различных фреймворков и технологий для веб-программирования.

2.2.2 Среды разработки IDE

Для проектирования программных комплексов необходимо наличие интегрированной среды(IDE). На данный момент существует широкий выбор средств для разработки программ. Для решения поставленных целей определенных в техническом задании были выбрана такая среда разработки как Eclipse.

Eclipse является полноценной Java IDE, нацеленной на групповую разработку: среда интегрирована с системами управления версиями -CVS в основной поставке, для других систем (например, Subversion, MS SourceSafe) существуют плагины. В силу бесплатности и высокого качества, Eclipse во многих организациях является корпоративным стандартом для разработки приложений. Также Eclipse включает поддержку технологии JAX-WS и позволяет разрабатывать приложения для медиа флэш сервера Red5.

Основной причиной выбора данной среды разработки является её бесплатность, качество и наличие поддержки флэш серверов Red5, а также поддержка всех основных технологий применяемых при разработке данной системы, а именно: JPA, JSF и JAX-WS.

2.2.3 Серверы и контейнер сервлетов

Для выполнения приложений необходимо наличие сервера, выполняющего их. При выборе сервера приложений необходимо, что бы он реализовывал эффективное исполнение процедур (программ, механических операций, скриптов) которые поддерживают построение приложений. Также необходимо, чтобы сервер приложений действовал как набор компонент доступных разработчику программного обеспечения через API (интерфейс прикладного программирования) определенный самой платформой. В качестве сервера приложений был выбран следующий продукт от Apache:

Tomcat - программа-контейнер сервлетов, написанная на языке Java и реализующая спецификацию сервлетов и спецификацию Java Server Pages (JSP), которые являются стандартами для разработки веб-приложений на языке Java. Tomcat позволяет запускать веб-приложения, содержит ряд программ для автоконфигурирования. Tomcat используется в качестве самостоятельного веб-сервера, в качестве сервера контента в сочетании с веб-сервером Apache HTTP Server.

Для публикации видеопотоков необходим флэш медиа сервер. Который будет играть роль контейнера медиа приложений. В качестве контейнера медиа приложений был выбран Red5 Media Server.

Red5 Media Server - это RTMP медиасервер с открытым исходным кодом, написанный на Java. Red5 включает в себя поддержку последних многопользовательских API, таких как: NetConnection, NetStream и SharedObject's обеспечивающих мощную RTMP/Servlet реализацию. В добавок к поддержке RTMP протокола, сервер приложений содержит в себе встроенный сервлет контейнер для JEE Web приложений Tomcat Servlet container. Основной причиной выбора данного сервера является его бесплатность, большая база наработок и примеров, позволяющих без особых затрат начать разработку.

2.2.4 Хранилище данных и средства интеграции

Для хранения и обеспечения целостности пользовательских и других данных необходима система управления базами данных. В качестве системы управления базами данных необходимо выбрать продукт, который представляет собой совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных. Для реализации данных требований было выбрано следующее программное обеспечение:

PostgreSQL - свободная объектно-реляционная система управления базами данных (СУБД), работающая как клиент-серверная система. Основываясь на базовых понятиях реляционных БД, PostgreSQL поддерживает и ряд "объектных" операций. PostgreSQL соответствует базовой спецификации SQL99 и поддерживает большое число возможностей, описанных стандартом SQL92;

Основной причиной выбора банной СУБД является поддержка рекурсивных запросов, которые существенно ускорят процесс прохода по иерархической структуре данных.

Для взаимосвязи с различными реляционными хранилищами данных необходимо выбрать средство интеграции. При выборе средства интеграции необходимо, что бы она поддерживала возможность связи базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». Существуют как коммерческие, так и свободные реализации этой технологии. Для решения данной проблемы был выбран программный продукт от JBoss:

Hibernate- библиотека для языка программирования Java, предназначенная для решения задач объектно-реляционного проецирования (object-relational mapping - ORM). Она представляет собой свободное программное обеспечение с открытым исходным кодом (open source), распространяемое на условиях GNU Lesser General Public License. Данная библиотека предоставляет лёгкий в использовании каркас (фреймворк) для отображения объектно-ориентированной модели данных в традиционные реляционные базы данных.

Для взаимодействия подсистем друг с другом выбрана технология веб-сервисов. Стандартом реализации веб-сервисов в Java является технология JAX-WS.

JAX-WS - это технология, разработанная для упрощения создания Web-сервисов и клиентов Web-сервисов на языке Java. Она предоставляет полный стек Web-сервисов, облегчающий разработку и развертывание Web-сервисов. JAX-WS поддерживает WS-I Basic Profile 1.1. Это гарантирует, что Web-сервисы, разработанные с использованием стека JAX-WS, могут потребляться любыми клиентами, разработанными на любом языке программирования и удовлетворяющими стандарту WS-I Basic Profile. JAX-WS также включает в себя JAXB (Java Architecture for XML Binding) и SAAJ (SOAP with Attachments API for Java).

Более того, JAX-WS ускоряет разработку Web-сервисов, предоставляя библиотеку аннотаций для преобразования POJO-классов (plain old Java object - традиционные Java-объекты) в Web-сервисы. Она также определяет детализированное отображение сервисов, определенных на языке WSDL (Web Services Description Language), в Java-классы, реализующие эти сервисы. Все сложные типы, определенные в WSDL, отображаются в Java-классы согласно отображению, определенному спецификацией JAXB. JAX-WS ранее поставлялась с платформой Java Platform, Enterprise Edition (Java EE) 5. Спецификация JAX-WS 2.0 разрабатывается под эгидой JSR 224 Java Community Process (JCP).

2.2.5 Инструментальные средства для проектирования слоя представления

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

Java Server Faces (JSF) - это технология обеспечивающая объектную модель построения веб приложений, предоставляющая набор визуальных классов для построения веб интерфейсов, а также утилиты для управления инфраструктурой всего приложения.

Для реализации слоя отображения будет использоваться JSF в совокупности с Facelets и набором компонентов Richfaces. Можно было бы использовать и другие наборы компонентов, например, Icefaces, но особых различий между ними нет, а Richfaces подробно документирован, и имеет множество тестовых примеров работы всех компонентов.

JSF представляет собой каркас разработки приложений, предоставляющий набор стандартных графических компонентов для создания интерфейсов. Но при этом JSF ориентирован на создание Web-приложений и имеет следующие преимущества:

четкое разделение бизнес-логики и интерфейса;

управление сохраняемостью на уровне компонент;

простая работа с событиями на стороне сервера;

использование простых и знакомых концепций, таких как графический интерфейс или слои в Web-приложении;

доступность нескольких реализаций от различных компаний-разработчиков;

широкая поддержка со стороны интегрированных средств разработки (IDE).

К недостаткам JSF можно отнести обработку графического интерфейса на стороне сервера, что приводит к увеличению нагрузки, как на сервер, так и на сеть, но в данном случае можно уменьшить нагрузку на сервер за счет применения Ajax компонентов из набора Richfaces.

2.2.6 Инструментальные средства для обеспечения безопасности

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

LDAP (англ. Lightweight Directory Access Protocol - «облегчённый протокол доступа к каталогам») - это сетевой протокол для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP - относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей.

Протокол LDAP был разработан исследователями из Мичиганского университета для упрощения доступа к сервисам каталогов X.500. Стандарт CCITT X.500 описывает базовую структуру и функциональную модель службы каталогов, но он очень сложен и громоздок, а его реализация требует использования стека протоколов OSI.

2.2.7 Дополнительные программные средства, необходимые для разработки проекта

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

Xuggler framework - предоставляет лёгкий способ раскодировать, модифицировать и перекодировать любой медиафайл (или поток) из Java.

Xuggler это свободно распространяемая open-source библиотека для Java разработчиков, которая может быть использована для распаковки, обработки, сжатия видео или видео потоков в реальном режиме времени. Xuggler использует такой мощный видео обработчик как FFmpeg, Java используется как обвертка над ним.

FFmpeg это полностью кроссплатформенное решение для записи, конвертирования, как для потокового видео, так и для потокового аудио при этом поддерживая большое число форматов.

Проект содержит высокоуровневое API, что позволяет осуществлять довольно сложные операции над различными видео и аудио данными. Также, Xuggle предоставляет возможность получить стандартный BufferedImage, который является двумерной RGB матрицей, над которой можно производить любые преобразования и формировать новый кадр.

JUnit - библиотека для тестирования программного обеспечения на языке Java. JUnit принадлежит семье фреймворков xUnit для разных языков программирования, берущей начало в SUnit для Smalltalk. JUnit породил экосистему расширений - JMock, EasyMock, DbUnit, HttpUnit, Selenium и т.д. Используется для тестирования приложения и его компонентов.

2.3 Разработка архитектуры системы

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

а) Подсистема публикации потока «Media Gateway» - основной задачей подсистемы публикация потока захватываемого с IP камер. Данная операция необходима для более гибкого управления потоками.

б) Подсистема записи и хранения видеоархива «Media Server» - данная подсистема выполняет задачу хранилища видео файлов и информации о предприятии, также осуществляет захват потоков публикуемых подсистемой «Media Gateway». Данная подсистема является централизованным хранилищем информации о предприятии, работниках, структуре предприятия, журнале событий и предоставляет сервисы для работы с информацией. Также, выполняет централизованное управление и регистрацию активных мобильных клиентов.

в) Подсистема отображения «Video portal» - основной задачей данной подсистемы является взаимодействие с пользователем, отображение видеоинформации с архива и в реальном режиме времени с IP камер.

г) Подсистема мобильного клиента «Mobile Client» - основная задача подсистемы отображение потока видеоданных. Данная подсистема управляется централизованно подсистемой «Media Server». Также, данной подсистеме при запуске необходимо зарегистрироваться на «Media Server».

Каждая подсистема размещается на отдельном сервере, так как обработка видеопотоков является ресурсоемкой задачей. Таким образом, необходимо отделить сервер веб-приложений, сервер выполняющий роль шлюза видеопотоков, принимающего видеопотоки от источников и транслирующего их во внутреннюю среду системы, и медиа сервер выполняющий непосредственную обработку видео. Также, данное разделение позволит в будущем применять технологию балансировки нагрузки. В системе также существуют сервер LDAP и сервер баз данных PostgreSQL.

На рисунке 2.7 представлена общая архитектура ИКС службы видеонаблюдения.



Рисунок 2.7 - Общая архитектура ИКС службы видеонаблюдения

2.4 Разработка структуры системы

В результате разработки архитектуры системы было выделено четыре основных программных подсистемы: подсистема отображения «Video Portal», подсистема «Media Server», подсистема «Media Gateway» и подсистема мобильного клиента «Mobile Client». Каждая подсистема взаимодействует между собой с помощью протокола SOAP, так как данный протокол является де-факто при реализации взаимодействия между основной логикой и подсистемой отображения. Применение данного стандарта позволит минимизировать зависимости между подсистемами и интегрировать данную систему с другими. Общая структура системы представлена на рисунке 2.8. Далее рассматривается внутренняя структура каждой подсистемы.



Рисунок 2.8 - Общая структура системы

2.4.1 Подсистема публикации потоков «Media Gateway»

Данная подсистема играет роль централизованной точки доступа к видеопотокам. Так как доступ к видеопотокам должен осуществляться с нескольких точек одновременно, а именно с «Media Server», «Video Portal» и «Mobile Client», появляется необходимость выделения системы, осуществляющую широковещательную публикацию видеопотока.

На рисунке 2.9 показана структура подсистемы «Media Gateway».



Рисунок 2.9 - Структура подсистемы «Media Gateway»

Компонент начальной инициализации - необходим для инициализации подсистемы. Данный компонент загружает настройки необходимые для захвата видеопотока с камер и публикации их во внутреннюю среду системы, конфигурационные данные представляет подсистема «Media Server». Компонент выполняется при старте приложения.

Компонент «Хранилище конфигурации» играет роль хранилища конфигурационных данных подсистемы «Media Gateway». Инициализируется при старте приложения.

Компонент «Обработчик подключений» выполняет функцию обработчика событий со стороны клиентов подсистемы. Обрабатывает события подключения клиентов, отключения, запросов на получение потока или публикацию потока.

Компонент «Контроллер безопасности проигрывания» отвечает за функции аутентификации и авторизации пользователя, который пытается подключиться к потоку. Данный компонент будет взаимодействовать с «Компонентом обеспечения ААА», от которого и будет получать информацию касательную легальности и прав пользователя в системе.

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

Компонент «Поток преобразования видеоданных» является отдельным потоком, выполняющимся параллельно по отношению к основной программе. В системе будет создан набор экземпляров данного компонента, по одному на каждый обрабатываемый поток. Данный компонент и является механизмом, обрабатывающим потоки от IP камер.

Компонент обеспечения ААА обеспечивает в системе аутентификацию и авторизацию. Данный компонент определяет легальность и права пользователя в системе.

2.4.2 Подсистема записи и хранения видеоархива «Media Server»

Данная подсистема играет роль хранилища видеофайлов и информации о предприятии, осуществляет захват потоков публикуемых подсистемой «Media Gateway». Данная подсистема является централизированным хранилищем информации о предприятии, работниках, структуре предприятия, журнале событий и предоставляет сервисы для работы с информацией. На рисунке 2.10 представлена структура подсистемы «Media Server».

Рисунок 2.10 - Структура подсистемы «Media Server»

Компонент захвата видеопотока выполняет функцию подключения к подсистеме «Media Gateway», захвата видеопотока. Для записи видеоинформации в файл использует компонент декодирования и записи в архив.

Компонент доступа к БД компонент предоставляет доступ к хранилищу информации о инфраструктуре предприятия.

Компонент «Хранилище информации об инфраструктуре предприятия» является хранилищем основных сущностей системы.

Компонент «Хранилище видеоданных» играет роль хранилища видеоархива, записанного с видеокамер предприятия.

Компонент декодирования потока и записи в архив выполняет функцию преобразования видеопотока в формат, который можно сохранить в файл. Взаимодействует с компонентом доступа к БД, так как необходимо вести учет сохраненных видеофайлов, и с компонентом «Хранилище видеоданных» куда и сохраняются видеофайлы.

Компонент «Хранилище видеоданных» обеспечивает хранение видеофайлов, представляющих сохраненный поток.

Компонент «Публикация видеофайлов и потоков» выполняет функцию публикации видеофайлов из архива, данная функция используется подсистемой «Video portal». Также предоставляет данные об активных потоках для внешних подсистем, таких как «Video portal» и «Mobile Client».

Компонент управления мобильным клиентом предоставляет возможность указания, какой именно видеопоток просматривать мобильному клиенту на данный момент.

Компонент регистрации активных мобильных клиентов необходим для оповещения подсистемы «Media Server» обо всех активных на данный момент мобильных клиентах.

Компонент обеспечения ААА обеспечивает в системе аутентификацию и авторизацию. Данный компонент определяет легальность и права пользователя в системе.

2.4.3 Подсистема отображения «Video portal»

Основной задачей данной подсистемы является взаимодействие с пользователем, отображение видеоинформации с архива и в реальном режиме времени с IP камер. Данная подсистема предоставляет пользователю графический интерфейс, через который пользователь производит взаимодействие с системой. Данная подсистема взаимодействует с подсистемой «Media Server» через веб-сервисы по средствам протокола SOAP. С помощь данного вида взаимодействия минимизируются зависимости между основной логикой системы и отображением. Это позволяет при необходимости использовать различные реализации отображения, а также производить интеграцию с другими системами. На рисунке 2.11 представлена структура подсистемы отображения.

Рисунок 2.11 - Структура подсистемы отображения

Компонент обеспечения ААА обеспечивает в системе аутентификацию и авторизацию. Данный компонент определяет легальность и права пользователя в системе.

Компонент приема потокового видео необходим для подключения к подсистеме «Media Gateway» и приема опубликованного видеопотока.

Компонент приема видео с архива необходим для подключения к подсистеме «Media Server» и скачивания видеофайлов с видеоархива.

Компонент взаимодействия с Media Server является связующим звеном с подсистемой «Media Server».

2.4.4 Подсистема «Mobile Client»

Основной задачей данной подсистемы является взаимодействие с мобильным клиентом. Подсистема позволяет захватывать видеопоток публикуемый подсистемой «Media Gateway» и показывает его пользователю. На рисунке 2.12 показана структура подсистемы «Mobile Client».



Рисунок 2.12 - Структура подсистемы «Mobile Client»

Компонент приема потокового видео необходим для подключения к подсистеме «Media Gateway» и приема опубликованного видеопотока.

Компонент взаимодействия с Media Server является связующим звеном с подсистемой «Media Server».

2.4.5 Разработка взаимодействия подсистем

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

Для передачи потокового видео между подсистемами используется протокол RTMP. Причиной выбора данного протокола является наличие готовой свободной реализации сервера медиа-приложений Red5, который полностью поддерживает и ориентирован на данный протокол. А также, наличие свободно распространяемого фреймворка Xuggler framework, который позволяет обрабатывать взаимодействовать с протоколом RTMP.

2.6 Разработка классов сущностей системы

В результате выполнения объектно-ориентированного анализа были выделены следующие классы, представляющие собой сущности системы. На рисунке 2.13 представлена диаграмма основных сущностей системы.

Рисунок 2.13 - Диаграмма классов основных сущностей системы

Класс Category предназначенный для хранения абстрактной сущности представляющей категорию. Данный класс содержит ссылку такого же типа, как и сам класс и является ссылкой на родителя, таким образом, достигается древовидная структура, с помощью которой можно описать бизнес структуру предприятия. Также класс содержит данные о названии, описании сущности и ссылку на коллекцию атрибутов, которые более подробно описывают экземпляр класса, ссылку на коллекцию наблюдательных пунктов. Листинг класса представлен в листинге 2.1.

- id - код категории

- name - название категории

- topCategory - ссылка на родительскую категорию

- subCategories - ссылка на коллекцию подчиненных категорий

- listAttributes - ссылка на коллекцию атрибутов

- checkpost - ссылка на наблюдательный пункт

- description - описание категории

- listEmployee - ссылка на список сотрудников

Листинг 2.1- Листинг класса сущности «Категория»

@Entity

@Table(name = "CATEGORIES")

@NamedQueries({

@NamedQuery(name = "Category.getAll", query = "select c from Category c")

})

public class Category implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String description;

private String name;

@ManyToOne(fetch = FetchType.EAGER)

private Category topCategory;

@OneToMany(fetch = FetchType.LAZY)

private List<Category> subCategories;

@OneToMany(fetch = FetchType.EAGER)

private List<Attribute> listAttributes;

@OneToMany(fetch = FetchType.EAGER)

private List<Checkpost> listCheckposts;

@OneToMany(fetch = FetchType.LAZY)

private List<Employee> listEmployee;

…

}

Класс Attribute используется для хранения атрибутов описывающих категории и пункты наблюдения. Содержит поля названия атрибута, значения атрибута и ссылку на объект представляющий данные о типе атрибута, данная ссылка необходима для правильной интерпретации значения атрибута. Текст класса представлен в листинге 2.2.

- id - код атрибута

- name - название атрибута

- value - значение атрибута

- type - ссылка на тип атрибута

- category - ссылка на категорию

- checkpost - ссылка на наблюдательный пункт

Листинг 2.2 - Листинг класса сущности «Атрибут»

@Entity

@Table(name = "ATTRIBUTES")

@NamedQueries({

@NamedQuery(name = "Attribute.getByCategoryId", query = "select a from Attribute a where a.category.id = :id"),

@NamedQuery(name = "Attribute.getByCheckpostId", query = "select a from Attribute a where a.checkpost.id = :id")

})

public class Attribute implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String name;

private String value;

@ManyToOne(fetch = FetchType.EAGER)

private AttrType type;

@ManyToOne(fetch = FetchType.LAZY)

private Category category;

@ManyToOne(fetch = FetchType.LAZY)

private Checkpost checkpost;

…

}

Класс AttrType используется для хранения информации о типе атрибута. Содержит поля названия типа и сам тип атрибута. Данная информация необходима для правильной интерпретации значения атрибута. Текст класса приведен в листинге 2.3.

- id - код типа

- title - название типа

- dataType - тип данных

- listAttributes - ссылка на коллекцию атрибутов

Листинг 2.3 - Листинг класса сущности «Тип атрибута»

@Entity

@Table(name = "ATTR_TYPES")

@NamedQueries({

@NamedQuery(name = "AttrType.getByTitle", query = "select at from AttrType at where at.title = :title")

})

public class AttrType implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String title;

private String dataType;

@OneToMany(fetch = FetchType.LAZY)

private List<Attribute> listAttributes;

…

}

Класс Checkpost используется для хранения информации о наблюдательных пунктах. Класс содержит поля IP адреса, описания, ссылку на категорию, ссылку на коллекцию атрибутов, описывающих более подробно наблюдательный пункт и ссылку на коллекцию SDP атрибутов, которые представляют настройки кодека для захвата и ретрансляции RTP потока. Текст класса представлен в листинге 2.4.

- id - код наблюдательного пункта

- ip - IP адрес наблюдательного пункта

- description - описание наблюдательного пункта

- listSDPAttributes - ссылка на коллекцию SDP атрибутов

- topCategory - ссылка на категорию

- listAttributes - ссылка на коллекцию атрибутов

- listFixations - ссылка на коллекцию событий распознавания образов

- listParts - ссылка на коллекцию частей сохраненного потока

Листинг 2.4 - Листинг класса сущности «Наблюдательный пункт»

@Entity

@Table(name = "CHECKPOSTS")

@NamedQueries({

@NamedQuery(name = "Checkpost.getByCategoryId", query = "select ch from Checkpost ch where ch.topCategory.id = :id")

})

public class Checkpost implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String ip;

private String description;

@OneToMany(fetch = FetchType.EAGER)

private List<SDPAttribute> listSDPAttributes;

@ManyToOne(fetch = FetchType.EAGER)

private Category topCategory;

@OneToMany(fetch = FetchType.EAGER)

private List<Attribute> listAttributes;

@OneToMany(fetch = FetchType.LAZY)

private List<Fixation> listFixations;

@OneToMany(fetch = FetchType.LAZY)

private List<Part> listParts;

…

}

Класс Employee используется для хранения информации о сотрудниках предприятия. К экземплярам данного класса будут привязываться события распознавания образов. Содержит поля имени, отчества, фамилии, даты рождения, должность, адрес проживания. Текст класса представлен в листинге 2.5.

- id - код сотрудника

- name - имя сотрудника

- surname - фамилия

- patronymic - отчество

- email - адрес электронной почты

- birthday - дата рождения

- post - должность

- address - адрес проживания

- listFixations - ссылка на коллекцию фиксаций данного сотрудника

- category - ссылка на категорию

Листинг 2.5 - Листинг класса сущности «Сотрудник»

@Entity

@Table(name= "EMPLOYEE")

@NamedQueries({

@NamedQuery(name = "Employee.getByCategoryId", query = "select e from Employee e where e.category.id = :id"),

@NamedQuery(name = "Employee.getAll", query = "select e from Employee e")

})

public class Employee implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String name;

private String surname;

private String patronymic;

private String email;

@Temporal(TemporalType.DATE)

private Calendar birthday;

private String post;

private String address;

@OneToMany(fetch = FetchType.LAZY)

private List<Fixation> listFixations;

@ManyToOne(fetch = FetchType.EAGER)

private Category category;

…

}

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

- id - код записи о фиксировании

- time - время и дата фиксации

- employee - ссылка на зафиксированного сотрудника

- checkpost - ссылка на наблюдательный пункт

Листинг 2.6 - Листинг класса сущности «Фиксация»

@Entity

@Table(name = "FIXATIONS")

@NamedQueries({

@NamedQuery(name = "Fixation.searchByTimeRange", query = "select f from Fixation f where f.time >= :start AND f.time <= :end"),

@NamedQuery(name = "Fixation.getByCheckpostId", query = "select f from Fixation f where f.checkpost.id = :id"),

@NamedQuery(name = "Fixation.getByEmployeeId", query = "select f from Fixation f where f.employee.id = :id")

})

public class Fixation implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

@Temporal(TemporalType.TIMESTAMP)

private Calendar time;

@ManyToOne(fetch = FetchType.EAGER)

private Employee employee;

@ManyToOne(fetch = FetchType.EAGER)

private Checkpost checkpost;

…

}

Класс Part используется для хранения информации о части сохраненного видеопотока. Класс содержит поля размера файла, время и дату начала захвата, время и дату окончания захвата видеопотока и путь к файлу. Текст класса представлен в листинге 2.7.

- id - код записи

- file - путь к видеофайлу

- length - размер файла

- dateTo - дата и время окончания записи потока

- dateFrom - дата и время начала записи потока

- checkpost - ссылка на наблюдательный пункт

Листинг 2.7 - Листинг класса сущности «Часть записи»

@Entity

@Table(name = "PARTS")

@NamedQueries({

@NamedQuery(name = "Part.getByTime", query = "select p from Part p where p.dateFrom <= :time AND p.dateTo >= :time"),

@NamedQuery(name = "Part.getByTimeRange", query = "select p from Part p where :start BETWEEN p.dateFrom AND p.dateTo OR " +

":end BETWEEN p.dateFrom AND p.dateTo OR " +

"p.dateFrom BETWEEN :start AND :end OR " +

"p.dateTo BETWEEN :start AND :end")

})

public class Part implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String file;

private Long length;

@Temporal(TemporalType.TIMESTAMP)

private Calendar dateTo;

@Temporal(TemporalType.TIMESTAMP)

private Calendar dateFrom;

@ManyToOne(fetch = FetchType.LAZY)

private Checkpost checkpost;

…

}

Класс SDPAttribute используется для хранения информации, которая представляет собой параметры конфигурации для преобразования RTP потоков в RTMP. Данная информация необходима FFMPEG кодеку. Содержит поля названия атрибута и значения. Текст класса приведен в листинге 2.8.

- name - название атрибута

- value - значение атрибута

- checkpost - ссылка на наблюдательный пункт

Листинг 2.8 - Листинг класса сущности «SDP атрибут»

@Entity

@Table(name = "SDP_ATTRIBUTES")

@NamedQueries({

@NamedQuery(name = "SDPAttribute.getByCheckpostId", query = "select s from SDPAttribute s where s.checkpost.id = :id")

})

public class SDPAttribute implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String name;

private String value;

@ManyToOne(fetch = FetchType.LAZY)

private Checkpost checkpost;

…

}

В результате применения объектно-реляционного преобразования была сформирована схема базы данных представленная на рисунке 2.14.

Рисунок 2.14 - Реляционная схема базы данных

2.7 Проектирование диаграмм деятельности ИКС службы видеонаблюдения

Диаграммы деятельности для системы архива видеонаблюдения представляют собой схему поведения системы при реакции на различные события. Необходимо рассмотреть диаграмму деятельности при старте приложения и начальной инициализации подсистем «Media Server» и «Media Gateway». Начальное конфигурирование подсистемы «Media Gateway» представляет собой запрос и загрузку конфигурационных данных с центральной подсистемы «Media Server». Конфигурационные данные содержат в себе параметры публикации поток во внутреннюю среду системы. Конфигурация будет сохранена до перезагрузки приложения, после перезагрузки операция начальной инициализации повториться снова. Диаграмма активности, описывающая основные аспекты поведения системы при инициализации показана на рисунке 2.15.

При старте подсистемы «Media Gateway» происходит вычитывание конфигурации подсистемы из конфигурационного файла, далее формируется запрос к подсистеме «Media Server». Производится отправка запроса к удаленной подсистеме и прием ответа. В случае неудачного выполнения запроса процесс останавливается на некоторый промежуток времени и снова повторяется до момента приема корректных данных. Далее производится сохранение конфигурации, после чего начинается проход по всем конфигурационным данным, для каждого сконфигурированного потока отправляется уведомление удаленной подсистеме о публикации нового потока. По окончанию прохода по всем конфигурационным данным процесс завершается.

Рассмотрена диаграмма активности при подключении клиента к видеопотоку, диаграмма описывает процесс, выполняющийся в контексте подсистемы «Media Gateway». Для экономии ресурсов подсистемы «Media Gateway», потоки к которым не подключено ни одного клиента закрываются, а публикация потока инициируется при подключении клиента. Следует отметить, что при подключении клиента производится проверка логина и пароля, а также прав доступа. На рисунке 2.16 показана диаграмма активности при подключении клиента к видеопотоку.

Рассмотрена диаграмма активности при оповещении подсистемы «Media Server» о публикации нового потока. При получении оповещения о публикации нового потока подсистема «Media Server» должна произвести подключение к видеопотоку и начать запись потока в файл. Диаграмма активности при оповещении о публикации нового потока показана на рисунке 2.17.

Рисунок 2.15 - Диаграмма активности для начальной инициализации системы



Рисунок 2.16 - Диаграмма активности при подключении клиент к потоку



Рисунок 2.17 - Диаграмма активности для обработчика оповещения о публикации нового потока

Оповещение подсистемы «Media Server» о публикации нового потока необходимо для инициирования процесса записи потока в файл. Обработка оповещения происходит следующим образом, сначала происходит проверка логина и пароля, после чего создается отдельный поток, отвечающий за захват видеоданных. В отдельном потоке производится подключение к подсистеме «Media Gateway», захват видеоизображения, запись в файл. Следующим действием является проверка времени записи, если же время записи превышает заранее заданное в конфигурации - выполняется создание нового файла, в который дальше и будет производиться запись. Данная операция применяется, так как запись с камер видеонаблюдения ведется длительное время, таким образом, запись всего содержимого в единый файл делает его чрезмерно большим и сложным в управлении.

Далее будет рассмотрена диаграмма активности при управлении мобильным клиентом. Управление заключается в отправке команды подсистеме «Mobile Client» на подключение к определенному потоку. Диаграмма активности для управления мобильным клиентом показана на рисунке 2.18.

Рисунок 2.18 - Диаграмма активности для управления мобильным клиентом

Управление подсистемой «Mobile Client» производится с подсистемы «Media Server», которая предоставляет для этого сервисы другим клиентам. Управление мобильным клиентом производится следующим образом, сначала выполняется проверка логина и пароля пользователя, далее, в случае легитимности пользователя, выполняется поиск мобильного клиента по идентификационному номеру. В случае отсутствия в списке мобильного клиент с заданным идентификационным номером формируется сообщение об ошибке. Далее формируется управляющая команда, после чего выполняется отправка команды мобильному клиенту.

2.8 Проектирование диаграмм последовательности работы ИКС службы видеонаблюдения

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

С помощью данных диаграмм были описаны базовые временные аспекты поведения системы при выполнении начальной инициализации системы, запрос на просмотр видео из архива, запрос на просмотр видеопотока.

Для описания временных аспектов поведения системы при начальной инициализации системы определим логику процесса. Начальная инициализация системы необходима для конфигурирования подсистемы «Мedia Gateway» и «Media Server». Подсистему «Media Gateway» при старте необходимо сконфигурировать таким образом, чтобы она опубликовала все необходимые потоки с внешней среды во внутреннюю среду системы. Таким образом, данной подсистеме необходимы конфигурационные данные, хранящиеся централизованно в подсистеме «Media Server». После получения конфигурационных данных подсистема «Media Gateway» должна проинформировать подсистему «Media Server» о наборе публикуемых потоков. В свою очередь подсистема «Media Server» начнет захват видеопотока. Для экономии ресурсов используется техника «ленивой загрузки», таким образом, старт и преобразование видео потока начинается только при подключении клиента. Диаграмма последовательности начальной инициализации системы показана на рисунке 2.19.

Для описания временных аспектов поведения системы при выполнении запрос на просмотр видеопотока определим последовательность действий. Запрос на просмотр потокового видео выполняется в два этапа. На первом этапе необходимо получить информацию о доступных на данный момент транслируемых видеопотоках. На втором этапе выполняется подключение к определенному видеопотоку, который публикуется и контролируется подсистемой «Media Gateway». После чего происходит захват видеопотока. Диаграмма последовательности при выполнении запроса на просмотр видеопотока показана на рисунке 2.20.

Рисунок 2.20 - Диаграмма последовательности при выполнении запроса на просмотр видеопотока

Для описания временных аспектов поведения системы при выполнении запроса на просмотр видео из архива, определим последовательность действий. Выполнение данного запроса также выполняется в два этапа относительно подсистемы «Video portal». На первом этапе происходит получение информации о необходимых архивных видеозаписях, которые хранятся и управляются системой «Media Server». После получения информации производится подключение к подсистеме «Media Server» и инициируется загрузка видеозаписей. Диаграмма последовательности представлена на рисунке 2.21.



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

2.9 Обеспечение требований к безопасности ИКС службы видеонаблюдения

Требования к безопасности работы или использования приложения, связанные с разграничением доступа, работой с приватными данными, снижения подверженности рискам от внешних атак предполагается достичь путем реализации политики безопасности. Одним из решений, есть использование сетевого протокола для доступа к службе каталогов LDAP, который предназначен производить операции аутентификации, поиска и сравнения, а также операции добавления, изменения или удаления записей. На рисунке 2.22 представлена структурная схема дерева LDAP для ИКС службы виденаблюдения.

Рисунок 2.22 - Схема дерева LDAP для ИКС службы видеонаблюдения

2.10 Разработка карты сайта подсистемы отображения «Video Portal»

Была разработана карта сайта, которая отображает все разделы, подразделы и страницы системы видеонаблюдения. Карта сайта представлена в виде дерева, которая представляет собой информационную архитектуру системы и определяет пути навигации по сайту. На рисунке 2.23 приведена карта сайта для оператора системы, а на рисунке 2.24 - для администратора.

Рисунок 2.23 - Карта сайта для оператора системы

Рисунок 2.24 - Карта сайта для администратора системы

2.11 Проектирование прототипов интерфейса пользователя ИКС службы видеонаблюдения

Интерфейс клиентского приложения должен обеспечить максимальную функциональность по управлению службой видеонаблюдения.

На рисунке 2.25 приводится прототип интерфейса главного окна подсистемы «Video portal» системы службы видеонаблюдения. В верхней части располагается логотип организации наряду с расширенным меню, которое будет общим для всей системы. Данное меню содержит пять закладок, с помощью которых можно переключаться между представлениями. Закладка «Архив видеонаблюдения» необходима для перехода на страницу просмотра информационной структуры предприятия и соответственно просмотра видеофайлов архива. Закладка «On-line трансляции» необходима для перехода на страницу просмотра «on-line» видео в реальном режиме времени с видеокамер. Закладка «События» нужна для перехода на страницу поиска и просмотра событий распознавания образов. Кнопка «Поиск видеозаписей» будет использоваться для просмотра страницы поиска видеозаписей архива. Ниже расположено меню по управлению просмотром информационной структуры предприятия, которое включает в себя три закладки. Первая закладка отвечает за просмотр детальной информации о выбранном элементе в информационном дереве. Вторая показывает список событий произошедших на выбранном объекте в дереве. Третье меню активируется при выборе в дереве элемента представляющего собой наблюдательный пункт. Слева находится элемент пользовательского интерфейса отвечающего за отображение древовидной информационной структуры предприятия.

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

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

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

Рисунок 2.25 - Прототип интерфейса просмотра информационной структуры предприятия



Рисунок 2.26 - Прототип интерфейса просмотра событий

Рисунок 2.27 - Прототип интерфейса поиска видеозаписей в архиве

Рисунок 2.28 - Прототип интерфейса просмотра онлайн видеотрансляций

3. Реализация ИКС службы видеонаблюдения

В данном разделе проводится реализация информационно-компьютерной системы службы видеонаблюдения на основании анализа существующих систем, выделенных требований к разрабатываемой системе и разработки основных частей системы.