Вахтель_VKR (1229959), страница 4
Текст из файла (страница 4)
Диспетчер таймеров. Для снижения загруженности системы таймерами была организована служба таймеров на основе диспетчера сообщений. Для этого были добавлены таблицы таймеров объектов. При запуске диспетчера автоматически запускается периодический таймер. После истечения каждого периода счетчик каждого объекта, заказавшего таймер (SetTimer), уменьшается на единицу. При достижении нулевого значения объекту посылается сообщение об истечении таймаута, при этом запись таймера не удаляется и может быть инициализирована снова повторным вызовом SetTimer. Для удаления записи таймера используется функция DeleteTimer.
Если вызывается деструктор объекта, зарегистрированного у диспетчера, то происходит удаление регистрации данного объекта, удаление всех его подписок (как входящих, так и исходящих), а также удаление всех его таймеров. Кроме этого организуется просмотр очереди сообщений диспетчера и удаление всех сообщений, направленных удаляемому объекту[10].
Трудоемкость поиска по таблице событий и таблице таймеров логарифмическая от числа всех элементов соответствующей таблицы. На рисунке 4 представлена диаграмма классов системы межобъектного взаимодействия СМХ.
Класс CEventDispatcher реализует диспетчер событий, сообщений и службу таймеров. Класс CObjEvent представляет собой объект событие, содержащий информацию об отправителе, получателе, типе сообщения, структуре события и времени отправления. Класс CInteractionObject задает общий интерфейс для всех взаимодействующих объектов в системе. Структуры ITEM_INTER_OBJ, TIMER_INFO, SUBSCRIBER_INFO представляют, соответственно, записи в таблице объектов, таблице таймеров и таблице подписчиков.
Рисунок 4 – Диаграмма классов системы межобъектного взаимодействия
4.2 Сохранение объектов
Сохранение объекта в файл. Некоторые объекты системы требуют сохранения на диск и последующего восстановления. Для этого на СМХ применяется механизм сериализации (преобразования объекта в последовательную форму и обратно). Принцип работы реализован следующим образом:
– При вызове функции сохранения в файл (Save) объект прежде всего записывает строку с именем своего класса. После этого происходит вызов функции сериализации (Serialize) с параметром «сохранить».
– В этой функции объект осуществляет запись на диск всех своих атрибутов. После этого объект считается сохраненным.
– При вызове функции загрузки объекта (пользователя) (Load) из файла считывается имя класса загружаемого объекта. Эта строка передается механизму параметризованного создания объектов, который осуществляет создание соответствующего объекта. После чего вызывается функция Serialize с параметром «загрузить».
– В функции Serialize происходит считывание из файла атрибутов сохраняемого объекта. Таким образом, в одном файле хранится произвольное число объектов. Однако, чтобы получать доступ к какому-либо объекту, приходится последовательно загрузить все предыдущие. Поэтому сериализацию удобно использовать лишь для сохранения состояния одиночных объектов, либо групп объектов, используемых одновременно.
На рисунке 5 представлена диаграмма классов, отображающая структуру данного механизма.
Для использования этого механизма все классы, желающие, чтобы их объекты сохранялись, должны наследовать от класса, задающего интерфейс для сериализации (CStorable, модуль Storable). Класс CStore задает интерфейс для использования различных типов файловых хранилищ. Например, класс CFileStore использует для работы с файлами функции API, а класс CFileExStore – функции класса CFileEx.
Этот механизм является полностью объектно-ориентированным, так как только сам объект (пользователь) знает порядок загрузки/сохранения своих атрибутов.
Рисунок 5 – Диаграмма классов механизма сериализации
Чтобы ускорить процесс записи объекта в файл, было принято следующее решение. Вместо того чтобы записывать на диск по-очереди все свои атрибуты, объект записывает себя целиком путем копирования области памяти. Это сделано для экономии времени записи, но при этом копируются не только атрибуты, но и таблицы виртуальных функций объекта и всех его базовых классов. Данный подход может применяться лишь в случаях, когда необходимо проводить постоянные сохранения объектов.
Склад. Сохранение в файл не позволяет нам организовать быстрый поиск и извлечение объектов. Для решения этой задачи на предприятии был разработан специализированный класс CStock (рисунок 6), являющийся контейнером одно - или двуключевых записей и реализующий возможности сохранения и поиска объектов. Склад хранит только объекты одного типа. Для этого он инициализируется именем класса хранимых объектов, положением и длиной ключей в записи, характеризующей объект [11].
Для помещения объектов на склад используется механизм, похожий на сериализацию. Каждый объект, желающий сохраняться на складе, должен иметь функции, задаваемые интерфейсом CStockItem. При добавлении объекта на склад, вызывается функция преобразования (Transform), которая по аналогии с функцией Serialize осуществляет запись атрибутов объекта и их извлечение. Однако в качестве хранилища атрибутов здесь выступает не файл, а строка (область памяти). Полученная строка добавляется в таблицу элементов и включается в индекс в соответствии со своим ключом (ключами).
Класс CStock имеет два индекса (по одному на каждый ключ), которые используются для быстрого поиска элементов. Поиск элементов по индексам осуществляется c помощью дихотомии, с использованием лексикографического сравнения, что дает возможность использования в качестве ключей любых типов, в том числе и строк.
Со склада можно извлекать либо один элемент, характеризуемый двумя ключами, имеющие одинаковые значения какого-либо одного ключа.
Были реализованы возможности извлечения элемента со склада с блокировкой записи и без блокировки. Для создания объектов извлекаемых элементов используется механизм параметризованного конструирования объектов.
Рисунок 6 – Диаграмма классов механизма складирования объектов
4.3 Работа с файлами на СМХ
Для обеспечения гибкой и надежной работы с файлами в механизмах сохранения объектов была разработана специальная система для обработки особых ситуаций – исключений.
Помимо непосредственной защиты самих операций предоставлялась возможность самому назначать функцию обработки для каждого файлового объекта или воспользоваться процедурой обработки по умолчанию. Для обеспечения эффективного и гибкого управления использовался специальный язык (UML). При возникновении исключения в режиме интерпретации выполняется специальная программа на этом языке – управляющий скрипт [12].
Данный язык позволяет однозначно сопоставить набору стимулов (причин исключения) последовательность действий, которые необходимо выполнить. Причем необходимые действия или последовательности действий могут повторяться любое число раз. Такая конструкция языка является вполне достаточной: количество стимулов конечно, и, сопоставив каждому стимулу последовательность действий, определяется реакция системы на все возможные файловые исключения для данного файлового объекта. Использование последовательности, а не единого действия, повышает гибкость языка за счет конструирования сложных действий на основе простых. Операция повторения позволяет строить сложные реакции на основе неоднократного выполнения блоков действий: например, ожидание освобождения файла при совместном его использовании и пр. Для стимулов, требующих одинаковой обработки, предусмотрена возможность сопоставления реакции их набору.
Использование данного языка позволило, помимо создания набора стандартных действий, предоставлять пользователю возможность регистрации своих собственных функций обработки исключений, что обуславливает дальнейшую расширяемость класса и приспособление его к любым потребностям.
Представление управляющего скрипта в виде строки разрешило подменять реакцию на файловые исключения прямо во время исполнения программы.
4.4 Взаимодействие подсистем
Команды. Архитектура «клиент-сервер» на предприятии подразумевает, что приложения-клиенты посылают запросы серверу, а тот их выполняет. Часто к серверу выдвигаются требования организации протоколирования этих запросов. Для реализации подобной схемы был использован шаблон проектирования «Команда». Он инкапсулирует запрос как объект, задавая параметры клиентов для обработки соответствующих запросов, ставит запросы в очередь и протоколирует их, а также поддерживает отмену операций [12].
Все команды имеют общий интерфейс, задаваемый классом CCommand (рисунок 7). В этом классе определена виртуальная функция Execute, которая инициирует выполнение команды. Такой подход позволил выполнять команду, не зная, какая это команда и что она должна сделать.
Если требуется выполнить несколько команд, то можно определить класс CMacroCommand как наследник класса CCommand, дополнив его операциями добавления и удаления команды и переписав операцию Execute таким образом, чтобы она осуществляла последовательное выполнения списка команд системы контроля доступом [13].
Для того чтобы организовывать протоколирование команд используется механизм сохранения объектов в файл, описанный выше. Для этого унаследуем класс CCommand от класса CStorable. Это позволит осуществить последовательную запись команд в файл. Протокол может быть использован для восстановления состояния системы в случае сбоя.
Рисунок 7 – Диаграмма классов механизма команд
Передача объектов. Сервер и клиенты производят обмен данными. Эти данные представляют собой различные объекты. Для того чтобы организовать передачу объекта от одного приложения другому, используется механизм, аналогичный сериализации, и осуществляемый преобразование объекта в строку. Тогда весь процесс передачи объекта выглядит следующим образом:
– Приложение-отправитель создает объект, инициализирует его данными и вызывает функцию преобразования в строку (Transform).
– Полученная строка передается приложению-получателю вместе с именем класса объекта (или другим идентификатором, определяющим объект).
– Получатель создает объект и вызывает функцию преобразования, передавая ей полученную строку. Использование этого механизма предполагает, что и отправитель и получатель знают о классе передаваемых объектов. Существенным преимуществом же является тот факт, что только сами объекты знают, как себя упаковать. Это позволяет не разрабатывать дополнительный формат пакета для передачи каждого объекта и облегчает возможности замены объектов и их повторного использования [14].
Для того чтобы иметь возможность унифицированного преобразования в строку был разработан класс CTransformable. Этот класс также был использован в механизме сохранения объектов на склад (рисунок 6).
5 Архитектура приложения-сервера СКУД на СМХ
В настоящее время на предприятии используется данная схема развертывания системы контроля управления доступом (рисунок 8).
Модули (служебные приложения) взаимодействуют с центральным сервером СКУД (рисунок 8), который исполняет роль диспетчера, обрабатывающего запросы приложений и события контроллеров, датчиков.
В качестве среды взаимодействия служебных приложений и сервера СКУД выступает локальная вычислительная сеть.
Рисунок 8 – Диаграмма развертывания СКУД на СМХ
Используя вышеописанные принципы, была разработана схема для представления архитектуры приложения-сервера СКУД. На рисунке 9 отражены пакеты, определяющие функциональную группировку классов, и показаны зависимости между ними.
– «Система связи сервера» - пакет, отвечающий за связь пользователей и сервера, а также сервера и оборудования СКУД на предприятии, такого как турникеты, датчики и т.д. Он организует прием входящих сообщений и отправку исходящих. Входящие сообщения интерпретируются как события, их публикация осуществляется от лица структурных объектов.
– Пакет «Структурные объекты» содержит объекты, являющиеся агентами внешних элементов системы, в данном случае на предприятии в этой роли выступают: контроллеры. Агенты используют систему связи для общения с внешним миром.
– Пакет «Объекты-данные» осуществляет группировку ряда пакетов, представляющих такие элементы предметной области, как группы и персоны (пользователи).
– Пакет «Исполнительная подсистема» отвечает за выполнение запросов от приложений и обработку событий контроллера. Он представляет собой адаптированную к системе реализацию механизма команд. Команды работают как с объектами-данными, так и со структурными объектами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
