Предлагаемый способ реализации системы.

Для окончательного перехода от формирования требований, декомпозиции на модули и составления набора функций, решающих поставленную задачу, к реализации приведем диаграмму компонентов, объединенную с диаграммой развертывания. Это довольно распространенный подход при разработке схем имплементации (реализации) системы, когда одно отображение дополняет другое.

Специфика работы Системы

- протокол передачи TCP/IP, Http-запрос/ответ

- формат передачи данных – текстовый посредством JSON-схемы

- независимая от источника данных (дамп базы конкретной СУБД, файл с разделителями, электронная книга Excel и так далее) модель доступа к данным

- асинхронное во времени общение клиентов с биллинг-системой

- автоматизированный контроль вводимых данных на стороне агента

- автоматизированный контроль полученных данных на стороне биллинг-системы до внесения их в базу

На рисунке 9 приведена диаграмма копмонентов совмещенная с диаграммой развертывания. Агенты взаимодействуют с биллинг-системой посредством специализированных устройств с каналами передачи (беспроводной интернет, либо данные скидываются по USB на машины в филиалах).

Рисунок 9 – Диаграмма компонентов, объединенная с диаграммой развертывания

Особенно полезным и целесообразным здесь является применение так называемых фреймворков ORM - технологии Объектно-Реляционного отображения. Когда записи из БД воспринимаются в системе на стадии исполнения как Объекты, отражающие бизнес-логику системы, они функционируют должным образом, имеют свойства и методы. По сохранении объектов в БД и отключении системы, объекты переносятся в реляционное представление и уже хранятся разнесенными записями в таблицах согласно схеме БД. Здесь преимущество в том, что выбор СУБД практически не затрагивает остальные части системы, менять их уже не придется. Поддержка множества СУБД также является преимуществом технологии таких фреймворков.

Среда исполнения как компонент подсистемы хранения показаний – необходимая часть в виде набора ЭВМ, ОС с настроенным сервером приложений (например, Apache для php-приложений, Apacha Tomcat, JBoss для Java Enterprise приложений). Сервисы в среде исполнения представляют необходимые классы для реализации функций подсистемы:

Таблица 1 – Функции подсистемы хранения показаний

Получение данных от биллинговой системы

Отправка данных клиентам

Прием, обработка запросов от клиентов

Прием данных с показаниями от клиентов.

Подсистема хранения на серверной стороне принимает показания, выдает задания, осуществляет контроль приходящих показаний. Специальный формат пакетов – JSON, оговоренный заказчиком, должен быть специальным образом обработан. Для этого потребуется написание соответствующего обработчика пакетов (класс, набор динамических библиотек или просто обертка с интерфейсом над существующими библиотеками работы с таким форматом).

У подсистемы сбора показаний имеется сервис ввода показаний. Он формируется из классов для работы с внутренней БД подсистемы, специальных классов, соуществляющих контроль и проверку вводимых данных, подсистемы отправки, подсистемы буферизации показаний. Все это скрыто от агентов, предоставляется только внешний интерфейс в виде экранных форм либо консоли, тогда оговаривается формат команд и приводятся возможные аргументы этих команд.

Модель доступа показана на диаграмме как интерфейс, необходимый для всей увязки компонентов подсистемы сбора показаний. Нужна она и в подсистеме хранения показаний. Этот интерфейс реализуется по разному в двух подсистемах. Так, в подсистеме сбора показаний предполагается только формирование набора необходимых хранимых процедур для соответствующей СУБД, а также класса для вызова этих процедур в ответ на действия агента с устройством.

В подсистеме хранения показаний несколько более универсальный и прозрачный механизм предоставляет такой интерфейс. Как оговорено в специфике работы АС, данные могут предоставляться в широком диапазоне форматов хранения, поэтому здесь недостаточно просто хранимых процедур и классов для их комбинирования и вызова. Нужны библиотеки работы со специальными файлами, готовые библиотеки (фреймворки).

Заключение

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

Полученные диаграммы и решения могут быть в дальнейшем использованы как материал для дипломного проектирования. Описанная система действительно востребована в ОАО “Омскэнергосбыт” и в перспективе может быть введена в виде прототипа, а затем и переведена в эксплуатацию при окончательной реализации.

Список использованных источников

1. Издательский дом “Вильямс”: Эволюция объектной модели. Предпросмотр. [Электронный ресурс] / Издательский дом “Вильямс”, - Режим доступа: http://www.williamspublishing.com/PDF/978-5-8459-1401-9/part.pdf

2. Цыганенко В.Н. Cals/case-технологии проектирования информационных систем: конспект лекций/Цыганенко В. Н. – Омск: Изд-во ОмГТУ, 2007. – 80 с.

3. Омскэнергосбыт: общая характеристика: [Электронный ресурс] / ОАО “Омскэнергосбыт”, 2005-2011. – Режим доступа: http://www.omskenergosbyt.ru/about/about.htm, свободный. – Загл. с экрана. – Яз. рус.

Дата добавления: 2015-07-25