Предлагаемое решение
У предложенных на рынке систем учета электроэнергии есть один значительный минус. Для их реализации необходимо использовать счетчики с модулями передачи данных и организовывать канал передачи данных. Если на каких-либо предприятиях это применимо, то в бытовом секторе это не так просто реализовать в связи с высокой стоимостью соответствующей аппаратуры.
Разрабатываемая система не предполагает кардинальных изменений в текущей системе работы предприятия и по сути должна встраиваться в существующую организацию. По сути, автоматизации на начальном этапе подвергается только схема передачи данных. Подразумевается создание серверной части, взаимодействующей с биллинговой системой предприятия. И клиентской, передающей и принимающей информацию на сервер. Клиентская часть будет представлять собой коммуникатор либо смартфон с установленным на него специальным программным обеспечением.
Кратко опишем принцип работы в разрабатываемой системе. Учет так же будет производиться в несколько этапов:
- агент на клиентской части авторизуется в системе;
- агенту из базы данных онлайн высылается задание в электронной форме с тем же содержанием что и использующиеся сейчас;
- агент в оффлайн режиме заполняет показания счетчиков для всех абонентов из задания;
- после завершения снятия показаний они сохраняются в памяти устройства. Далее, при подключении к сети, агент должен отправить с клиента на сервер снятые показания;
- после этого на серверной части происходит обработка полученных результатов, они анализируются, сохраняются в базу данных и используются как и ранее. Система биллинга в свою очередь производит по этим показаниям расчет.
Модель системы с точки зрения прецедентов
На рисунке 6 представлена диаграмма прецедентов[3], показывающая то, как и кто ведет свою работу по внесению показаний в биллинговую систему. Сервер-посредник представляет на диаграмме подсистему хранения показаний. Это может быть комплекс ЭВМ с установленным программным комплексом или выделенный сервер, подключающийся как периферйный комплекс к существующей биллинговой системе (также отмечена на диаграмме в виде действующего лица). В любом случае, устанавливается асинхронное общение биллинговой системы, сервера-посредника и агента, пользующегося техническими средствами сбора и передачи показаний на сервер-посредник.
Жилец также влияет на ход работы системы, предоставляя или не предоставляя агентам доступ к счетчикам. Здесь возможно составление отчетов о причинах отказа дачи показаний или иные информационные процессы.
Рисунок 6 – Диаграмма прецедентов системы учета и контроля показаний “Омскэнергосбыт”
3 Модель системы с точки зрения проектирования
Представим подсистему хранения показаний на диаграмме классов на рисунке 6. Класс для работы с хранилищами данных, независимый от реализации этих хранилищ (реляционные БД, файлы с разделителями, Excel-файлы или другие формы хранения) представляет собой интерфейс – Data Access Object. От него наследуются классы DBAccess для работы с данными из БД, DocumentAccess для работы с данными в виде текстовых, табличных или иных стандартизированных представлений.
Таким образом, объекты класса TaskProvider, работая с данными через интерфейс Data Acces Object даже не имеют представления о первоначальной форме извлеченных данных. Таким образом обеспечивается параллельная разработка частей подсистемы хранения показаний и также разделяемость её на четкие отлаживаемые модули (конкретные реализации способов работы с данными и обобщенный компонент доступа к ним).
Класс, работающий с показаниями – ReadngsManager читает со специальных объектов в JSON-представлении все необходимые данные о счетчиках, их разрядности, показания, номер счета абонента счетчика, затем через Data Access Object сохраняет эти показания, предварительно проверив их корректность (validate), в случае чего сформировав ответное сообщение об успешном снятии показаний в хранилище или провале операции с возможными причинами.
Класс Network – обертка над низкоуровневым протоколом сетевого взаимодействия (HTTP, FTP, общение с БД и так далее). Как вариант, язык Java предлагает готовые каркасные реализации таких оберток в виде сервлетов, EJB-компонентов, а также ORM-технологии (фреймворк Hibernate).
TaskProvider отвечает за выдачу заданий по запросу агента, взяв в качестве ключа - идентификатор агента (число, строка, любые уникальные идентификационные данные, проверяемые сервером).
Рисунок 7 – Диаграмма классов подсистемы