Структурная модель СКУД предприятия с арендаторами и их клиентами

в 19:55, , рубрики: Анализ и проектирование систем, ненормальное программирование, ооп, СКУД, структурная модель

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

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

Особенности структурной модели

Построим структурную модель СКУД на территорию с одной точкой доступа. Любая точка доступа оборудуется замком, для открытия которого имеется набор ключей. Простейшая модель такой системы включает в себя четыре сущности, играющие определенные роли, например, для квартиры с одной входной дверью:

Структурная модель СКУД предприятия с арендаторами и их клиентами - 1

Однако, даже при самом подробном описании сущностей, они не являются моделью системы, потому что между ними нет связей. Например, описывая дверь, мы должны знать к какой она относится квартире. Устанавливая связи между сущностями (объектами), мы фиксируем результат взаимодействия между ними и задаем связь как набор атрибутов: дверь в квартиру установлена 01.01.2000 (атрибут Дата), замок на двери установлен 02.01.2000 (атрибут Дата) мастером Петровым П.П. (атрибут Мастер).

Структурная модель СКУД предприятия с арендаторами и их клиентами - 2

Так как у каждого из связанных объектов может быть свой «взгляд» на связь между ними, то нужно рассматривать две связи. Например, связь Замок#Двери это набор атрибутов,

{"Имя связи", "Дата установки замка", "Кем установлен замок"}

а связь Двери#Замок — набор атрибутов

{"Имя связи", "Дата установки замка", "Кем установлен замок", ["Координаты установки замка"]}

Структурная модель СКУД предприятия с арендаторами и их клиентами - 3

Установка второго замка на дверь, означает появление не только нового экземпляра сущности (без изменения ее роли), но и изменения ее «размерности» — с одномерной Замок, на многомерную Замки. Точно также установка второй двери изменит «размерность» соответствующей сущности:

Структурная модель СКУД предприятия с арендаторами и их клиентами - 4

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

Структурная модель СКУД предприятия с арендаторами и их клиентами - 5

может иметь вид:

[{"Имя связи", "Операция (открытие/закрытие)", "Время начала операции"}, {}, ..., {}]

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

Роли и объекты структурной модели

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

Структурная модель СКУД предприятия с арендаторами и их клиентами - 6

Связь Метки#Посетители:

[{ "Имя связи", "Имя посетителя", "Тип метки": (Постоянный, Временный, Разовый) ", "Дата начала владения", "Дата окончания владения", "Статус метки": (Активный, Неактивный)}, ...]

Такая связь позволяет:
однозначно идентифицировать посетителя по метке (только одна запись в связи может иметь Статус метки=Активный);
выдавать сотруднику разовый или однодневный временный пропуск взамен забытого;
задавать срок действия временного пропуска.

Связь Посетители#Метки:

[{"Имя связи", "Имя метки", "Причина добавления новой метки"}, ...]

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

Связь Считыватели#Метки:

[{ "Имя связи", "Имя метки", "Статус метки": (Вход разрешен, Вход запрещен, Выход разрешен, Выход запрещен), "Время считывания"}, ...]

Такая связь позволяет вести журнал учета событий со считывателем.
Связь Метки#Считыватели устанавливать не будем, так как для нее нет значимых атрибутов.
Получение статуса Вход разрешен, еще не означает, что вход состоялся. Для того, чтобы отобразить атрибуты связанные с переходом добавим связи между метками и турникетом.

Структурная модель СКУД предприятия с арендаторами и их клиентами - 7

Связь между меткой и считывателем должна показывать какая метка каким считывателем и когда определяется, а также фиксировать статус метки.
Связь Метки#Турникет:

[{ "Имя связи", "Имя Турникета", "Направление": (Вход, Выход), "Время перехода"}, ...]

Такая связь позволяет вести учет переходов через турникет каждым посетителем в соответствии с его меткой.
Связь Турникет#Метки:

{ "Имя связи", ["Имя Метки", "Направление": (Вход, Выход, Не определено), "Время перехода"]}

Такая связь позволяет вести журнал посетителей и переходов. Если невозможно определить направление перехода (турникет открыт кнопками в обоих направлениях), а переход осуществлен, в связи указывается время перехода с неопределенным направлением и пустым именем метки.
Связи между турникетом и считывателями, а также турникетом и зоной доступа могут использоваться для учета эксплуатации устройств, например, связь Турникет#Считыватели:

{"Имя связи", ["Имя cчитывателя", ["Событие": (Установка, Ремонт, Замена) ,"Время события"]]}

Чтобы определить направление перехода в связях Метки#Турникет и Турникет#Метки нужно знать позицию посетителя (метки) по отношению к зоне доступа. Соответствующий атрибут удобно держать в связи между меткой и зоной доступа, поэтому создадим соответствующую связь:

Структурная модель СКУД предприятия с арендаторами и их клиентами - 8

Связь Зона_доступа#Метки:

{"Имя связи", ["Имя Метки", "Имя Посетителя", "Позиция"]}

Такая связь позволяет определить позицию Посетителя в любой момент времени, а также обеспечить контроль за сменой позиций при наличии нескольких зон доступа. Например, Посетитель не может попасть во внутреннее помещение, если он не вошел через турникет.

Связь Метки#Зона_доступа:

[{"Имя связи", "Имя Зоны ", "Время входа", "Время выхода", "Время пребывания"}]

Такая связь позволяет получать необходимые данные для учета рабочего времени с учетом фактического времени пребывания на территории. Однако этих данных не достаточно. Во — первых, нужна информация о фирме-работодателе (фирмах-работодателях), а во-вторых — информация о графике работы. Для учета такой информации добавим новый объект Фирма в роли Работодатель и установим связи между ней и сотрудниками (Посетители).

Структурная модель СКУД предприятия с арендаторами и их клиентами - 9

Связь Посетители#Фирма:

[{"Имя связи", "Имя фирмы", "Время прихода на работу факт", "Время прихода на работу учет", "Время ухода с работы факт", "Время ухода с работы учет", "Время пребывания на работе факт", "Время пребывания на работе учет"}]

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

{"Имя связи", ["Имя посетителя", "Посещение в нерабочие дни", "Режим работы", ["Дата", "Время прихода на работу план", "Время ухода с работы план", "Время пребывания на работе План"]]}

Такая связь позволяет учитывать данные по графику работы для каждого сотрудника, а также запрещать или разрешать вход в Зону доступа в нерабочие дни. Данные для связи формируются вне СКУД и должны поступать от фирм.
Теперь рассмотрим контроль за клиентами фирм. Такие посетители являются покупателями или поставщиками (или их представителями) фирм. Фирмы для них выступают не в роли Работодателя, а в роли Поставщика или Покупателя. Таким образом, у объекта появляется несколько ролей:

Структурная модель СКУД предприятия с арендаторами и их клиентами - 10

Соответственно изменяется и количество связей между посетителем и фирмой. И хотя теперь каждый посетитель может играть роли Сотрудника, Покупателя или Поставщика, в рамках структурной модели мы оставляем ему только одну роль — Владельца идентификатора. Зато увеличение количества связей

Структурная модель СКУД предприятия с арендаторами и их клиентами - 11

позволяет собирать и хранить всю информацию, необходимую для контроля за клиентами арендаторов.
Связь Посетители#Покупатель#Фирма:

[{"Имя связи", "Имя фирмы", "Время получения товара", "Время оформления документов", "Время оплаты товара"}]

Такая связь позволяет разрешать выход покупателя в зависимости от условий, наложенных поставщиком (все три времени не нулевые). Аналогично, в связи Посетители#Поставщик#Фирма:

[{"Имя связи", "Имя фирмы", "Время получения товара", "Время оформления документов"}]

содержатся данные необходимые для разрешения поставщику покинуть территорию.

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

Автор: LRpro

Источник

Поделиться новостью

* - обязательные к заполнению поля