Подсистема оповещения для информационной системы учета электропогружного оборудования скважин нефтяной компании "Роснефть"

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Реферат

стр. 82, рис. 28, табл. 9, прил. 2

Подсистема оповещения для информационной системы учета Электропогружного оборудования скважин нефтяной компании «Роснефть» (Компании).

В данной дипломной работе проведено исследование процесса работы пользователей с информационной системы учета электропогружного оборудования скважин (ИС «ЭПОС»). Целью работы является повышение эффективности работы пользователей ИС «ЭПОС».

В результате данной работы было спроектирована, разработана и внедрена подсистема оповещения в ИС «ЭПОС», устраняющая недостатки в работе ИС «ЭПОС». Разработаны и реализованы спецификации требований на внесение изменений в ИС «ЭПОС».

Подсистема оповещения разработана в среде программирования Microsoft Visual Studio и внедрена с применением системы управления версиями SourceGear Vaul.

Подсистема оповещения разработана, внедрена и находится на стадии тестирования жизненного цикла ИС «ЭПОС».



Содержание

Реферат

Перечень понятий и сокращений

Введение

1.Описание предметной области

1.1 Модель бизнес-процессов

1.2 Обзор ИС «ЭПОС»

2.Обзор аналогов

2.1 Подсистема оповещений и уведомлений системы «Дело»

2.2 Програм Лайн: Уведомления о событиях

2.3 Подсистема «Выписка Онлайн» в ДБО BS-Client x64

2.4 Вывод

3.Постановка задачи

4.Контур Подсистемы

5.Инфологическая модель предметной области

6.Виды обеспечения

6.1 Информационное обеспечение

6.2 Математическое обеспечение

6.3 Программное обеспечение

6.3.1 Подсистема связи с СУБД

6.3.2 API СУБД

6.3.3 Модуль опроса базы данных

6.3.4 Модуль оперативного оповещения

6.3.5 Модуль формирования заявок

6.3.6 Модуль формирования подписок

6.4 Техническое обеспечение

7.Описание интерфейса

7.1 Оповещение по событиям

7.2 Оповещение о запросах

7.3 Контроль ввода данных

8.Технико-эксплутационные характеристики

Заключение

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

Приложение 1

Приложение 2



Перечень понятий и сокращений

информационный учет оповещение скважина

БД - база данных

ДК - мероприятие расследования причин внутрисменной остановки комплекта погружного оборудования на подконтрольной скважине, либо ее отказа

ДО - дочернее добывающее общество

ИС - информационная система

НЭО - наземное электрооборудование скважины

ОК - отдел качества

ПО - погружное оборудование

РФ - Российская Федерация

СП - сервисное предприятие

СУБД - система управления базами данных

ЭПОС - система учета электропогружного оборудования скважины

Событие - регистрация факта внутрисменной остановки комплекта погружного оборудования на подконтрольной скважине, либо ее отказ

Компания - ОАО «НК «Роснефть»

Подсистема - подсистема оповещения, разработанная для внедрения в «ЭПОС»



Введение

Компания является крупнейшей нефтедобывающей компанией в Российской Федерации (РФ). Непосредственно добычу углеводородного сырья осуществляется дочерними добывающими обществами (ДО) компании «Роснефть». Каждая ДО может владеть десятками тысяч скважин, за состояниями которых необходимо постоянно наблюдать и которых необходимо обслуживать. Для обслуживания скважин в состав ДО входят сервисные предприятия (СП) осуществляющие непосредственно техническое обслуживание оборудования на месторождениях.

При таких больших масштабах невозможно обойтись без современных информационных системы и компьютерных технологий. С целью оперативного учета и анализа параметров эксплуатации и ремонта электропогружного оборудования скважин в Компании используют собственную разработку - «ЭПОС».

Для обеспечения и повышения качества работ сервисных подразделений, на уровне ДО активно работает отдел качества (ОК). отдел качества занимается расследованием случаев остановки, демонтажа и отказов скважин (События). При этом отдел качества активно использует «ЭПОС» для сбора данных по расследуемым Событиям. В результате расследования делается заключение и на основании этого заключения руководителям предлагают внести ряд изменений в деятельность СП для исключения таких причин. От эффективности работы отдел качества во многом зависит качество работы всей Компании, однако в работе отдел качества возникают задержки и простои из-за недостаточных или некорректных данных полученных от СП через «ЭПОС». Т.к. территориально отдел качества и СП находятся на больших расстояниях, и часто неизвестно какой оператор ответственен за данные, возникают сложности в создании запроса на дополнение и коррекцию данных. Не смотря на это, даже своевременное дополнение или корректирование данных не исключает задержек в работе отдела качества, т.к. сотрудник отдела качества не оповещается об этом.

В данной работе было исследован процесс работы пользователей ЭПОСа в результате чего были выявлены недостатки ЭПОСа, устранив которые можно было значительно повысить эффективность работы отдела качества. Было предложено разработать подсистему оповещения (Подсистема) для устранения таких недостатков ЭПОСа, как:

недостаточный контроль за своевременный ввод данных;

отсутствие возможности создания запросов на коррекцию и дополнение данных;

отсутствие оповещения о вводе данных по Событиям.

Для разработки Подсистемы была использована среда разработки Microsoft Visual Studio. Разработанная подсистема способна расширить «ЭПОС» функциями:

оповещение пользователя о несвоевременном вводе данных;

оповещение пользователя о Событиях;

формирование запросов на коррекцию и дополнение данных;

оповещение пользователя о некорректных и неполных данных.

Благодаря спиральной модели жизненного цикла ЭПОСа, автор воспользовался возможностью внедрить Подсистему в «ЭПОС» и устранил тем самым выявленные недостатки в работе ИС «ЭПОС». Для качественного внедрения были использована система управления версиями SourceGear Vault.

В процессе внедрения были внесены изменений в компоненты ЭПОСа для обеспечения взаимодействия Подсистемы с ИС «ЭПОС».



1. Описание предметной области

Нефтяная промышленность РФ - основной сектор топливно-энергетического комплекса нашей страны. От ее успешного функционирования зависят эффективное удовлетворение внутреннего и внешнего спроса на нефть и продукты ее переработки, обеспечение валютных и налоговых поступлений в федеральный бюджет. Не менее важна эта отрасль и для энергетической безопасности страны и ее политических интересов в мире [1].

Большое место в нефтяной промышленности РФ занимает ОАО «НК «Роснефть». Компания добывает большую часть нефти по всей территории РФ. Большие объемы добычи достигаются благодаря интенсивной разработке месторождений и большому количеству используемых скважин (миллионы). Для технического обслуживания такого большого числа скважин в Компании работают множество сервисных предприятий.

Эффективность использования нефтепромыслового подземного оборудования во многом зависит от повышения качества его изготовления, подбора оборудования, соблюдения технологии монтажа и эксплуатации[2]. Повышение качества серийно изготавливаемого оборудования необходимо добиваться за счет повышения качества рекламационной работы к заводам-изготовителям, т.е. полно и качественно проводить учет и анализ работы узлов оборудования. Данная работа требует накопления большой статистики по причинам отказа узлов оборудования, о наработке их за срок службы, о характеристиках рабочей среды, и условий эксплуатации, где используется данное оборудование.

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

Повышение межремонтного периода работы электропогружных установок -- главная цель проведения расследований по Событиям. Однако какие конкретно мероприятия необходимо произвести для этого, проанализировать результат их внедрения -- все это сложная, трудоемкая задача, которая требует обработки больших объемов информации в разных разрезах.

Для решения таких задач Компания применяет «ЭПОС», с помощью которой проводится сбор данных из СП для анализа.

1.1 Модель бизнес-процессов

Объектом исследования является процесс работы сотрудников СП и отдел качества с ИС «ЭПОС». На вход процесса поступает информация из различных источников в бумажном и электронном виде. Сотрудники СП и отдел качества руководствуются соответствующими положениями и инструкциями пользователя «ЭПОС». В результате работы оформляются сводные отчеты, а пользователи отдел качества с помощью ИС «ЭПОС» формируют протокол расследования.

Модель бизнес-процессов описана согласно нотации IDEF0. IDFE0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции[3]. Концептуальная схема предметной области представлена на рис. 1.



Рис.1. Концептуальная схема предметной области

При декомпозиции процесса работы пользователя с «ЭПОС» можно выделить 4 основных процесса:

Ввод данных - процесс ввода данных операторами СП с помощью ИС «ЭПОС», согласно положению о сервисных предприятиях. При данном процессе пользователь руководствуется инструкциями по использованию ИС «ЭПОС».

Хранение и управление данными - процесс хранения данных и их управление с помощью СУБД, используемой для работы ИС «ЭПОС». Данные хранятся по определенным правилам с соблюдением правил нормализации и ограничений целостности. По имеющимся данным можно получить с помощью ИС «ЭПОС» сводные отчеты о различных событиях, объектах учета и других сущностей.

Расследование Событий - мероприятие, которое проводит отдел качества добывающего объединения для поиска причин остановки подконтрольных скважин. Для расследования необходимы различные данные о событиях. При этом пользователь тратит время на поиск скважин, чьи события необходимо расследовать. Согласно положению об отделе качества, сотрудник отдела качества по завершению расследования оформляет протокол по дню качества. Протокол оформляется с использованием ИС «ЭПОС» согласно его инструкциям. При недостатке или некорректности данных, используемых при расследовании, сотрудник отдел качества вынужден обращаться в сервисное предприятие, которое обслуживает подконтрольную скважину. В этом случае сотрудник отдела качества связывается с руководителем СП посредством телефонной связи или корпоративной почты. Руководитель СП после подобного обращения должен выяснить, какой оператор внес некорректные данные или должен был внести данные, но этого не сделал, и дать ему задание внести или скорректировать данные.

Дополнение и коррекция данных - процесс, при котором оператор СП ответственный за данные корректирует или дополняет данные с помощью ИС «ЭПОС», необходимые сотруднику отдела качества для расследования Событий или оформления протокола по ДК. При этом оператору СП не всегда ясно, какие именно данные некорректны и по какому именно событию необходимо ввести данные. Скорректированные и дополненные данные хранятся в БД. Сотрудник отдела качества никаким образом не извещается о выполнении запроса, из-за чего приходится самостоятельно периодически проверять изменения в данных. Из-за большого количества скважин, такие запросы возникают часто, и происходит путаница, вследствие которой часто возникают ошибки пользователей при вводе данных.

Модель бизнес-процессов предметной области представлена на рис.2.

Рис. 2. Модель бизнес-процессов



При такой модели время от начала расследования до оформления протокола по ДК складывается из следующих составляющих:

- время поиска событий для расследования [1 - 8 час];

- время запроса коррекции и дополнения данных [1 час];

- время поиска ответственных за ввод данных [2 - 4 часа];

- время дополнения и коррекции данных [8 - 16 часов];

- возобновления расследования после выполнения запроса [8- 16 часа];

- время расследования событий с корректными и полными данными [2 - 6 часов].

Рис. 3. Временные затраты бизнес-процессов

Таким образом, время от начала расследования до оформления протокола, по оценке автора, может доходить до рабочих часов, что в переводе на дни может составлять 6-7 рабочих дней, как это видно на рис. 3.

1.2 Обзор ИС «ЭПОС»

Информационная система «ЭПОС» предназначена для ведения оперативного учёта, контроля и анализа параметров эксплуатации и ремонта электропогружного оборудования, их узлов, НЭО и кабеля и формирования первичной, оперативной и аналитической отчетности ОАО «НК «Роснефть», а также сторонних предприятий, задействованных в процессе учёта. В системе реализован широкий спектр функций по учету операций над оборудованием, позволяющие отслеживать состояние оборудования и его параметров на всем его жизненном цикле.

Первичные данные и данные об операциях над оборудованием вносятся операторами СП. Система так же позволяет осуществлять оформление первичных документов и отчетов для заказчика сервисных работ. В системе храниться такая информация как:

технические характеристики оборудования;

параметры эксплуатации;

результаты ремонта;

наличие и движение оборудования.

Подобная информация необходима пользователям добывающих организаций для:

анализа эксплуатации и ремонта;

отслеживания жизненного цикла оборудования;

формирования отчетов в различных срезах;

расследования причин отказов оборудования;

подконтрольной эксплуатации;

В результате работ добывающих организаций ОАО «НК «Роснефть» получает необходимое количество информации для:

проведения анализа эксплуатации оборудования;

формирования рейтингов;

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

Жизненный цикл ИС «ЭПОС» построен на основе спиральной модели, которая предполагает постоянное развитие информационной системы. Благодаря этому и тому, что ИС «ЭПОС» является собственной разработкой Компании, есть возможность интегрировать в ИС «ЭПОС» дополнительные подсистемы, модули и расширять тем самым функционал системы, адаптируя ее под новые нужды пользователя.

Архитектура информационной системы «ЭПОС» представлена на рис. 4. Архитектура ИС «ЭПОС» построена по принципу «клиент-сервер». Клиентское приложение тиражируется на множество рабочих мест различных подразделений и предприятий.

Клиентская часть системы учёта оборудования «ЭПОС» содержит 7 элементов:

подсистема связи с СУБД;

модуль кэширования;

подсистема формирования отчетов;

подсистема управления конфигурациями;

подсистема ввода и редактирования данных;

подсистема безопасности;

пользовательский интерфейс.

Рис. 4. Архитектура ИС «ЭПОС»

Серверная часть ИС «ЭПОС» содержит СУБД и специально разработанный API для взаимодействия клиентских приложений с СУБД. СУБД используется в зависимости от предприятия, в котором работают с «ЭПОС». API взаимодействует с клиентскими приложениями через компьютерную сеть, связывающую разные предприятия.

Пример графического интерфейса ЭПОСа представлен на рис. 5.

Рис. 5. Графический интерфейс ЭПОСа

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



2. Обзор аналогов

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

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

В данном разделе описаны наиболее схожие по функционалу подсистемы оповещения, используемые в различных информационных системах.

2.1 Подсистема оповещений и уведомлений системы «Дело»

«Подсистема оповещений и уведомлений» предназначена для автоматической рассылки уведомлений и оповещений в электронную почту пользователей о различных событиях системы электронного документооборота (СЭД) «ДЕЛО»[9].

Рассылка оповещений производится всем пользователям системы «ДЕЛО», в соответствии с их правами и должностями. «Подсистема оповещений и уведомлений» обеспечивает рассылку оповещений при следующих событиях:

пересылка регистрационной карточки;

отправка документа внутреннему адресату;

ввод поручения;

редактирование поручения;

ввод отчета об исполнении поручения;

направление регистрационной карточки проекта документа на визирование;

направление регистрационной карточки проекта документа на подпись.

«Подсистема оповещений и уведомлений» обеспечивает уведомление пользователей системы «ДЕЛО» о приближении сроков исполнения ими действий по следующим событиям:

исполнение поручения;

контроль поручения;

визирования документа;

подписание документа.

Уведомления направляются пользователям системы до тех пор, пока не истечет плановый срок исполнения операции, либо пока не произойдет фактическое исполнение операции.

Периодичность отправки уведомлений определяется в настройках параметров подсистемы.

По истечении планового срока, выделенного для исполнения операции, уведомления пользователю направляются ежедневно, вплоть до фактического исполнения операции «Производственный календарь».

Периодичность рассылки уведомлений по каждому из событий может быть задана отдельно. Обеспечена возможность задавать периодичность рассылки с указанием, в какие именно дни следует направлять первое, второе и так далее уведомления.

Место подсистемы оповещения в СЭД «Дело» изображено значком на рис. 6.



Рис. 6. Подсистема оповещения в СЭД «Дело»

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

Пример оповещения изображен на рис. 7.

Рис. 7. Пример оповещения в СЭД «Дело»

Так как подсистема «Оповещения и уведомления» интегрирована с «ДЕЛО-Web» (в рассылаемых подсистемой сообщениях размещаются ссылки на регистрационные карточки для открытия через «ДЕЛО-Web»), то необходимо при покупке данной подсистемы приобретать и серверную часть «ДЕЛО-Web».

2.2 Програм Лайн: Уведомления о событиях

Подсистема «Програм Лайн: Уведомления о событиях» была опробована на пилотном проекте в группе компаний «КАМИ» -- крупнейшем в стране поставщике промышленного оборудования. Подсистема была встроена в эксплуатируемую там 1С:УПП. На текущий момент настроено порядка 20 различных уведомлений, сообщения регулярно получают более 100 человек[10].

Подсистема «Програм Лайн: Уведомления о событиях» предназначена для рассылки оповещений пользователям и партнерам о важных событиях в информационной базе, например:

менеджеру - о поступлении оплаты заказа, срыве сроков поставки, приходе нового товара;

клиенту - о готовности его заказа к отгрузке, просроченной задолженности или наступлении срока очередного платежа и так далее.

Принцип работы «Програм Лайн: Уведомления о событиях» изображен на рис. 8.

Рис. 8. Принцип работы «Програм Лайн: Уведомления о событиях»

Обрабатываются два вида событий информационной базы:

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

при периодическом анализе данных -- для напоминания о сроке очередного платежа или просроченном платеже, поздравлении с днем рождения и так далее.

Подсистема встраивается в любую конфигурацию, включая УПП, УТ 10.3, УП 2.0 (ERP), УТ 11, Бухгалтерию и так далее. Встраивание не затрагивает типовые объекты и модули и не оказывает влияния на последующие обновления. Работает с конфигурациями на платформах 1С 8.2 и 8.3. Код полностью открыт для изменений. Пример оповещения представлен на рис. 9.

Рис. 9. Пример оповещения в «Програм Лайн: Уведомления о событиях»

Интерфейс подсистемы проработан для интуитивного освоения, настраивать простые уведомления сможет пользователь, а более сложные -- специалисты поддержки базы 1С.

2.3 Подсистема «Выписка Онлайн» в ДБО BS-Client x64

Подсистема «Выписка Он-Лайн» комплексного решения для дистанционного банковского обслуживания юридических лиц «ДБО BS-Client x64» предназначена для информационного обслуживания клиентов кредитных организаций в сегментах малого и среднего бизнеса[11].

Подсистема «Выписка Он-Лайн» позволяет клиентам банка получать информацию об остатках и выписки по счетам через сеть Интернет в круглосуточном режиме. Данное решение может использоваться банком совместно с другими подсистемами комплексного решения «ДБО BS-Client x64», обеспечивая единое пространство дистанционного обслуживания клиентов по всем сервисам системы «ДБО BS-Client x64».

Место подсистемы «Выписка Он-лайн» в структуре системы «ДБО BS-Client x64» отражено на рис. 10.

Рис. 10. Выписка Онлайн в системе ДБО BS-Client x64

Подсистема «Выписка Он-лайн» функционирует в паре с сервером Нотификации, который обеспечивает хранение данных для оповещений.

«Сервер Нотификации» v. 2 -- это автономный технологический сервис, обеспечивающий автоматическое информирование клиентов банка - юридических и физических лиц - по различным каналам связи[12].

Схема взаимодействия «Сервера Нотификации» изображен на рис. 11.

Рис. 11. Схема взаимодействия «Сервера Нотификации» v. 2

«Сервер Нотификации» v. 2 позволяет банку автоматически информировать клиентов посредством SMS, E-mail, файлового обмена. Система на основе XML-запросов от информационных систем банка (CRM, АБС, ДБО, процессинга и прочее) автоматически генерирует сообщения о поступлении/списании средств, осуществленных операциях в торговой сети, снятии средств в банкомате, изменениях лимита, сроках действия пластиковой карты, других заданных событиях: сроках платежей по кредитам, изменении цен, котировок и прочее.



Вывод

Рассмотренные подсистемы оповещения функционируют в рамках конкретных систем, однако «Програм Лайн: Уведомления о событиях» допускает возможность интеграции благодаря открытости платформы 1С: «Предприятие». В условиях эксплуатации ИС «ЭПОС» возможность интеграции рассмотренных решений отсутствует из-за требований к безопасности ИС «ЭПОС»[3]. Предлагается разработать частную подсистему оповещения для использования ее в ИС «ЭПОС» учитывая опыт разработчиков рассмотренных аналогов.

Сравнить аналоги можно с помощью таблицы 1.

Таблица 1

Сравнительная таблица аналогов

	«Дело»	Програм Лайн	Выписка Он-лайн
Оповещение по Событиям	В области уведомлении Windows	Через Email	Через клиентское приложение, SMS, Email, Web-сайт
Оповещение о заявках	В области уведомлении Windows	Через Email	Нет
Оповещение о задержках	В области уведомлении Windows	Через Email	Нет

У каждого аналога функции реализованы различными способами. Оповещение по Событиям и о заявках подходящим образом реализовано в подсистеме оповещений и уведомления системы «Дело». Оповещение через привычную для пользователя область уведомления Windows положительно скажется на время привыкания пользователя к Подсистеме.

Оповещение через электронную почту, по мнению автора, стоит проводить лишь о сводной информации такой как отчет по задержкам ввода за прошедшие сутки.

Использование SMS приемлемо для экстренных видов оповещения таких как аварии на скважине, порывы трубопровода и подобные. В рамках работы ИС «ЭПОС» такие оповещения не востребованы. Однако возможно в будущем в рамках развития ИС «ЭПОС» потребность в экстренных оповещениях появиться.



3. Постановка задачи

Целью данной работы является - проектирование, разработка и внедрение подсистемы оповещения. Разработанная Подсистема должна устранить ряд недостатков информационной системы «ЭПОС»:

отсутствие возможности отслеживать факты задержек ввода данных по операциям;

отсутствие возможности создавать и отправлять запросы на дополнение и коррекцию данных;

отсутствие оповещения пользователя по Событиям.

Для достижения данной цели необходимо:

изучить предметную область;

изучить ИС «ЭПОС»;

провести обзор существующих подсистем оповещений в различных ИС;

разработать техническое задание на Подсистему;

разработать контур Подсистемы;

разработать инфологическую модель предметной области;

разработать Подсистему;

интегрировать Подсистему с ИС «ЭПОС».

Разработанная Подсистема должна обладать следующими функциями:

оповещение пользователя о новых Событиях;

создание и отправка запроса на коррекцию и дополнение данных;

оповещение пользователя о новых запросах на коррекцию и дополнение данных;

оповещение пользователя о задержках ввода данных.

При внедрении Подсистемы необходимо учесть особенности архитектуры ИС «ЭПОС» и внести изменения в ИС «ЭПОС» для успешной интеграции Подсистемы и ИС «ЭПОС».



4. Контур Подсистемы

Для решения вышеизложенной задачи была спроектирована, разработана и внедрена подсистема оповещения. В результате проектирования было оформлено Техническое Задание на подсистему оповещения, согласно которому Подсистема должна использовать для хранения данных БД целевой системы «ЭПОС» и взаимодействовать с ней имеющимися средствами целевой системы.

Предполагается, что каждое оповещение на одном рабочее место за один сеанс работы пользователя с ИС «ЭПОС» будет возникать однократно, поэтому кэшировать данные для работы Подсистемы не требуется. Таким образом, Подсистема должна встроиться в структуру ИС «ЭПОС» так, как это показано на рис. 12.

На этапе проектирования заказчик потребовал следующие функции:

оповещение пользователя о Событиях;

оповещение пользователя о запросах на коррекцию и дополнение данных;

возможность оформлять и отправлять запросы на коррекцию и дополнение данных;

возможность оформлять подписки на оповещения;

оповещение пользователя о задержках ввода данных.



Рис. 12. Подсистема оповещения в ИС «ЭПОС»

Для обеспечения вышеперечисленных функций в составе Подсистемы предусмотрены следующие модули:

модуль формирования подписки - оформляет подписки на события по выбранному перечню оборудования;

модуль формирования заявок пользователю СП - оформляет заявки на дополнение и коррекцию данных, необходимых для расследования отказов оборудования. Заявки отправляются на хранение в базу данных до востребования модулем опроса базы данных со стороны пользователя сервисного предприятия;

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

модуль оперативного оповещения - активирует графические средства оповещения в пользовательском интерфейсе.

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

Контур Подсистемы представлен на рис. 13.

Рис. 13. Контур подсистемы оповещения

Подсистема взаимодействует с подсистемой связи с СУБД и с пользовательским интерфейсом ИС «ЭПОС». Для внедрения необходимо внести изменения в:

пользовательский интерфейс - добавить формы для формирования подписок и заявок, графические элементы сигнализирования и графические окна просмотра оповещений;

подсистему связи с СУБД - добавить дополнительные модули для связи подсистемы оповещения и СУБД;

API СУБД - добавить дополнительные функции внесения данных по оповещения их извлечения и модификации;

базу данных - дополнить таблицами для сущностей связанных с оповещением.

Изменения в БД, подсистему связи с СУБД и API СУБД подробно описаны в настоящей работе в пункте 6.1, 6.3.1 и 6.3.2 соответственно. Изменения в графическом интерфейсе подробнее описаны в разделе 7.

Данные изменения необходимы для успешной интеграции Подсистемы с ИС «ЭПОС».

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



5. Инфологическая модель предметной области

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

Скважины могут объединяться в группы для подписок по Событиям. Одна скважина может входить в несколько групп. Пользователь может подписываться на несколько групп скважин. Так как одно оповещение по Событиям может адресоваться нескольким пользователям, то статус оповещения устанавливается относительно каждого адресата.

В результате обследования предметной области можно выделить следующие сущности:

скважина;

пользователь;

сервисное предприятие;

события;

группа скважин;

протокол ДК;

запросы.

Инфологическая модель предметной области представлена на рис. 14.

Рис. 14. Инфологическая модель предметной области

Представленная модель оформлена с помощью языка ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). Где стержневые сущности изображены прямоугольниками, ассоциативные - шестиугольниками, характеристические - трапециями, а атрибуты - овалами[4].



6. Виды обеспечения

В данном подразделе представлены изменения в ИС «ЭПОС» необходимые для функционирования Подсистемы и разработанные модули Подсистемы.

6.1 Информационное обеспечение

После нормализации инфологической модели предметной области была получена логическая инфологическая модель Подсистемы. Логическая инфологическая модель представлена на рис. 15.

Рис. 15. Логическая инфологическая модель базы данных

Логическая модель разработана с помощью CASE-средства AllFusion ERwin Data Modeler 7 в нотации IDEF1X.

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для построения концептуальной схемы структуры данных предприятия, независимой от конечной реализации базы данных и аппаратной платформы[5].

С помощью CASE-средство AllFusion ERwin переход от логической модели к физической происходит достаточно легко[6]. Благодаря данной возможности задача модификации существующей базы данных ИС «ЭПОС» не вызвала затруднений. Физическая инфологическая модель Подсистемы представлена на рис. 16. В качестве СУБД было использовано MS SQL Server 2008 R2, которое обеспечивает управление данными ИС «ЭПОС» на сервисных предприятиях ООО «Юганскнефтегаз». Так как в базе данных ИС «ЭПОС» информация о пользователях уже имеется, то таблицу USERS создавать нет необходимости.

Для рассылки по электронной почте используется компонент СУБД - Database Mail.

Компонент Database Mail -- это решение уровня предприятия для отправки сообщений электронной почты от компонента SQL Server Database Engine. Используя компонент Database Mail, приложения базы данных могут отправлять почтовые сообщения пользователям. Сообщения могут содержать результаты запроса, а также могут включать файлы из любого сетевого ресурса. Компонент Database Mail спроектирован для надежности, масштабируемости, безопасности и простой поддержки[14].

Рис. 16. Инфологическая модель Подсистемы



Физическая инфологическая модель

Подсистемы содержит в себе таблицы:

NOTIFY_LIST_WELLS - таблица групп со скважинами для подписок. Она необходима для хранения информации о группах скважин для подписки. Список атрибутов таблицы NOTIFY_LIST_WELLS описан в табл. 2. Менять значения параметров подписки может только автор. Группы с указанным параметром «Общая группа», доступны для подписки всем пользователей, иначе оповещение будет приходить только автору группы.

Таблица 2

Описание атрибутов таблицы NOTIFY_LIST_WELLS

Атрибут	Тип данных	Описание	FK	PK	Ограничение целостности
LIST_ID	счетчик	Идентификатор перечня	Нет	Да	NOT NULL (уникальное значение)
LIST_NAME	текстовый	Наименование перечня скважин	Нет	Нет	NOT NULL (<255 символов)
OWNER	текстовый	Автор перечня	Да	Нет	NOT NULL (<255 символов)
CDS_STOP	логический	Потери и остановки	Нет	Нет	NOT NULL
EPOS_DEMOUNT	логический	Демонтаж	Нет	Нет	NOT NULL
EPOS_DISASM	логический	Разбор	Нет	Нет	NOT NULL
SUBS_DATE	дата	Дата подписки	Нет	Нет	NOT NULL (<Текущей даты)
SHARED	логический	Общая группа	Нет	Нет	NULL

QUALITY_DAY_REC - таблица протоколов дня качества, она необходима для хранения данных о протоколах дня качества. Список атрибутов таблицы QUALITY_DAY_REC описан в табл. 3. Таблица связана с таблицами NOTIFY_EVENTS и NOTIFY_REQUEST_DATA



Таблица 3

Описание атрибутов таблицы QUALITY_DAY_REC

Атрибут	Тип данных	Описание	FK	PK	Ограничение целостности
QUALITY_DAY_REC_ID	Счетчик	Идентификатор протокола	Нет	Да	NOT NULL (уникальное значение)
QUALITY_DAY_REC_DATE	дата	Дата создания протокола	Нет	Нет	NOT NULL (<Текущей дату)
EVENT_ID	числовой	Идентификатор События	Да	Нет	NOT NULL
STOP_YMD	дата	Дата отказа скважины	Нет	Нет	NOT NULL (<Текущей даты)

WELL - таблица сущности «скважина», она необходима для хранения данных о скважинах. В таблице хранятся данные о местонахождении скважины. Список атрибутов таблицы WELL описан в табл. 4.

Таблица 4

Описание атрибутов таблицы WELL

Атрибут	Тип данных	Описание	FK	PK	Ограничение целостности
WELL_ID	числовой	Идентификатор скважины	Нет	Да	NOT NULL (уникальное значение)
OILWELL	текстовый	Имя скважины	Нет	Нет	NOT NULL (<30 символов)
REGION	текстовый	Регион	Нет	Нет	NOT NULL (<30 символов)
OIL_FIELD	текстовый	Месторождение	Нет	Нет	NOT NULL (<30 символов)
WELL_CLUSTER	текстовый	Куст	Нет	Нет	NOT NULL (<30 символов)
SHOP	текстовый	Цех	Нет	Нет	NOT NULL (<30 символов)
NOTE	текстовый	Примечание	Нет	Нет	NULL (<255 символов)
KIT_PO_NUMBER	текстовый	Номер комплекта ПО	Нет	Нет	NULL (<30 символов)

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

NOTIFY_EVENTS - таблица событий, связанных со скважинами. Список атрибутов таблицы NOTIFY_EVENTS описан в табл. 5. Информация данной таблицы используется при оповещении по Событиям.

Таблица 5

Описание атрибутов таблицы NOTIFY_EVENTS

Атрибут	Тип данных	Описание	FK	PK	Ограничение целостности
EVENT_ID	числовой	Идентификатор события	Нет	Да	NOT NULL (уникальное значение)
WELL_ID	числовой	Идентификатор скважины	Да	Нет	NOT NULL
EVENT_DATE	дата	Дата события	Нет	Нет	NOT NULL (<текущей даты)
STOP_REASON_TYPE	текстовый	Причина остановки	Нет	Нет	NULL (<150 символов)
OPERATION_ID	числовой	Операция в ЭПОС	Нет	Нет	NULL
MPR	числовой	Межремонтный период	Нет	Нет	NULL (>0)
MODUFY_DATE	дата	Дата модификации записи в ЭПОС	Нет	Нет	NULL (<текущей даты и >EVENT_DATE)
EVENT_TYPE_ID	числовой	Идентификатор типа события	Да	Нет	NULL

NOTIFY_ACTIVE_EVENTS - таблица, хранящая информацию об оповещении пользователя о событии. Список атрибутов таблицы NOTIFY_ACTIVE_EVENTS описан в табл. 6. Оповещение о Событие может приходить нескольким пользователям и в разное время. После получения оповещения пользователь может сменить статус События относительно себя. В зависимости от статуса оповещения могут приходить повторно или приходить только при изменении информации о Событии. Хранить время изменения статуса События нет необходимости.

Таблица 6

Описание атрибутов таблицы NOTIFY_ACTIVE_EVENTS

Атрибут	Тип данных	Описание	FK	PK	Ограничение целостности
EVENT_ID	числовой	Идентификатор события	Да	Да	NOT NULL (>0)
STATUS_ID	числовой	Идентификатор статуса	Да	Нет	NOT NULL (>0)
USER_NAME	текстовый	Имя пользователя	Нет	Да	NOT NULL (<30 символов)

NOTIFY_REQUEST_DATA - таблица запросов на дополнение или коррекцию данных. Запись имеет ссылку на протокол Дня качества, откуда можно получить информацию о Событии и скважине, по которым необходимо дополнить или скорректировать данные. Сотрудники отдела качества должны иметь возможности отслеживать изменения статуса запроса, для этого необходимо хранить информацию об авторе запроса и дату выполнения запроса. Список атрибутов таблицы NOTIFY_REQUEST_DATA описан в табл. 7.

Таблица 7

Описание атрибутов таблицы NOTIFY_REQUEST_DATA

Атрибут	Тип данных	Описание	FK	PK	Ограничение целостности
REQUEST_ID	числовой	Идентификатор запроса	Нет	Да	NOT NULL (уникальный)
QUALITY_DAY_REC_ID	числовой	Идентификатор протокола Дня Качества	Да	Нет	NOT NULL
REQUEST_STATE_ID	числовой	Статус запроса	Да	Нет	NOT NULL
NOTIFY_REQUEST_TYPE_ID	числовой	Тип запроса	Да	Нет	NOT NULL
REQUEST_DATE	дата	Дата запроса	Нет	Нет	NOT NULL (<текущей даты)
REQUEST_AUTHOT	текстовый	Автор запроса	Да	Нет	NOT NULL (<30 символов)
SERVICE_ENTERPRISE_ID	числовой	Сервисное предприятие	Да	Нет	NOT NULL
REQUEST_COMMENT	текстовый	Комментарий	Нет	Нет	NULL (<4000 символов)
REQUEST_COMPLETE_DATE	дата	Дата выполнения запроса	Нет	Нет	NULL (<текущей даты)

А так же используется ряд справочников:

DIC_SERVICE_ENTERPRISE - таблица сервисных предприятий;

NOTIFY_INPUT_OPR_PREFS - таблица, хранящая информацию о том, что нужно ли оповещать пользователя о несвоевременном вводе данных;

NOTIFY_LIST_WELL_SET - таблица отношения скважин к группе;

DIC_NOTIFY_STATUS - справочник статусов оповещения;

DIC_NOTIFY_EVENT_TYPE - справочник типов события;

DIC_NOTIFY_REQUEST_TYPE - справочник типов запроса;

DIC_NOTIFY_REQUEST_STATE - справочник статусов запроса;

NOTYFY_INPUT_OPR_TYPES - таблица максимально допустимых задержек ввода данных;

DIC_OPERATION_TYPE - справочник типов операций;

NOTIFY_REQUEST_DATA_FILTERS - таблица, хранящая информацию о фильтрации запросов.

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

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

6.2 Математическое обеспечение

В Подсистеме используется формула для расчета времени задержки ввода данных:

Оповещение о несвоевременности ввода данных формируется по правилу:

где Z - допустимая задержка ввода данных, определяемая каждым пользователем индивидуально.

Алгоритм Подсистемы работает в зависимости от категории пользователя. Для сотрудников сервисных предприятий выводятся оповещения по заявкам на дополнение или коррекцию данных для отдела качества добывающей организации. При наличии необработанных заявок пользователь ответственный за данные получает оповещение о том, что нужно внести требуемые данные или скорректировать их. Если данные по заявке не были внесены или скорректированы, то оповещение повторно приходит пользователю с определенной периодичностью пока данные не будут внесены или скорректированы.

Блок-схема алгоритма работы подсистемы оповещения изображена на рис. 17.

Рис. 17. Алгоритм работы Подсистемы

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

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

Сотрудники отдела качества в процессе работы формируют подписки на события связанные с определенным перечнем оборудования. При регистрации в системе «ЭПОС» таких событий, сотрудники отдела качества получают оповещения об этом по их подписке. Кроме подписок пользователи формируют заявки для сотрудников сервисных предприятий на коррекцию или дополнение данных.

6.3 Программное обеспечение

В данном подразделе описаны изменения, которые необходимо внести в подсистему связи с СУБД и API СУБД, а также описаны модули Подсистемы.

Изменения и модули Подсистемы разработаны с помощью среды разработки Microsoft Visual Studio 2008. Внесения изменений и интеграция Подсистемы с ИС «ЭПОС» были проведены на одном из этапов развития целевой системы.

Программа работает на Framework 3.5, поддерживающий операционную систему Windows XP[13]. При внесении изменений в графический интерфейс были использованы пакеты графических компонентов DevExpress. Легкая интеграция Подсистемы с ИС «ЭПОС» была достигнута благодаря системе управления версиями SourceGear Vualt версии 5.1.2. Для тиражирования Подсистемы на рабочие места использовалась ClickOne. СУБД было использовано Microsoft SQL Server 2008 R2. Изменения в базу данных ИС «ЭПОС» были внесены с помощью среды SQL Server Management Studio.

6.3.1 Подсистема связи с СУБД

Для взаимодействия Подсистемы с СУБД были разработаны и внесены модули:

DataSet_DelayNotifications - оповещение по задержкам ввода данных;

DataSet_EventNotifications - оповещение по событиям;

DataSet_EventNotifications_Lists - список личных групп подконтрольных скважин;

DataSet_EventNotifications_SharedLists - список общих групп скважин;

DataSet_RequestResponce_List - оповещение о запросах на коррекцию и дополнение данных;

DataSet_OPR_Stop - создание запроса на коррекцию и дополнение данных.

Каждый модуль подсистемы связи с СУБД взаимодействует с несколькими процедурами из API СУБД согласно таблице 8

Таблица 8

Описание модулей подсистемы связи с СУБД

Имя модуля	Связанные процедуры в API СУБД
DataSet_DelayNotifications	get_input_monitoring_prefs, set_input_monitoring_prefs
DataSet_OPR_Stop	add_data_request, get_request_receivers, get_data_request_attr
DataSet_RequestResponce_List	add_data_request, update_data_requests_state, rem_data_request, get_request_receivers
DataSet_EventNotifications_SharedLists	get_lists_wells, get_lists_wells_set
DataSet_EventNotifications	get_active_lists_wells, get_events, upd_active_events_status
DataSet_EventNotifications_Lists	get_lists_wells, del_lists_wells, add_lists_wells, upd_lists_wells, upd_lists_wells_set_note, add_lists_wells_set, del_lists_wells_set, get_lists_wells_set

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

6.3.2 API СУБД

Для доступа к данным были разработаны и внесены в ИС «ЭПОС» хранимые процедуры:

get_input_monitoring_prefs - вызов параметров для контроля за задержкой ввода данных;

get_active_lists_wells - запрос данных для оповещения по Событиям;

get_events - запрос данных по событию, выбранной скважины;

get_data_request_attr - получение данных по запросу;

del_lists_wells - удаление группы из подписки;

del_lists_wells_set - удаление скважины из группы подписки;

upd_lists_wells - обновление значений параметров подписки на События;

get_data_request - формирование заявок на коррекцию и дополнение данных;

add_data_request - добавление заявок на коррекцию и дополнение данных;

add_lists_wells - добавление группы скважин;

add_lists_wells_set - добавление скважины в группу подписок;

update_data_requests_state - обновление статуса запроса;

upd_lists_wells_set_note - обновление параметров скважин в подписке;

upd_active_events_status - обновление статуса оповещения по Событиям;

get_request_receivers - получение списка запросов;

rem_data_request - удаление запроса;

get_lists_wells - запрос данных по подписке;

copy_lists_wells - копирование общую группу в список личных групп;

set_input_monitoring_prefs - обновление параметров для настройки подписки на оповещение по задержкам ввода данных;

get_data_requests_count - возвращает количество необработанных запросов;

get_lists_wells_set - управление общими группами подписок.

Разработанные хранимые процедуры обеспечивают операции над данными, хранящимися на сервере СУБД. Подробно хранимые процедуры описаны в таблице 9.

Таблица 9

Описание хранимых процедур

Имя процедуры	Параметр	Описание
set_input_monitoring_prefs	IS_MONITORING_ENABLE (входной параметр)	Включение оповещения о задержках ввода данных
	CRITICAL_DELAY_PERIOD (входной параметр)	Допустимая задержка ввода данных
	MONITOR_OPERATION_TYPE_IDS (входной параметр)	Электронная почта пользователя
get_data_requests_count	CNT (выходной параметр)	Количество необработанных запросов
get_new_events_count	CNT (выходной параметр)	Количество новых Событий
Имя процедуры	Параметр	Описание
get_input_monitoring_prefs	IS_MONYTORING_ENABLE (выходной параметр)	Включение оповещения о задержках ввода данных
	CRITICAL_DELAY_PERIOD (выходной параметр)	Допустимая задержка ввода данных
	EMAIL (выходной параметр)	Электронная почта пользователя
	OPERATION_TYPES (выходной параметр)	Список типов операций для подписки
upd_active_events_status	EVENT_ID (входной параметр)	Идентификатор События
	STATUS_ID (входной параметр)	Идентификатор нового статуса
get_active_lists_wells	ACTIVE_LISTS (выходной параметр)	Список подписанных групп
del_lists_wells_set	LISTS_ID (входной параметр)	Идентификатор группы
	WELL_ID (входной параметр)	Идентификатор удаляемой из группы скважины
add_lists_wells_set	LISTS_ID (входной параметр)	Идентификатор группы
	WELL_ID (входной параметр)	Идентификатор новой в группе скважине
	NOTE (входной параметр)	Комментарий
get_events	FROM_DATE (входной параметр)	Дата «после»
	TO_DATE (входной параметр)	Дата «до»
	LISTS_IDS (входной параметр)	Идентификатор подписанной группы
	IS_HISTORY (входной параметр)	Признак архивных данных
	EVENTS (выходной параметр)	Список Событий
Имя процедуры	Параметр	Описание
upd_lists_wells_set_note	LISTS_ID (входной параметр)	Идентификатор группы
	WELL_ID (входной параметр)	Идентификатор изменяемой скважины
	NOTE (входной параметр)	Новое значение комментариев
	IS_ACTIVE (входной параметр)	Новое значение «подписана»
del_lists_wells	LISTS_ID (входной параметр)	Идентификатор удаляемой группы
add_lists_wells	LISTS_ID (выходной параметр)	Идентификатор новой группы
	LISTS_NAME (входной параметр)	Название новой группы
upd_lists_wells	LISTS_ID (входной параметр)	Идентификатор обновляемой группы
	LISTS_NAME (входной параметр)	Новое имя группы
	CDS_STOP (входной параметр)	Новое значение подписки на события остановки скважины
	EPOS_DEMOUNT (входной параметр)	Новое значение подписки демонтаж скважины
	EPOS_DISASM (входной параметр)	Новое значение подписки разбора скважины
	SHARED (входной параметр)	Новое значение «общая группа»
copy_lists_wells	SRC_LISTS_ID (входной параметр)	Идентификатор группы из источника
	DST_LISTS_NAME (входной параметр)	Имя группы
	DST_LISTS_ID (входной\выходной параметр)	Новый идентификатор группы
	NAME_EXISTS (выходной параметр)	Сигнал о совпадении идентификаторов группы
Имя процедуры	Параметр	Описание
get_data_requests	quality_day_rec_id (входной параметр)	Идентификатор дня качества
	data_requests (выходной параметр)	Список запросов
get_lists_wells	IS_OWNER (входной параметр)	Является ли пользователь автором подписки
	ALL_SHARED (входной параметр)	Только общие группы
	LIST_WELLS (выходной параметр)	Список групп скважин
get_lists_wells_set	LISTS_ID (входной параметр)	Идентификатор группы
	LISTS_WELL (выходной параметр)	Список скважин из группы
add_data_request	DATA_REQUEST_ID (выходной параметр)	Идентификатор созданного запроса
	QUALITY_DAY_REC_ID (входной параметр)	Идентификатор протокола «Дня качества»
	SERVICE_ENTERPRISE_ID (входной параметр)	Идентификатор сервисного предприятия
	REQUEST_TYPE_ID (входной параметр)	Идентификатор типа запроса
	REQUEST_COMMENT (входной параметр)	Комментарий к запросу
update_data_requests_state	DATA_REQUEST_IDS (входной параметр)	Идентификатор изменяемого запроса
	REQUEST_STATE_ID (входной параметр)	Идентификатор нового статуса запроса
rem_data_request	DATA_REQUEST_ID (входной параметр)	Идентификатор удаляемого запроса
get_request_receivers	RESULT (выходной параметр)	Список запросов
	SERVICE_ENTERPRISE_ID (входной параметр)	Идентификатор сервисного предприятия

Использование хранимых процедур позволяет снизить нагрузку на компьютерную сеть и упрощает разработку клиентских приложений[8].

6.3.3 Модуль опроса базы данных

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

6.3.4 Модуль оперативного оповещения

Для оперативного оповещения пользователя о Событиях в модуле используется класс EventNotifications. Класс описывает правила, в соответствии с которым требуется активировать графический элемент пользовательского интерфейса, а именно:

если количество событий находится от 1 до 8 включительно, то вывести в правом нижнем углу экрана значок в форме красного круга с цифрой в центре, соответствующей количеству событий;

если количество событий больше 9, то вывести в правом нижнем углу экрана значок в форме красного круга с символом «>9» в центре;

если курсор мыши наведен на графический элемент, то отразить рядом с курсором сообщение «ЭПОС: Оповещение о событиях».

Инициализация класса происходит только по сигналу из модуля опроса базы данных. Листинг класса EventNotifications представлен в приложении 1.