От анализа к синтезу. Тупик? Взлетаем!

Анализ задачи СКУД выделил нам ряд очевидных сущностей:

1. основная задача СКУД как таблица,
2. валидатор как механизм принятия решения,
3. контроллер как устройство работы с внешним оборудованием.

Как же на основании этих сущностей сделать шаг к практической реализации задачи СКУД?

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

Задачу СКУД (в силу очевидности) можно реализовать в любой СУБД или даже в файле.

А как же быть с валидаторами и контроллерами?

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

ТУПИК!

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

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

А задача реализация СКУД приобрела вид:

Рассматривая ранее варианты валидации, я отметил вариант Проверка по двери.

Из этого варианта следует, что встроенный валидатор каждого контроллера должен иметь доступ к данным только своей колонки.

Как обеспечить валидатору доступ к данным, необходимым для его работы? Очевидны два варианта:

1. Вариант 1. Передать валидатору данные, необходимые для его работы (т.е. загрузить список карт в контроллер).
2. Вариант 2. Предоставить валидатору доступ к данным таблицы СКУД (и тут тоже есть свои варианты).

Вариант 1. Загрузка карт в контроллер.

Методика его реализации становится очевидной:

1. выбрать из таблицы основной задачи СКУД список карт для каждой двери.
2. передать каждую карту в контроллер СКУД.
3. выполнить пп. 1-2 для каждого контроллера.

Все!

Изучив свойства Абстрактной модели контроллера СКУД этот процесс можно расписать буквально по шагам:

Надо отметить, что:

1. выборку данных, подготовку команд и их передачу контроллеру можно реализовать в одном шаге,
2. т.к. контроллер дает ответы на команды (OK/Err), то процесс процесс загрузки данных в контроллер становится 100% контролируемым.
3. в приведенном примере описан вариант передачи основного условия валидации (код карты); необходимо осуществить еще и передачу дополнительных данных.
4. описанный процесс не зависит ни от способа реализации таблицы СКУД, ни от канала связи с контроллером, ни от длины кода карты (он рассматривается как константа).

Вариант 2. Доступ валидатора к внешним данным.

В этом варианте валидатор имеет доступ к данным основной задаче СКУД (либо к ее производным).

Резюме:

Использование абстрактной модели СКУД позволяет:

1. найти решение общей задачи СКУД.
2. формализовать процесс управления.
3. реализовать несколько вариантов управления.

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

<< Предыдущая - Следующая >>