Вахтель_VKR (1229959), страница 5

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

– Пакет «Сохранение объектов» показывает, каким образом сервер использует механизмы сохранения объектов. Этот пакет на СМХ используется командами, структурными объектами и объектами-данными.

Рисунок 9 – Пакеты и связи приложения - сервера СКУД

5.1 Пакет «Система связи сервера»

Рассмотрим состав (рисунок 10) и принципы работы системы связи приложения-сервера СКУД СМХ.

Класс CCommManager задает общий интерфейс для приема входящих соединений. При приеме соединения создается объект класса CCommObject, через который и осуществляется дальнейшее взаимодействие с подсоединившимся приложением. В данном случае в качестве коммуникационных объектов используются сокеты (для их объектно-ориентированного представления используется класс CBlockingSocket).

Кроме коммуникационного объекта создается структурный объект, представляющий собой образ приложения в системе (CApp). Образ приложения знает структуру своего коммуникационного объекта и может общаться с ним через диспетчер, что отражено на диаграмме стрелкой с пометкой «disp_link».

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

Рисунок 10 – Пакет "Система связи сервера"

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

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

5.2 Структурные объекты

В настоящее время все структурные элементы системы контроля доступа СМХ имеют агентов, представляющих интересы данных элементов внутри программы-сервера. Взаимодействие между агентами и другими объектами сервера происходит с помощью Диспетчера (интерфейс CInteractionObject). Для обеспечения надежности системы структурные объекты сохраняются в файл (интерфейс CStorable). В случае необходимости передают объект со всеми его данными другому приложению в виде строки (интерфейс CTransformable).

На рисунке 11 представлены классы пакета «Структурные объекты».

Класс CSystem представляет собой систему и является источником системных событий. Класс CApp является источником для объектов-агентов приложений, подключенных к серверу. Класс CController задает общий интерфейс для контроллера системы.

Для помещений в качестве контроллера используется класс турникета (CTurnstile), а класс CZone в качестве помещения. Для конкретного класса CTurnstile важно направление доступа [14].

Рисунок 11 – Пакет "Структурные объекты"

5.3 Объекты - данные

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

Пакет «Пользователи» (рисунок 12) задает логическую структуру данных о клиентах-пользователях системы.

Так, класс CPerson представляет собой сведения о персонах, CGroup – о группах, CCard – о картах. Класс CGGSlot задает возможность ассоциаций групп путем установления связи между ними. Для определения прав доступа конкретной персоны к определенному ресурсу используется отношение CPRSlot.

Наличие элемента этого отношения говорит о возможности доступа конкретного клиента к определенному ресурсу с использованием расписания. Класс CDayTimetable представляет собой расписание доступа на один день, аCYearTimetalbe – на год.

Рисунок 12 – Пакет "Пользователи" из пакета "Объекты - данные"

5.4 Исполнительная подсистема

Исполнительная подсистема сервера на предприятии построена на основе механизма команд, с учетом использования диспетчера и требований протоколирования запросов (рисунок 13).

Класс CCommandHandler отвечает за создание и запуск команд в системе. Он подписан на ряд событий и имеет таблицу, сопоставляющую имя класса конкретной команды определенному событию. В случае возникновения события обработчик команд проверяет, зарегистрирована ли за этим событием команда. Если соответствие найдено, то осуществляется создание экземпляра соответствующей команды с помощью механизма параметрического создания объектов. После создания команды происходит ее инициализация входными данными, на основе которых команда определяет своего получателя. Запуск команды осуществляется с помощью отправки ей сообщения.

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

Команды являются активными объектами системы, содержащими всю логику запросов приложений. Каждый объект-команда регистрируется у диспетчера и поэтому может осуществлять обмен сообщениями с другими объектами, подписываться на события и т.д.

Рисунок 13 – Пакет "Исполнительная подсистема"

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

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

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

5.5 Сохранение объектов

Этот пакет показывает, каким образом приложение-сервер СКУД использует механизмы сохранения объектов на предприятии (рисунок 14).

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

– Структурные объекты «живут» в системе постоянно. Они зарегистрированы у диспетчера, общаются с другими объектами, подписываются на события. Их «образ жизни» не позволяет им храниться на складе, поэтому для сохранения они используют сериализацию в файлы.

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

– Объекты-команды, являющиеся носителями логики запросов приложений. Эти объекты, так же как и структурные, являются «живыми», но «живут» они временно. Для их сохранения применяется сериализация в отдельные файлы. А после того, как команда выполнилась, организуется ее сохранение в общий файл протокола.

Рисунок 14 – Пакет "Сохранение объектов"

6 Архитектура приложения-клиента СКУД на СМХ

Разработанная архитектура предполагает, что приложение-клиент, так же как и сервер, является многопоточным. Поэтому для обеспечения межобъектного взаимодействия использовались те же механизмы, которые применялись в сервере. В каркас приложения были включены следующие пакеты (рисунок 15):

Рисунок 15 – Пакеты и связи приложения - клиента СКУД СМХ

6.1 Система связи приложения-клиента

На предприятии система связи клиента использует те же коммуникационные объекты, что и сервер (рис.16).

– «Система связи клиента» - обеспечивает прием и публикацию информации от приложения-сервера.

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

– «Диалоговые классы» - объединение классов, занимающееся визуализацией и представлением информации, полученной от сервера. Сюда входят как основной диалог, так и классы «помощников» (wizard), обеспечивающие возможность построения необходимых запросов приложению-серверу.

– С пакетами «Объекты-данные» и «Структурные объекты» мы уже познакомились при рассмотрении архитектуры сервера. Присутствие их в приложении объясняется используемым способом передачи объектов от приложения приложению, который описан в архитектурных механизмах.

Рисунок 16 – Пакет "Система связи клиента"

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

6.2 Пакеты «Клиент» и «Диалоговые классы»

Так как пакет «Клиент» состоит лишь из одного класса, рассмотрим его вместе с пакетом «Диалоговые классы» (рисунок 17).

Для того чтобы интегрировать класс приложения (CClientApp) в структуру СКУД, наследуется его структурный класс CApp. Это автоматически заставляет его регистрироваться у диспетчера. В связи с тем, что класс CClientApp является первым классом, создаваемым приложением, вся начальная инициализация помещена в его функцию InitInstance. Здесь создается диспетчер, коммуникационный объект, инициализируется функция подключения к серверу, устанавливаются начальные подписки и т.д.

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

Приложение-клиент содержат также диалоговые классы «помощников» (CWizard), которые шаг за шагом позволят пользователю внести необходимые изменения (создать группу, добавить нового члена группы и т.д).

Характеристики

Список файлов ВКР