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

. (2.29)

Для этого случая, когда (p0 = pr), величину a1 найдем следующим образом. Из уравнения (2.7) получаем, что . После чего уравнение (2.29) принимает вид:

. (2.30)

Подставляя в уравнения (2.25) и (2.26) значения pIV, pIII, pII, pI максимально давления, допускаемого при работе агрегата на скоростях IV, III, II, I соответственно, определяем высоты столбов глинистого раствора над верхней пробкой, при которых агрегат должен быть переключен на следующую (меньшую) мощность:

; (2.31)

и т.д.

Для упрощения расчета можно вместо lIV, lIII, lII, lI определять сразу hIV, hIII, hII, hI -- высота столба глинистого раствора, закачиваемого на скоростях IV, III, II, I:

. (2.32)

В общем виде по описанной методике производится расчет гидродинамики цементирования нефтяной скважины.

3. ОПИСАНИЕ СТРУКТУРЫ И ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ ПРОГРАММНОГО КОМПЛЕКСА АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ

3.1 Описание структуры программного комплекса

На основе функциональной модели сформирована структура системы автоматизации проектирования гидродинамики цементирования нефтяных скважин (рисунок 3.1), представленная несколькими взаимосвязанными блоками, каждый из которых поддерживает свой режим работы [19].

Основными блоками системы являются: блок ввода исходных данных; блок расчета параметров цементирования; блок расчета количества и режимов работы цементировочных агрегатов и цементно-смесительных машин; блок расчета гидродинамики процесса цементирования; блок графического моделирования.



Рисунок 3.1 -- Структурная схема системы автоматизации

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

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

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

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

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

Блок расчета количества и режимов работы цементировочных агрегатов и цементно-смесительных машин позволяет на основе расчетных параметров цементирования подобрать количество агрегатов так, чтобы соблюдались все технологические требования при строительстве скважин. Одним из основных критериев выбора является время цементирования, которое не должно превышать 75% времени начала схватывания цементного раствора.

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

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

Работа блока графического моделирования заключается в построении анимационной модели процесса цементирования. Здесь эскиз скважины с обсадными колоннами отображается на экране пользователя, программно масштабируется по глубине и ширине скважины различными масштабами, т.к. диапазон изменения глубины скважины в среднем варьируется от 1000 до 6000 метров, а диапазон изменения диаметра скважины от 0,15 до 0,5 метра. Программа выполняет масштабирование автоматически. Пользователь лишь варьирует скорость протекания процесса.

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

3.2 Состав информационного обеспечения программного комплекса автоматизированного проектирования

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

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

- скважина -- объект расчета и моделирования;

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

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

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

Накопителями данных являются:

- информация о скважинах;

- информация об оборудовании;

- информация о материалах.

Информационная система разбита на четыре логические подсистемы:

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

- система запросов;

- система формирование отчетов;

- система анализа данных.

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

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



Рисунок 3.2 -- Структура базы данных

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

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

Разработанную структуру базы данных можно условно разделить на два уровня:

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

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

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

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

Далее приведено описание компонентов информационной модели.

Таблица «Well» предназначена для хранения информации о скважине, для которой производится проектный расчет. В таблице 3.1 приведена ее структура и назначение полей.

Таблица 3.1 -- Структура таблица БД «Well»

Название поля	Тип поля	Описание
ID_Skv	Длинное целое	Уникальный идентификатор скважины, ключевое поле, счётчик
Name	Текстовый (50)	Наименование скважины
Type	Длинное целое	Идентификатор типа
WC	Длинное целое	Идентификатор способа цементирования

Ключевое поле связано с таблицами базы данных «Count» и «Inklin», информация в записях которых соотносится с соответствующей скважиной.

Таблица «Inklin» хранит сведения об инклинометрии скважины -- глубинах ее участков и углах искривления. Структура таблицы «Inklin» представлена в таблице 3.2.

Таблица 3.2 -- Структура таблица БД «Inklin»

Название поля	Тип поля	Описание
ID	Длинное целое	Уникальный идентификатор записи, ключевое поле, счётчик
ID_Well	Длинное целое	Идентификатор скважины
Depth	Десятичное	Глубина участка скважины
Z_Angle	Десятичное	Зенитный угол
A_Angle	Десятичное	Азимутальный угол

Таблицы «Way_Cem» и «Type_Well» хранят соответственно возможные способы цементирования (прямое, обратное, ступенчатое) и типы скважин (тангенциальная, S-образная, J-образная). Структуры данных таблиц представлены в таблицах 3.3 и 3.4.

Таблица 3.3 -- Структура таблица БД «Way_Cem»

Название поля	Тип поля	Описание
ID_Way	Длинное целое	Уникальный идентификатор способа цементирования, ключевое поле, счётчик
Name	Текстовый (50)	Наименование способа цементирования

Таблица 3.4 -- Структура таблица БД «Type_Well»

Название поля	Тип поля	Описание
ID_Type	Длинное целое	Уникальный идентификатор типа скважины, ключевое поле, счётчик
Name	Текстовый (50)	Наименование типа скважины

Ключевые поля рассмотренных таблиц связаны с соответствующими полями таблицы базы данных «Well», куда по идентификатору передается информация о скважине.

Справочными являются таблицы, хранящие сведения о цементосмесительных машинах «CSM» и цементировочных агрегатах «CemAgr», характеристики буферной жидкости «BF» и бурового раствора «BR». В таблицах 3.5 - 3.8 приведены структуры и назначения полей перечисленных справочников.

Таблица 3.5 -- Структура таблица БД «CSM»

Название поля	Тип поля	Описание
Mash_ID	Длинное целое	Уникальный идентификатор машины, ключевое поле, счётчик
Машина	Текстовый (50)	Наименование машины
Bak	Десятичное	Вместимость мерного бака
Q	Десятичное	Производительность машины

Таблица 3.6 -- Структура таблица БД «CemAgr»

Название поля	Тип поля	Описание
Agr_ID	Длинное целое	Уникальный идентификатор агрегата, ключевое поле, счётчик
Агрегат	Текстовый (50)	Наименование агрегата
Bak	Десятичное	Вместимость мерного бака

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

Таблица 3.7 -- Структура таблица БД «BF»

Название поля	Тип поля	Описание
BF_ID	Длинное целое	Уникальный идентификатор раствора, ключевое поле, счётчик
Раствор	Текстовый (50)	Наименование раствора
J	Десятичное	Плотность
ПФ	Десятичное	Показатель фильтрации
ph	Десятичное	Кислотно-щелочной баланс

Таблица 3.8 -- Структура таблица БД «BR»

Название поля	Тип поля	Описание
BR_ID	Длинное целое	Уникальный идентификатор раствора, ключевое поле, счётчик
Раствор	Текстовый (50)	Наименование раствора
J	Десятичное	Плотность
Вязкость	Десятичное	Условная вязкость
ПФ	Десятичное	Показатель фильтрации
ПВ	Десятичное	Пластическая вязкость
ДНС	Десятичное	Динамическое напряжение сдвига
ПГ1	Десятичное	Прочность геля 10с/10мин
ПГ2	Десятичное	Прочность геля lb/10ft
СНС	Десятичное	Статическое напряжение сдвига
ph	Десятичное	Кислотно-щелочной баланс

Вспомогательными для справочника «CemAgr» являются таблицы «CemAgrWork», хранящая сведения о режимах работы соответствующего цементировочного агрегата, и «Diametrs», содержащая перечень возможных диаметров втулок агрегатов. Ключевое поле таблицы «Diametrs» связано с таблицей базы данных «CemAgrWork» информация в записях которой соотносится с соответствующим диаметром втулки агрегата. В таблицах 3.9 и 3.10 приведены структуры и назначения полей рассмотренных таблиц.

Таблица 3.9 -- Структура таблица БД «CemAgrWork»

Название поля	Тип поля	Описание
ID	Длинное целое	Уникальный идентификатор записи, ключевое поле, счётчик
Agr_ID	Длинное целое	Идентификатор агрегата
Скорость	Длинное целое	Скорость работы
D_ID	Длинное целое	Идентификатор диаметра втулки
Q	Десятичное	Скорость подачи раствора
P	Десятичное	Развиваемое агрегатом давление

Таблица 3.10 -- Структура таблица БД «Diametrs»

Название поля	Тип поля	Описание
D_ID	Длинное целое	Уникальный идентификатор записи, ключевое поле, счётчик
Diametr	Длинное целое	Диаметр втулки агрегата

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

Таблица 3.11 -- Структура таблица БД «Count»

Название поля	Тип поля	Описание
1	2	3
ID_Count	Длинное целое	Уникальный идентификатор расчета, ключевое поле, счётчик
Date	Дата	Дата проведения расчета
ID_FIO	Длинное целое	Идентификатор инженера-проектировщика
ID_Skv	Длинное целое	Идентификатор скважины
Ddol	Десятичное	Диаметр долота
K	Десятичное	Коэффициент кавернозности
PPm	Десятичное	Расстояние до продуктивного пласта
PPP	Десятичное	Пластовое давление
Dn	Десятичное	Наружный диаметр колонны
Dv	Десятичное	Внутренний средний диаметр колонны
h	Десятичное	Высота цементного стакана
Hc	Десятичное	Высота подъема раствора за колонной
ID_BR	Длинное целое	Идентификатор бурового раствора
ID_BF	Длинное целое	Идентификатор буферной жидкости
Kspr	Десятичное	Коэффициент сжатия продавочной жидкости
jpr	Десятичное	Плотность продавочной жидкости
jcr	Десятичное	Плотность цементного раствора
jv	Десятичное	Плотность воды
vcs	Десятичное	Водоцементное соотношение
kp	Десятичное	Коэффициент, учитывающий потери
ID_CA	Длинное целое	Идентификатор цементировочного агрегата
ID_CSM	Длинное целое	Идентификатор цементосмесительной машины
V	Десятичное	Скорость течения цементного раствора в заколонном пространстве
t	Десятичное	Среднегодовая температура
tpz	Десятичное	Продолжительность подготовительно-заключительных работ

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

4. ОПИСАНИЕ ТЕХНОЛОГИИ РЕАЛИЗАЦИИ ПРОГРАММНОГО КОМПЛЕКСА ПО АВТОМАТИЗАЦИИ ПРОЕКТИРОВАНИЯ

4.1 Описание реализации инфологической модели и организации взаимодействия программного обеспечения с базой данных

автоматизированный программный база данные

Разрабатываемый программный комплекс с технологической точки зрения состоит из двух логически раздельных компонент -- базы данных и программы-оболочки. Для их взаимодействия необходимо наличие технологии, обеспечивающей механизм общения приложений с базами данных с интерфейсом системного и прикладного уровней. Но перед выбором таких интерфейсов следует определиться с системой управления базами данных (СУБД), с помощью которой будет реализована спроектированная в подразделе 3.2 инфологическая модель и структура БД.

При таком выборе важным аспектом является то, что создаваемое программное обеспечение согласно технического задания не предназначено для работы в компьютерной сети и будет использоваться для работы в операционной системе MS Windows. Наиболее подходящая СУБД, отвечающей заданным критериям -- MS Access -- реляционная СУБД корпорации Microsoft, в настоящее время являющаяся одной из самых популярных среди настольных (персональных) программных систем управления базами данных. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных [21]. Специфической особенностью СУБД Access является то, что вся информация, относящаяся к одной базе данных, хранится в едином файле, что можно отнести только к положительным характеристикам, т.к. упрощает операцию связывания базы данных с приложением и обеспечивает простоту при переносе данных с одного рабочего места на другое при необходимости.

Для работы СУБД MS Access применяется технологии OLE DB -- интерфейс системного уровня с дополнительным прикладным уровнем, который получил название ADO (ActiveX Data Objects), предназначенным для прикладных задач. Для доступа к источникам данных БД MS Access используется драйвер Microsoft.Jet.OLEDB.4.0 и провайдер Jet 4.0 [21]. Эта технология позволяет создавать как клиент-серверные приложения, когда база данных физически располагается на удаленном сервере данных, так и настольные, когда и база данных и исполнимое приложение находятся на одном компьютере.

Основным достоинством ADO является ее естественная ориентация на создание «облегченного» клиента, т.е. настольного приложения. На машине сервера данных (это может быть файловый сервер в рамках файл/серверной технологии, или машина с сервером данных -- в технологии клиент/сервер, или рабочий компьютер в настольном приложении) устанавливается провайдер данных -- надстройка над специальной технологией OLE DB, распознающая запросы объектов ADO и траснслирующая эти запросы в соответствующие действия с данными. Взаимодействие компонентов ADO и провайдера осуществляется на основе универсальной для Windows технологии ActiveX, причем провайдер реализуется как СОМ-сервер, а ADO-компоненты -- как COM-клиенты даже в рамках одного компьютера.

При создании программы для работы с базой данных следует использовать связанные компоненты-наборы ADOTable, ADOQuery, ADODataSet и ADOConnection. Схема связи данных с объектами ADO в среде разработки приложений Borland Delphi приведена на рисунке 4.1.

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

Рисунок 4.1 -- Схема связи данных с объектами ADO в Borland Delphi

Каждый из перечисленных компонентов может связываться с провайдером данных либо с помощью связного компонента ADOConnection, либо минуя его и используя собственное свойство ConnectionString. Таким образом, ADOConnection играет роль концентратора соединений с источником данных компонентов-наборов. После того, как связь с базой данных установлена, на компонент могут ссылаться другие ADO-компоненты, разделяя установленное соединение.

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

ADOTable -- компонент, способный получать и обслуживать набор данных, состоящий из записей единственной физической таблицы БД, имя которой содержит его свойство TableName. Поскольку, как и все остальные компоненты-наборы, он является надстройкой к базовому объекту Command, он имеет свойство CommandText, которое, однако, недоступно программисту. Значение этого свойства у него формируется автоматически по имени связанной таблицы. Компонент позволяет перемещаться по записям таблицы, считывая их по очереди.

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

Для организации взаимодействия по приёму и передаче данных между базой данных и системой автоматизированного проектирования применяется технология SQL-запросов -- инструкций, выполняющих операции над таблицами. SQL (англ. Structured Query Language -- «язык структурированных запросов») -- универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. С помощью SQL описывается только то, какие данные нужно извлечь или модифицировать. То, каким образом это сделать, решает СУБД непосредственно при обработке SQL-запроса [22].

Каждое предложение SQL -- это запрос или обращение к базе данных, которое приводит к какому-либо изменению в ней. В соответствии с тем, какие изменения происходят в базе данных, различают следующие типы запросов:

- запросы на создание или изменение в базе данных новых или существующих объектов (при этом в запросе описывается тип и структура создаваемого или изменяемого объекта);

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

- запросы на добавление новых данных (записей);

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

- обращения к СУБД.

Самый главный вид запроса -- это запрос, возвращающий пользователю некоторый набор строк, с которым можно осуществить одну из трёх операций:

- просмотреть полученный набор;

- изменить все записи набора;

- удалить все записи набора.

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

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

- SELECT -- считывает данные, удовлетворяющие заданным условиям;

- INSERT -- добавляет новые данные в таблицу;

- UPDATE -- изменяет существующие данные;

- DELETE -- удаляет данные.

На рисунке 4.2 приведен пример запроса на отбор данных, характеризующих работу цементировочного агрегата с кодом «0» при диаметре цементировочной втулки, равном 100 мм.

Рисунок 4.2 -- Пример SQL-запроса на выборку данных

Выбранные средства реализации инфологической модели: интерфейс ADO для взаимодействия прикладной программы с базой данных, СУБД MS Access, компоненты-наборы группы CustomADODataSet и информационно-логический язык SQL -- позволяют наладить надёжную связь оболочки и БД.

4.2 Разработка графического интерфейса программного комплекса

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

В состав графической части системы автоматизированного проектирования входят окна двух типов:

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

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

Главное окно будет содержать все основные стандартные элементы:

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

- управляющее (основное) меню, содержащее имена ниспадающих меню;

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

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

- кнопки системного меню, с помощью которого вызываются команды изменения размеров окна и его перемещения;

- строка состояния, содержащая информацию о режимах работы приложения.

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

- закладка «Цементирование», которая в свою очередь содержит закладки «Скважина», «Колонна», «Жидкости», «Расчет цементирования»;

- закладка «Гидродинамика», содержимое которой распределено на закладки «Агрегаты и условия» и «Расчет гидродинамики»;

- закладка «Моделирование».

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

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

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



Рисунок 4.3 -- Схема главного окна графического интерфейса пользователя: 1 -- заголовок окна; 2 -- главное меню; 3 -- строка состояния; 4 -- закладки рабочего поля, отвечающие за этапы работы программы; 5 -- закладки, отвечающие за режимы работы программы; 6 -- область для элементов управления и отображения информации; 7 -- область для отображения динамической модели; 8 -- кнопки системного меню

Вывод результатов проектного расчета каждого режима работы программы осуществляется в текстовые многострочные поля. Редактирование выводимого текста в них запрещено, текст можно лишь просмотреть, скопировать либо перенести в текстовый редактор MS Word путем нажатия предусмотренной для этого кнопки.

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

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

4.3 Описание лингвистического обеспечения системы автоматизированного проектирования

Следующим этапом в разработке программного обеспечения является выбор вида интерфейса для определения способа общения пользователя и системы автоматизированного проектирования и описания лингвистического обеспечения. Такой выбор производится на основе созданной конструкции и определенного состава интерфейса (подраздел 4.2).

В рамках данной разработки будет применен WIMP-интерфейс (Window -- окно, Image -- образ, Menu -- меню, Pointer -- указатель). Характерной особенностью этого вида интерфейса является то, что диалог с пользователем ведется не с помощью команд, а с помощью графических образов -- меню, окон и других элементов. Хотя и в этом интерфейсе подаются команды компьютеру и программе, но это делается опосредственно, через графические образы [24].

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

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

В данном разделе приведено описание правил взаимодействия пользователя и системы автоматизированного проектирования гидродинамики цементирования нефтяных скважин в рамках выбранной модели WIMP-интерфейса.

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

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

- пользователь заполнил не все поля ввода, таблицы;

- введенная информация не соответствует требованиям: вместо цифр введены буквы, неверный формат ввода данных (дробного числа, даты и пр.);

- в таблице создано количество записей больше разрешенного;

- произведен выбор не из всех необходимых списков;

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

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

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

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

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

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

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

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

- информационное окно, сообщающее о каком-либо событии, например, о завершении расчета, содержащее голубой символ «i»;

- окно ошибок, содержащее красный стоп-сигнал;

- окно замечаний, содержащее желтый восклицательный знак.

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

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

4.4 Описание использованных компонентов и иерархии классов

Большинство использованных компонентов для создания спроектированного графического интерфейса и реализации лингвистического обеспечения были взяты из стандартной библиотеки визуальных компонентов среды разработки приложений Delphi, именуемой VCL (Visual Component Library). Это объектно-ориентированная библиотека для разработки программного обеспечения, созданная компанией Borland для поддержки принципов визуального программирования, и предоставляющая огромное количество готовых к использованию компонентов для работы в самых разных областях программирования, таких, например, как интерфейс пользователя (экранные формы и элементы управления), работа с базами данных и пр.

Компоненты библиотеки Delphi оформляются в виде классов -- типов определяемых пользователем [26]. В классах описываются свойства объекта, его методы и события, на которые он может реагировать. Как и в большинстве других хороших библиотек классов, в библиотеке VCL широко используется механизм наследования. Иерархия классов VCL, служащих представлениями компонентов, довольно сложна. Структура этой иерархии представлена на рисунке 4.3.

На самом верху иерархической структуры находится объект TObject. Он является прародителем всех классов, представляющих компоненты VCL. Сразу же за TObject следует TPersistent. Этот класс отвечает за способность компонентов сохранять себя в файлах и в памяти, а так же предназначен для выполнения ряда других процедур. Более близким к компонентам в цепочке наследования является класс TComponent. Он обеспечивает для них все основные функциональные возможности. Невизуальные компоненты (таймеры, контейнер изображений и т.п.) являются прямыми потомками самого класса TComponent. Визуальные компоненты наследуются от класса TControl, который, как видно из рисунка 4.3, также является потомком класса TComponent. TControl придает визуальным компонентам дополнительные функциональные свойства. Отдельные визуальные компоненты выводятся либо из TGraphicControl, либо из TWinControl. Помимо компонент, сама форма и ее класс TForm также являются наследниками родительского класса TCustomForm.



Рисунок 4.3 -- Иерархическая структура классов

Далее в таблице 4.1 приведен перечень использованных в данной разработке стандартных компонентов управления и визуализации и их назначение.

Таблица 4.1 -- Использованные компоненты и их назначение

Компонент	Назначение
1	2
MainMenu	Формирование главного меню приложения
StatusBar	Строка состояния приложения
PageControl	Создание страниц, управляемых закладками и иными органами управления
LabeledEdit	Отображение, ввод и редактирование однострочных текстов. Компонент, оснащенный подписью (заголовком)
Label	Отображение статического и динамического текста, который не изменяется пользователем
Button	Кнопка, с помощью которой пользователь управляет работой приложения
Chart	Отображение диаграмм и графиков
StringGrid	Отображение текстовой информации в таблице из строк и столбцов с возможностью перемещения по полям, вводом и редактированием данных
GroupBox	Контейнер, объединяющий группу связанных органов управления
RadioButton	Предлагает пользователю набор альтернатив, из которых выбирается одна
Panel	Контейнер для группирования органов управления, отображение текста с возможностями объемного оформления
Memo	Отображение, ввод и редактирование однострочных текстов.
ImageList	Контейнер изображений, пиктограмм
UpDown	Кнопка-счетчик для изменения числовой информации с заданным шагом.
ComboBox	Выпадающий список данных для их выбора
ValueListEditor	Окно редактирования списков строк вида «имя-значение»

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

Реализация компьютерной динамической модели основана на использовании трех основных компонентов:

- TrackBar -- элемент управления в виде ползунка, предназначенный для регулировки скорости протекания процесса

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

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

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

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

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

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

4.5 Описание программной реализации задачи автоматизации проектирования гидродинамики при строительстве скважин

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

Для организации работы программы, взаимодействия функций и процедур объявлен большой набор глобальных переменных различных типов. При чем, весь это набор условно делится на переменные для считываемых и вычисляемых данных. Кроме того, организованы статические массивы: nc -- для записи количества цементировочных агрегатов в процессе закачки цементного раствора, и np, nbf -- аналогично при закачке продавочной и буферной жидкостей соответственно. Также описаны массивы hc, tc, Vc, хранящие результаты расчета высоты подъема цементного раствора, времени и объема его закачки. Для продавочной жидкости -- аналогичные массивы tp, Vp. Перед выполнением расчетов массивы инициализируются: в каждый из их элементов записывается ноль. Объявленные массивы имеют фиксированный размер (содержат пять элементов), т.к. хранят информацию о результатах работы цементировочных агрегатов на различных скоростях при закачке соответствующей жидкости или раствора, а таких скоростей у любого агрегата пять. Если при закачке какой-либо жидкости агрегат не работает на той или иной скорости, то ячейка с порядковым номером этой скорости соответствующего массива остается равной нулю.

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

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

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

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

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

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

Листинг программного комплекса приведён в приложении А.

6. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАБОТЫ

6.1 Расчет общей трудоемкости разработки программного обеспечения

В соответствии с Постановлением Министерства труда и социальной защиты Республики Беларусь от 27.06.2007 № 91 «Об утверждении укрупненных норм затрат труда на разработку программного обеспечения» [27] основой для определения общей трудоемкости разработки программного обеспечения, объемов финансирования на стадии его технико-экономического обоснования используются укрупненные нормы затрат труда. На основе общей трудоемкости разработки ПО составляется смета затрат, а также определяется численность исполнителей и трудоемкость выполняемых ими работ по этапам разработки ПО.

В качестве единицы измерения объема ПО примем строку исходного кода программы. Общий объем ПО (V0) определяется исходя из количества и объема функций, реализуемых программой, по каталогу функций программного обеспечения [27, приложение 1], и рассчитывается по формуле:

, (6.1)

где Vi -- объем отдельной функции программы;

n -- общее число функций.

Согласно имеющемуся каталогу функций, реализованное ПО содержит функции следующих категорий:

- контроль, предварительная обработка и ввод информации;

- обработка входного языка и формирование таблиц;

- организация ввода-вывода информации в интерактивном режиме;

- управление вводом-выводом;

- генерация структуры базы данных;

- формирование базы данных;

- обработка наборов и записей базы данных;

- организация поиска и поиск в базе данных;

- формирование служебных таблиц;

- обработка ошибочных сбойных ситуаций;

- математическая статистика и прогнозирование;

- формирование и вывод на внешние носители;

- графический вывод результатов.

Учитывая, что программное обеспечение реализовано с использованием среды разработки приложений Delphi (Borland) и нормативный объем строк исходного кода для выбранных категорий функций, получаем:

строк.

Действительный объем ПО имеет ряд отличий ввиду специфики примененных функций, поэтому нормативные значения объемов функций подлежат корректировке. Уточненный объем функций получается снижением объема различных функций на 20 % и увеличением на 10 % от значений по каталогу. Сравнение исходного и уточнённого объема строк исходного кода представлено в таблице 6.1.

Таблица 6.1 -- Сравнение исходного и уточнённого объёма строк исходного кода

Код функции	Наименование (содержание) функции	Объем функций (строк исходного кода)
		исходный	уточненный
1	2	3	4
Ввод, анализ входной информации, генерация кодов и процессор входного языка
102	Контроль, предварительная обработка и ввод информации	290	319
104	Обработка входного языка и формирование таблиц	630	630
107	Организация ввода-вывода информации в интерактивном режиме	170	170
109	Управление вводом-выводом	2700	2250
Формирование, ведение и обслуживание базы данных
202	Формирование базы данных	1700	1700
203	Обработка наборов и записей базы данных	2050	2050
207	Организация поиска и поиск в базе данных	5430	4358
403	Формирование служебных таблиц	570	570
506	Обработка ошибочных сбойных ситуаций	970	970
Расчетные задачи, формирование и вывод на внешние носители документов сложной формы и файлов
703	Расчет показателей	410	410
705	Формирование и вывод на внешние носители	2650	2208
707	Графический вывод результатов	300	330
Итого:	17870	15965

По формуле (6.1) производим расчет уточненного объема программного обеспечения (Vу):

строк.

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

На основании принятого к расчету уточненного объема программы и ее категории сложности определяем нормативную трудоемкость выполняемых работ согласно [27, приложение 3] Тн = 715 чел.-дн.

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

, (6.2)

где Ki -- коэффициент, соответствующий степени повышения сложности;

n -- количество учитываемых характеристик.

Т.к. программа обеспечивает хранение, ведение и поиск данных в сложных структурах, то коэффициент, соответствующий степени повышения сложности, Ki = 0,07. Подставив соответствующее значение в формулу (6.2), получаем:

.

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

Таблица 6.2 -- Результат экспертной оценки новизны ПО

Категория новизны ПО	Степень новизны	Использование	Коэффи-циент новизны
		На основе нового типа ПК	В среде новой ОС
Б	ПО имеет аналоги, содержит более развитый набор функций, средств визуализации	+	+	1,00

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

Современные технологии разработки компьютерных программ предусматривают широкое использование коробочных продуктов (пакетов, модулей, объектов). Степень использования в разработанном ПО стандартных модулей определяется их удельным весом в общем объеме программного продукта. В созданной системе компьютерного моделирования используется до 70 % стандартных модулей, что соответствует значению коэффициента КТ = 0,55.