4 Диаграмма деятельности
4.1 Отправка показаний счетчиков на сервер
Диаграмма деятельности[3] представляет собой блок-схему, которая показывает, как поток управления переходит от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Результат может привести к изменению состояния системы или возвращению некоторого значения.
Диаграмма деятельности процесса взаимодействия агента через свое устройство с сервером системы представлена на рисунке 8.
На диаграмме в частности показан способ отправки показаний счетчиков на сервер. Массив записей преобразуется в JSON-структуры, которые группируются в блоки, а затем поблочно отправляются через HTTPS-соединение на сервер. Таким образом обеспечивается сохранность отправляемых данных в случае сбоя на стороне клиента или сервера. Неотправленные блоки сохраняются во временной буфер и при восстановлении соединения позже отправляются на сервер.
Данная диаграмма служит ориентиром на создание API (прикладных библиотек) для взаимодействия с подсистемой хранения показаний с её серверной частью, а также определяет типовой сценарий работы подсистемы сбора показаний, когда выполняется наиболее значимая часть задач, возложенных на систему – сбор показаний с последующей их отправкой на хранение.
Рисунок 8 – Диаграмма деятельности
5 Предлагаемый способ реализации системы.
Для окончательного перехода от формирования требований, декомпозиции на модули и составления набора функций, решающих поставленную задачу, к реализации приведем диаграмму компонентов, объединенную с диаграммой развертывания. Это довольно распространенный подход при разработке схем имплементации (реализации) системы, когда одно отображение дополняет другое.
Специфика работы Системы
- протокол передачи TCP/IP, Http-запрос/ответ
- формат передачи данных – текстовый посредством JSON-схемы
- независимая от источника данных (дамп базы конкретной СУБД, файл с разделителями, электронная книга Excel и так далее) модель доступа к данным
- асинхронное во времени общение клиентов с биллинг-системой
- автоматизированный контроль вводимых данных на стороне агента
- автоматизированный контроль полученных данных на стороне биллинг-системы до внесения их в базу
На рисунке 9 приведена диаграмма копмонентов совмещенная с диаграммой развертывания. Агенты взаимодействуют с биллинг-системой посредством специализированных устройств с каналами передачи (беспроводной интернет, либо данные скидываются по USB на машины в филиалах).
Рисунок 9 – Диаграмма компонентов, объединенная с диаграммой развертывания
Особенно полезным и целесообразным здесь является применение так называемых фреймворков ORM - технологии Объектно-Реляционного отображения. Когда записи из БД воспринимаются в системе на стадии исполнения как Объекты, отражающие бизнес-логику системы, они функционируют должным образом, имеют свойства и методы. По сохранении объектов в БД и отключении системы, объекты переносятся в реляционное представление и уже хранятся разнесенными записями в таблицах согласно схеме БД. Здесь преимущество в том, что выбор СУБД практически не затрагивает остальные части системы, менять их уже не придется. Поддержка множества СУБД также является преимуществом технологии таких фреймворков.
Среда исполнения как компонент подсистемы хранения показаний – необходимая часть в виде набора ЭВМ, ОС с настроенным сервером приложений (например, Apache для php-приложений, Apacha Tomcat, JBoss для Java Enterprise приложений). Сервисы в среде исполнения представляют необходимые классы для реализации функций подсистемы:
Таблица 1 – Функции подсистемы хранения показаний
Получение данных от биллинговой системы |
Отправка данных клиентам |
Прием, обработка запросов от клиентов |
Прием данных с показаниями от клиентов. |
Подсистема хранения на серверной стороне принимает показания, выдает задания, осуществляет контроль приходящих показаний. Специальный формат пакетов – JSON, оговоренный заказчиком, должен быть специальным образом обработан. Для этого потребуется написание соответствующего обработчика пакетов (класс, набор динамических библиотек или просто обертка с интерфейсом над существующими библиотеками работы с таким форматом).
У подсистемы сбора показаний имеется сервис ввода показаний. Он формируется из классов для работы с внутренней БД подсистемы, специальных классов, соуществляющих контроль и проверку вводимых данных, подсистемы отправки, подсистемы буферизации показаний. Все это скрыто от агентов, предоставляется только внешний интерфейс в виде экранных форм либо консоли, тогда оговаривается формат команд и приводятся возможные аргументы этих команд.
Модель доступа показана на диаграмме как интерфейс, необходимый для всей увязки компонентов подсистемы сбора показаний. Нужна она и в подсистеме хранения показаний. Этот интерфейс реализуется по разному в двух подсистемах. Так, в подсистеме сбора показаний предполагается только формирование набора необходимых хранимых процедур для соответствующей СУБД, а также класса для вызова этих процедур в ответ на действия агента с устройством.
В подсистеме хранения показаний несколько более универсальный и прозрачный механизм предоставляет такой интерфейс. Как оговорено в специфике работы АС, данные могут предоставляться в широком диапазоне форматов хранения, поэтому здесь недостаточно просто хранимых процедур и классов для их комбинирования и вызова. Нужны библиотеки работы со специальными файлами, готовые библиотеки (фреймворки).