Гайсаров Р.Н. (ТПП Урайнефтегаз)

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

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

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

ПС оперирует большим объемом информации по различным показателям геологоразведочных работ. Выбор Visual FoxPro 6.0 как среды разработки обусловлен необходимостью эффективной работы с данным объемом информации.

Visual FoxPro 6.0 среда разработки, основанная на RAD-технологии и эффективная СУБД.

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

АНАЛИЗ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ

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

1.1. RAD — технологии. Правильное использование RAD

RAD — системы — это системы, ускоряющие процесс проектирования и раз¬вития приложений. Многие из таких систем базируются на виртуальных технологиях. Это значит, что пользователь создает интерфейс своей программы (в виде кнопок, полей ввода и т.п.), просто расставляя элементы в окне/окнах программы (здесь используется терминология системы Windows). В дальнейшем система сама генерирует исходный код прикладной программы и либо использует его как источник данных для интерпретатора, либо может скомпилировать его в код, исполняемый непосредственно процессором. При этом вся работа по контролю за логикой работы приложения возлагается на программиста.

«RAD — это управляемая разработка наращиваемой прикладной системы за короткое время». Это наиболее емкое определение систем «быстрой разработки приложений».

Обычно к RAD — средствам относят любое программное средство, обеспечивающее помощь в разработке ПО, его сопровождении или деятельности по управлению проектом и проявляющее следующие дополнительные черты:

• хорошо развитая графическая оболочка для построения систем ПО, а также для создания интерфейса с пользователем;
• использование компьютерного хранилища (репозитория) для всей инфор¬мации о проекте для разделения между разработчиками и исполнителями как основа продуцирования ПО и повторного его использования в будущих проектах;

Кроме этого в основе RAD — средств лежат следующие положения:

1. Широкое использование базовых программных средств, получивших массовое распространение в других приложениях;
2. Ограничение сложности, позволяющее получать компоненты, поддающиеся управлению, обозримые и доступные для понимания, а также обладающие простой и ясной структурой;
3. Доступность для разных категорий пользователей;
4. Рентабельность;
5. Человеческий фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс;
6. Сопровождаемость, способность адаптации при изменении требований и целей проекта.

Под RAD часто подразумевают торопливую разработку приложения и раздача его пользователям в надежде, что оно будет работать. На самом деле нужно, чтобы приложение разрабатывалось быстро, но было «настраиваемым, работоспособным, удобным в эксплуатации и хорошо документированным».

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

Итеративную разновидность RAD, вероятно, можно использовать совместно со структурными методами и инструментальными средствами разработки, но большинство пользователей склоняется к объектно-ориентированному подходу, который сам напрашивается для использования рабочими группами. Кроме того, объектно-ориентированный подход может ускорить процесс разработки за счет обеспечиваемого им многократного использования компонентов. Если используются структурные методы, то попытка разделить разработку на отдельные части оказывает очень сильное влияние на уже проделанную часть работы.

Иногда RAD пытаются представить самостоятельной методологией, но это просто подход, который охватывает весь цикл разработки.

Чтобы RAD был более формализованным и управляемым, нужно сформулировать все элементы и требования подхода RAD. Никакой конкретной технологии при этом не предписывается, т. е. не говорится, что вы должны использовать СУБД Oracle, среду разработки клиентских программ для баз данных Powerbuilder, или что-либо еще.

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

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

CASE — системы отличаются тем, что позволяют проектировать приложе¬ние на концептуальном уровне. При этом основной упор делается на принцип концептуального проектирования предметной области. Это означает, что в предметной области выделяются некоторые составляющие (концепты), а также связи между ними и после этого такая сетевая структура переносится в информационную область описания. Концепты, перенесенные в информационную область, должны сохранять характеристики, присущие составляющим предметной области. В отличие от RAD — систем, CASE — системы, в которых процесс генерации исходного текста программы не является основным, не просто автоматизируют процесс разработки приложения, они определяют корректность определений сущностей, взаимосвязей, процессов и состояний сущностей внутри проектируемой системы, а также направляют работу разработчика путем частичного ограничения свободы действий при разработке, сохраняя таким образом логику системы. Эти свойства CASE — систем привлекательны, но в данном случае мало применимы, потому что поставленная задача требует разработки некоторых концептов предметной области как отдельных объектов и четко определить их свойства.

Но представленные объектно-ориентированные технологии имеют целый ряд общих достоинств:

1. Упрощение внесения изменений.
2. Гибкая архитектура и переносимость.
3. Повторное использование программных компонент.
4. Естественность описания проекта.

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

1.2. OLE — автоматизация

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

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

Более удобной реализацией программируемости настольных приложений было бы наличие в них возможности предоставлять свои сервисы другим приложениям с помощью универсального механизма, не зависящего от встроенных макроязыков и позволяющего, в частности, использовать обычные языки программирования. Именно для этой цели и предназначен механизм, называемый автоматизацией (Automation). В этом случае приложение, предоставляющее тот или иной сервис, использует для этой цели интерфейсы содержащихся внутри его адресного пространства COM-объектов и называется сервером автоматизации. Приложение, использующее сервис, называется контроллером автоматизации и может быть написано с помощью подавляющего большинства современных средств разработки. Отметим, что серверами автоматизации являются, в частности, такие популярные приложения, как Microsoft Office (Word, Excel, PowerPoint), Microsoft Internet Explorer и даже сама оболочка Windows 95/98/NT.

В общем случае клиент и сервер находятся в разных адресных пространствах и, соответственно, для управления сервером клиент должен обращаться к методам объектов, находящихся в другом адресном пространстве. Для этой цели используется технология LRPC (Local Remote Procedure Calls — локальные вызовы удаленных процедур).

Каждый COM-сервер (каковым является сервер автоматизации) и каждый класс COM-объектов обладает уникальным 128-битовым идентификатором GIUD (Global Unique Identifier). При обращении к классам COM-объектов он иногда называется CLSID (идентификатор класса). При создании COM-серверов (в том числе и серверов автоматизации) GUID и CLSID генерируются автоматически, хотя при необходимости можно сгенерировать их с помощью вызова стандартной функции Windows API CoCreateGUID. Информация обо всех COM-серверах и классах COM-объектов хранится в системном реестре, что позволяет клиенту «не знать», в каком каталоге (или на каком компьютере локальной сети) находится COM-сервер.

В общем случае COM-сервер представляет собой приложение, которое создает COM-объект и делает его доступным для других программ. Сервер автоматизации предоставляет для доступа объект специального типа — dispatch object. При этом в адресном пространстве приложения-контроллера, управляющего сервером, присутствует вариантная переменная, содержащая интерфейс IDispatch, открывающий предоставляющий доступ к этому объекту на COM-сервер.

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

Библиотека типов

Что представляет собой библиотека типов и зачем она нужна? По существу, библиотека типов представляет собой двоичный файл с описанием интерфейсов COM-объекта и их методов.

Обычно такие описания создаются с помощью специального языка IDL (Interface Definition Language) и используются для того, чтобы разработчики знали, как создать код, реализующий методы COM-объекта (или вообще методы объекта, расположенного за пределами адресного пространства разрабатываемого приложения, так как IDL используется не только в COM-технологии, но и в иных технологиях, реализующих вызовы удаленных процедур или функций, например, CORBA). Помимо этого, описания методов на языке IDL могут быть использованы для автоматической генерации серверного и клиентского кода (так называемого proxy-кода и stub-кода) с помощью соответствующих утилит.

С другой стороны, proxy-код и stub-код могут быть сгенерированы динамически. В этом случае клиент должен динамически получать информацию о свойствах и методах интерфейсов COM-объекта, и в этом случае наличие библиотеки типов, содержащей такую информацию, может быть весьма удобно. Отметим, что библиотеку типов можно в принципе сгенерировать на основе описания на языке IDL с помощью специального компилятора MIDL, но в данном случае в этом нет необходимости.

Исходя из вышеизложенного, можно сделать вывод: наиболее оптимальным подходом для реализации поставленной задачи разработки программной системы, включающей в себя широкий спектр задач, решаемых с помощью программирования, является подход, основанный на правильном применении RAD – технологии. Наиболее оптимально сочетает в себе необходимые для проектирования ПС свойства – RAD-система Visual Foxpro.

В представленной работе, основываясь на анализе требований, необходимо произвести автоматизацию COM-сервера Excel.Application для создания отчетов в формате Excel. Используя возможности, предоставляемые разработчику средой Visual Foxpro, можно реализовать данную задачу без особых трудозатрат.

РАЗРАБОТКА ПРОГРАММНОЙ СИСТЕМЫ

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

Задача: автоматизация обработки данных по геологоразведочным работам.

Цель: разработка программной системы для автоматизации обработки данных, формирования отчетности по ГРР, хранения и контроля необходимой информации.

Требования к ПС

1. Формат данных – Visual FoxPro.
2. Платформа Windows 95/98/NT/2000.
3. Среда разработки Visual FoxPro 6.0.
4. Режимы работы ПС: ввод, редактирование и просмотр данных;настройка справочников; расчет данных по скважине (сумма затрат по проведенным работам, глубина забоя, суммарный вынос керна, суммарная проходка с отбором керна); расчет данных по прочим и плановым работам (сумма по кварталам и годовая).
5. Формирование отчетов за период.Отчеты в формате Excel.Детализация по Андреевскому участку.Отчеты по всем объектам деятельности (физические показатели, финансовые показатели, плановые и фактические цифры).Формирование запросов к БДПоиск по номеру скважин.Поиск по номеру сейсмопартии.Работа с базой данных.

   Резервное копирование данных и шаблонов отчетов.

   Переиндексация базы.

   Восстановление базы данных.

   Восстановление шаблонов отчетов.

   «Упаковка» баз.

Анализ требований к программной системе

В результате анализа требований заказчика выделены следующие группы входных и выходных данных:

Входные данные

1. БурениеДанные по скважинеНомер и тип скважины (согласно справочнику)Признак «первая» на месторождении или залежиУказание залежи (если есть)Дата бурения (начало, окончание бурения)Проходка за месяц и текущий забойСостояние скважины на дату

   Глубина эксплуатационной колонны

   Суммарная проходка с отбором керна

   Суммарный вынос керна

   План отбора керна

   Стоимость работ общая

   Стоимость работ по бурению и прочим работам (дата работ, подрядчик)

   Данные по пласту

   Код и название пласта (привязка к скважине)

   Интервалы отбора керна (верхний, нижний уровень)

   Длина интервала отбора керна

   Вынос керна

   Проходка по песчанику

   Вынос песчаника

   Признак нефти

2. ИспытаниеДата испытанияСпособ испытанияТип перфоратораПерфорационная средаИнтервал испытания (верхний, нижний уровень)Результаты испытанийПризнак «сухо»

   Нефть

   Вода

   Газ

   Динамический уровень

   Депрессия

   Диаметр штуцера

   Давление пластовое

   Прирост запасов С₁ и С₂

3. СейсмикаДанные по ВСП (привязка к площадям)Дата проведения работНомера скважинПодрядчикСумма затратКоличество скважинДанные по 2D (привязка к площадям)

   Дата проведения работ

   Номер сейсмопартии

   Подрядчик

   Сумма затрат

   Объем работ (пог. км)

   Данные по 3D (привязка к площадям)

   Дата проведения работ

   № сейсмопартии

   Подрядчик

   Сумма затрат

   Объем работ (кв. км)

   Данные по «Крестам» (привязка к площадям)

   Дата проведения работ

   Номер сейсмопартии

   Подрядчик

   Сумма затрат

   Объем работ (пог. км)

4. Прочие показателиГодСписок работ (привязка к году), по месяцам вводятся финансовые (план, факт) затраты на проведение работ. Группировка по месяцам, кварталам, итоговые цифры за год.
5. Плановые цифрыГодСписок физических и финансовых показателей (привязка к году), по месяцам вводятся плановые цифры. Группировка по месяцам, кварталам, итоговые цифры за год.
6. СправочникиСправочник залежейСправочник подрядчиков по сейсмикеСправочник подрядчиков по буровым работамСправочник способов испытанийСправочник пластовСправочник процента НДС

Выходные данные

Отчеты вида:

Андреевский участок:

• Справка по 2Д
• Справка по 3Д
• Справка по ВСП
• Справка по строительству скважин

1. Изученность территории
2. Итоги ГРР
3. Итоги ГРР (полугодия)
4. Итоги ГРР (с прочими работами)
5. Керн
6. Общий прирост
7. Открытия
8. Прирост по скважинам
9. Реестр работ
10. Результаты бурения
11. Сведения об испытаниях
12. Сведения о поисково-разведочном бурении
13. Сводный отчет
14. Сейсморазведка
15. Скважины, законченные строительством
16. Физические объемы
17. Форма ГРМ — месячная
18. Эффективность ГРР

Проектирование и реализация

Этап проектирования программной системы требует более детального описания (описания на логическом уровне) ее входных, выходных данных и функций. Для реализации программной системы использована среда Visual Foxpro 6.0 и СОМ- сервер Excel.Application, а также дополнительные ActiveX компоненты.

Объекты и их характеристики

1. Бурение на скважинах

Основными объектами здесь являются месторождения, которые имеют название, площадь (кв. км), дополнительные параметры.

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

Каждой скважине присваивается номер (согласно стандарту UWI), тип (разведочная, нефтяная, поисковая и т.д. в соответствии со справочником типов скважин), принадлежность к залежи (в соответствии со справочником залежей), дата начала и окончания бурения, стоимость работ, план отбора керна и признак – является ли данная скважина первооткрывательницей на месторождении или залежи.

В состав скважины входят пласты, каждый из которых имеет название (в соответствии со справочником пластов), отношение «пласт – скважина» описывается как «многие к одному».

К пласту также относится информация по интервалам отбора керна. На одном пласте может быть несколько интервалов, отношение «интервал отбора керна – пласт» описывается как «многие к одному».

Структура данных строится по древовидному принципу, где объектами являются:

• 1-й уровень – месторождения;
• 2-й уровень – скважины, залежи;
• 3-й уровень – пласты.

Для ее реализации использован ActiveX компонент TreeView (см. рис.1).

Рис.1. Данные по бурению

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

Основные данные по месторождению MEST.dbf

Основные данные о скважине SKV.dbf

Данные о проходке и состоянию скважины SKVINFO.dbf

Данные о бурении по пластам BURENIE.dbf

Финансовые показатели по бурению COST.dbf

2. Проведение испытаний на скважинах

Структура данных здесь такая же, как и структура данных по бурению (см.рис.2). Отличие состоит в том, что к пластам в данном случае относятся периоды испытании. Отношение «период испытание – пласт» описывается как «многие к одному».

Испытания характеризуются следующими показателями: пласт, на котором проводятся испытания. На каждом пласте может быть проведено несколько испытаний, каждое испытание различают по датам начала и конца испытания (PERIOD_IS.dbf->DATA_N, DATA_K). На одну дату испытаний может быть несколько интервалов испытания, интервал испытания описывается верхней и нижней границей интервала (ISP.dbf->INT_IS_V, INT_IS_N).

Рис.2. Данные по испытанию

Основные данные о проведении испытаний на скважине записываются в таблицу PERIOD_IS.dbf.

 

Интервалы испытаний записываются в таблицу ISP.dbf.

 

3. Сейсморазведка

Объектами проведения работ по сейсморазведке являются площади. Данные на экране представлены в виде «дерева». Работы по сейсмике привязаны к площадям. Отношение «работы — площадь» описывается как «многие к одному».

Рис.3. Данные по сейсморазведочным работам

Работы по сейсморазведке делятся на следующие категории:

• ВСП
• 3D
• 2D
• «Кресты»

а) Фактические показатели по сейсморазведке

В ВСП вводятся и хранятся данные о дате проведения работ (месяц, год), номер скважины, название подрядчика и стоимость работ. В 2D, «Крестах» и 3D находится информация о дате проведения работ (месяц, год), номере сейсмопартии, названии подрядчика, стоимости работ и объеме произведенных работ (2D и «Кресты» — в погонных километрах, 3D – в квадратных километрах).

Данные по ВСП VSP.dbf

Данные по 3D 3D.dbf

Данные по 2D 2D.dbf

Данные по «Крестам» KREST.dbf

б) Плановые показатели по сейсморазведке

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

Рис.4. Данные по плановым показателям

4. Прочие работы

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

Рис.5. Фактические и плановые цифры по прочим работам

Данные по прочим работам WORKS.dbf

Рис.6. Диаграмма связи основных таблиц

Выводы

Для реализации программной системы использована среда Visual FoxPro 6.0 и предлагаемый ею набор стандартных компонентов. Для отображения данных в виде «дерева» использован компонент ActiveX TreeView. Для удобства в использовании пользователь осуществляет работу с данными при помощи контекстных меню. Также ему предоставлена возможность настройки справочников. По требованию заказчика возможен поиск скважин и сейсмопартий по их номеру, отображение данных в прочих и плановых показателях как по месяцам, так и по кварталам с итоговой суммой за год (в прочих показателях кроме этого отображаются либо только фактические данные, либо только плановые, либо и те и другие одновременно). Для сохранности рабочих таблиц программа при запуске проверяет наличие других запущенных копий самой себя и при обнаружении выдает соответствующее сообщение о повторном запуске.

В программе предусмотрена возможность переиндексации, резервного копирования и восстановления баз данных. По завершении работы с программой рабочие таблицы автоматически «упаковываются». Вся отчетность формируется в формате Excel. В папке Shablons хранятся настроенные для печати шаблоны отчетов. Каждый шаблон настроен по стандарту заказчика и может быть модифицирован в связи с изменившимися требованиями. При повреждении или случайном удалении рабочих шаблонов они заменяются резервными копиями. Готовые отчеты сохраняются в папке Reports.

В настоящее время программа установлена в отделе РиМСБ и находится на стадии промышленной эксплуатации.

Преимущества программной системы:

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

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

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

Экономическая эффективность программы состоит в уменьшении рабочего времени и трудозатрат на обработку информации. Если раньше на сбор сведений и формирование отчета в среднем тратилось около одного-двух дней (требовалось время на сбор информации, набивка данных в отчеты), то с применением программы отчеты формируются не более 1 – 2 минут.

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