CC BY
16
удк 541662: П.П. Олейник
04.004
К ВОПРОСУ О НЕОБХОДИМОСТИ РЕАЛИЗАЦИИ МОДУЛЯ ОПИСАНИЯ ФИНИШНЫХ ПРОЦЕССОВ ДЛЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ ЭКОНОМИЧЕСКОГО ПРОИЗВОДСТВЕННО-ЭНЕРГЕТИЧЕСКОГО КЛАСТЕРА УГОЛЬНОЙ ПРОМЫШЛЕННОСТИ
Представлена структура ядра информационной системы для экономического производственно-энергетического кластера глубокой переработки углеродсодержащих материалов. Описан состав и структура классов, представленных на статической диаграмме классов графического унифицированного языка моделирования UML. Для реализации объектной модели использована реляционная СУБД. Рассмотрены достоинства и недостатки каждого из трех методов, описаны области для оптимального применения. Представлен финишный процесс производства композитов на основе термоантрацита с отображением структурных составляющих кластера и получаемых на выходе материалов. Описан каждый структурный элемент экономического кластера, поступающий на переработку материал и создаваемый в итоге конечный продукт. Описана необходимость представления технических параметров, требуемых для производства продуктов.
Ключевые слова: углеводороды, глубокая переработка углеводородов, кластер предприятий, угольная промышленность, проектирование информационных систем, унифицированный язык моделирования UML, базы данных, объектно-ориентированное программирование.
С целью повышения прибыли каждое предприятие внедряет единую информационную систему, автоматизирующую ключевые бизнес-процессы. Выбор оптимального варианта — наиболее сложная задача в настоящее время, что обусловлено наличием множества альтернативных систем, име-
ISSN 0236-1493. Горный информационно-аналитический бюллетень. 2016. № 6. С. 261-270. © 2016. П.П. Олейник.
ющих сходный функционал. Задача усложняется при автоматизации деятельности группы компаний.
В работах [1—2] описана структура организации экономического производственно-энергетического кластера угольной промышленности, а также обозначена необходимость реализации единой информационной системы, ядро которой в виде диаграммы классов представлено на рис. 1.
Рассмотрим рисунок более подробно. Данная информационная система реализована в среде разработки SharpArchitect RAD Studio, имеющей строгую объектную метамодель и описанную в работах [3—4]. В настоящее время наибольшую популярность получила разработка в соответствии с принципами MDA (Model Driven Architecture), предполагающими наличие развитой ме-тамодели объектной системы, интерпретируемой при выполнении приложения. Проектируемая информационная система была описана в понятиях метамодели объектной системы.
Для представления территориальных объектов создан класс TerritoryObject. Класс TerritoryObjectKind описывает виды территориальных объектов: страна, округ, город и т.п. Для представления поставщиков/потребителей углеродсодержащих материалов используется класс Organization, а для организационно-правовой формы — класс OrganizationForm. Для сохранения информации о товарах и услугах введен класс Product, структура которого соответствует Общероссийскому классификатору продукции. Каждая организация одновременно может быть поставщиков одного вида продукции и потребителем другого. Для унифицированной реализации подобной структуры выделено два класса: 1) ActivityKind — для описания видов деятельности (продажа, производство, логистика и т.п.); 2) Activity — для непосредственного описания деятельности (например, указания конкретного антрацита, выработанного на определенной угольной шахте в конкретном населенном пункте). Одной из ключевых особенностей объектно-ориентированного проектирования является наследование, предоставляющее возможность выделения базовых абстрактных классов, содержащих общие свойства для производных классов. Так, класс BaseNamedDomainClass содержит атрибут Name, содержащий название. Класс BaseCo-dedTreeNodeDomainClass содержит атрибут Code, используемый для сохранения кодов классификаторов.
Многие из представленных классов (TerritoryObject, Organization, Product, ActivityKind) необходимо организовать в древовидную структуру данных. Именно поэтому рассматривае-
TeiritoryObject A
Interface
IBaseRunTimeTreeNodeDomainClass IBaseRunTimeDomainClass
Q Properties
A Owner
>
BaselNamedDomainClass
Interface
IBaseRunTimeDomainClass
0 Properties f* Name
M TerritoryObjectXind
ft Activitys
TerritoryObjectXind
Interface
BaseNamedDomainClass
H Properties
f> TerritoryObJects
W
Activity
Interface
IBaseRunTimeDomainClass
H Properties
ft Product J'* TerritoryObject
A
b Organization
Organization fi
Interface
BaseNamedDomainClass
В Properties
Activitys
7Г
ft Organizationa^orm
OrganizationalForm
Interface
■Ф BaseNamedDomainClass
В Properties
f* Organizations
M Nodes M
ft Activityiiind
9» Activitys
ActivityKind
Interface
BaseCodedTreeNodeDomainClass
В Properties
A Activitys ft Owner
-O
BaseCodedTreeNodeDomainClass
Interface
4 IBaseRunTimeTreeNodeDomainClass IBaseRunTimeDomainClass
□ Properties A Code
I
f* Nodes
Product
Interface
-t1 BaseCodedTreeNodeDomainClas
a Properties A Owner
Рис. 1. Иерархия классов экономического производственно-энергетического кластера
мые классы унаследованы от системного класса IBaseRunTime DomainClass, имеющегося в метамодели объектной системы [3—4]. Описанные действия привели к автоматической генерации свойства Nodes, содержащего дочерние (вложенные) узлы. Все выделенные ассоциации являются бинарными и двунаправленными. Т.е. каждый класс, участвующий в ассоциации, имеет атрибут, представляющий класс противоположного края ассоциации.
Для реализации модели использовалась среда разработки программных комплексов на основе организации метамодели объектной системы, представленная в работах [3—4]. Эта среда разработки получила название SharpArchitect RAD Studio, и в качестве хранилища информации использует реляционную СУБД. Т.к. информационная система проектируется в понятиях объектно-ориентированной парадигмы, а реализуется в среде реляционной СУБД, то возникает так называемое «объектно-реляционное несоответствие», для преодоления последствий которого используются методы (паттерны, шаблоны) объектно-реляционного отображения. Наиболее часто используются паттерны для представления иерархии классов.
В SharpArchitect RAD Studio реализуются три классических метода представления объектно-ориентированного отношения наследования классов в виде реляционной структуры (реляционных отношений) описанных далее. Метод Наследование с одной таблицей (Single Table Inheritance) физически представляет иерархию наследования классов в виде одной таблицы реляционной базы данных, столбцы которой соответствуют атрибутам всех классов, входящих в иерархию и позволяет отобразить структуру наследования и минимизировать количество соединений, которые необходимо выполнить для извлечения информации. В данном методе каждому экземпляру класса соответствует одна строка таблицы. При создании объекта значения заносятся только в те столбцы таблицы, которые соответствуют атрибутам класса, а все остальные остаются пустыми (имеют null-значения).
Метод имеет достоинства:
• в структуре БД присутствует лишь одна таблица, представляющая все классы иерархии;
• для извлечения экземпляров классов иерархии нет необходимости выполнять соединение таблиц;
• перемещение полей из базового класса в производный (так же из производного в базовый) не требует внесения изменений в структуру таблицы.
Методу присущи недостатки:
• При изучении структуры таблиц БД могут возникнуть проблемы, ведь не все имеющиеся столбцы таблицы предназначены для описания каждого класса предметной области. Это усложняет процесс доработки системы в будущем.
• При наличии глубокой иерархии наследования с большим количеством атрибутов многие столбцы могут иметь пустые значения (null-маркеры). Это приводит к неэффективному использованию свободного пространства в БД. Однако современные СУБД способны сжимать строки, содержащие большое количество отсутствующих значений.
• Итоговая таблица может оказаться слишком большой и содержать огромное число столбцов. Основной способ оптимизировать запрос (сократить время выполнения) — создать покрывающий индекс. Однако множество индексов и большое количество запросов к одной таблице способны привести к частым блокировкам, что будет оказывать негативное влияние на производительность программного приложения.
Альтернативным является метод Наследование с таблицами для каждого класса (Class Table Inheritance), представляющий иерархию классов по одной таблице для любого класса (как абстрактного, так и реализованного). Атрибуты класса отображаются непосредственно на столбцы соответствующей таблицы. При использовании данного метода ключевой является задача соединения соответствующих строк нескольких таблиц БД, представляющих единый объект предметной области.
Методу присущи преимущества:
• В каждой таблице присутствуют лишь поля, соответствующие атрибутам определенного класса. Поэтому таблицы легки для понимания и занимают мало места на жестком диске.
• Взаимосвязь между объектной моделью и схемой базы данных проста и понятна.
Однако имеются недостатки:
• При создании экземпляра определенного класса необходимо выполнить загрузку данных из несколько таблиц, что требует либо их естественного соединения, либо множества обращений к базе данных с последующим соединением результатов в оперативной памяти.
• Перемещение полей в производный класс или суперкласс требует изменения структуры нескольких таблиц.
• Таблицы суперклассов могут стать слабым местом в вопросах производительности, поскольку доступ к таким табли-
цам будет осуществляться слишком часто, что приведет к множеству блокировок.
• Высокая степень нормализации может стать препятствием к выполнению незапланированных заранее запросов.
Метод Наследование с таблицами для каждого конкретного класса (Concrete Table Inheritance) представляет иерархию наследования классов, использующий по одной таблице для каждого реализованного (неабстрактного) класса этой иерархии. С практической точки зрения данный метод предполагает, что каждый экземпляр класса (объект), который находится в оперативной памяти, будет отображен на отдельную строку таблицы. При этом каждая таблица в нашем случае содержит столбцы, соответствующие атрибутам как конкретного класса, так всех его предков.
Преимуществами являются то, что:
• каждая таблица не содержит лишних полей, вследствие чего ее удобно использовать в других приложениях, в которых не использован инструмент объектно-реляционного отображения;
• при создании объектов определенного класса в памяти приложения и извлечения данных из реляционной базы данных выборка выполнятся из одной таблицы, т.е. не требуется выполнять реляционные соединения;
• доступ к таблице осуществляется только в случае доступа к конкретному классу, что позволяет снизить количество блокировок, накладываемых на таблицу и распределить нагрузку на систему.
При этом имеются недостатки:
• Первичные ключи могут быть неудобны в обработке.
• Отсутствует возможность моделировать отношения (связи) между абстрактными классами.
• Если атрибуты классов перемещаются между суперклассами и производными классами, требуется изменять структуру нескольких таблиц. Эти изменения будут не так часты, как в случае наследования с таблицами для каждого класса, однако их нельзя игнорировать ( в отличие от метода Наследование с одной таблицей, в котором эти изменения вообще отсутствуют).
• Если в суперклассе изменить определение хотя бы одного атрибута (например, поменять тип данных), это потребует изменить структуру каждой таблицы, представляющей производный класс, поскольку поля суперкласса дублируются во всех таблицах его производных классов.
• При реализации метода поиска данных в абстрактном классе потребуется просматривать все таблицы, представляю-
щие экземпляры производных классов. Это требует большого количества обращений к базе данных.
Выбор соответствующего метода ОРО зависит от исходной логической модели, т.е. от иерархии классов предметной области. При этом одновременно могут использоваться два и более метода ОРО, что связано с необходимостью оптимизировать структуру реляционной БД и сократить количество используемых таблиц, что позволит увеличить скорость выполнения запросов на выборку данных.
Представленная иерархия классов экономического кластера является базовым ядром разрабатываемой системы. В настоящий момент в систему заносится информация об угольных шахтах Ростовской области и обо всех ключевых потребителях углеродсодержащих материалов. Дальнейшее развитие предполагает миграцию в сторону Веб-приложения и реализацию различных элементов личного кабинета пользователя, а также развитых средств поиска информации по введенным параметрам. Отметим, что представленная иерархия является унифицированной и позволяет автоматизировать деятельность экономического кластера для любой отрасли (а не только угольной).
Для дальнейшего развития очень важна возможность описания финишных процессов, предполагающая возможность получения новых видов продукции на основе имеющихся материалов и сырья. Особенно это актуально при переработке углеводородов.
В работе [1] представлена структура организации экономического производственно-энергетического кластера угольной промышленности и указана номенклатура выпускаемой продукции. На рис. 2 представлен финишный процесс производства композитов на основе термоантрацита.
Рисунок требует пояснений. Выданная нагора горная масса, кроме угля, всегда содержит то или иное количество породы. Эффективная переработка горной массы осуществляется
Шэхта-пава
горная масса
'Обогатительная фабрика
антрацит
Цех производства термоантрацита ,
термоантрацит
Цех производства композитов „
композиты на основе термоантрацита
Рис. 2. Финишный процесс производства композитов на основе термоантрацита
на обогатительной фабрике. На выходе обогатительной фабрики получают антрацит.
Антрациты после термической обработки применяют в производстве композитов (перекачивающие агрегаты, угольные электроды, катодные блоки для алюминиевых электролизеров, набивные электроды ферросплавных и карбидных печей и т.д.). Кроме того, термоантрацит применяют в вагранках и доменных печах на металлургическом и литейном производствах в качестве заменителя дефицитного кокса. Получением термоантрацита занимается цех производства термоантрацитов.
Цех производства композитов принимает на входе термоантрацит и на выходе выдает композиты. Например, полученный угольный электрод применяется для резки, строжки, прошивки отверстий в углеродистых, низколегированных и легированных сталях. Применяется в сталелитейной промышленности, судостроении, производстве металлоконструкций, машиностроении. Использование угольного электрода имеет множество преимуществ над общепринятыми способами резки типа кислородной или пильным полотном. В этом простом и комфортном методе используются углерод, сжатый воздух и электрический ток, что позволяет осуществить поверхностную резку и удаление металла. Электрод позволяет работать с широким диапазоном материалов: от малоуглеродистых сталей до нержавеющей стали, чугуна, меди и легких сплавов. Способ резки угольным электродом основывается на взаимодействии электрической дуги и сжатого воздуха. Металл, расплавленный электрической дугой, удаляется при помощи воздушной струи.
Еще одним получаемым композитом являются катодные блоки. Катодные подовые блоки, боковые и угловые предназначены для футеровки ванн и боковых стенок алюминиевых электролизеров. Блоки изготавливаются по чертежам заказчика на основе газо- или электрокальцинированного антрацита с добавлением различного количества искусственного графита (от 5 до 100%) в соответствии с пожеланиями заказчика. В качестве связующего применяется каменноугольный пек. Блоки катодные могут быть изготовлены как методом вибропрессования, так и методом давления (экструзии).
Представленный рис. 2 не содержит такие важные составляющие, как рыночную цену каждого готового продукта и необходимые условия для производства в виде технических условий производства. Особый интерес представляет процесс расчета себестоимости и сравнение с рыночной стоимостью
готовых товаров, что позволит рассчитать рентабельность производства. В настоящий момент автор занимается исследованием в этой области, результаты которого станут материалом для будущих публикаций.
В статье представлена структура ядра информационной системы для экономического производственно-энергетического кластера глубокой переработки углеродсодержащих материалов, описан финишный процесс производства композитов на основе термоантрацита с представлением структурных составляющих кластера и получаемых на выходе материалов. Дальнейшим развитием является разработка структуры БД, позволяющей унифицировано описать любой финишный процесс и рассчитать себестоимость каждого полученного материала.
СПИСОК ЛИТЕРАТУРЫ
1. Кураков Ю.И., Олейник П.П. Проектирование ядра информационной системы экономического производственно-энергетического кластера угольной промышленности // Объектные системы — 2014: материалы VIII Международной научно-практической конференции (Ростов-на-Дону, 10—12 мая 2014 г.) / Под общ. ред. П. П. Олейника. — Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2014. -С. 67-72.
2. Кураков Ю. И., Олейник П. П. Ядро ИС энергетического кластера / Студенческая научная весна - 2014: материалы региональной научно-технической конференции (конкурса научно-технических работ) студентов, аспирантов и молодых ученых вузов Ростовской области, г. Новочеркасск, 24-25 мая 2014 г. ЮРГПУ (НПИ). — Новочеркасск: ЮРГПУ(НПИ), 2014. - С. 38-39.
3. Олейник П. П. Элементы среды разработки программных комплексов на основе организации метамодели объектной системы // Бизнес-информатика. - 2013. - № 4(26). - С. 69-76.
4. Олейник П. П. Программа для ЭВМ «Унифицированная среда быстрой разработки корпоративных информационных систем SharpArchitect RAD Studio», свидетельство о государственной регистрации № 2013618212 от 04 сентября 2013 г. [¡233 "
КОРОТКО ОБ АВТОРЕ
Олейник Павел Петрович — кандидат технических наук, доцент, системный архитектор программного обеспечения, ОАО «Астон»,
Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, e-mail: [email protected].
Gornyy informatsionno-analiticheskiy byulleten'. 2016. No. 6, pp. 261-270.
P.P. Oleynik
ON THE QUESTION OF THE NEEDS TO IMPLEMENT THE MODULE OF DESCRIPTION FINISHING PROCESSES FOR THE INFORMATION SYSTEM OF ECONOMIC PRODUCTION AND ENERGY CLUSTER FOR COAL INDUSTRY
This article presents the structure of the core information system of economic production and energy cluster for deep processing of carbonaceous materials. Describes the composition and structure of the classes presented in a static class diagram graphical Unified Modeling Language UML. To implement the object model to use a relational DBMS. Considered the information system is implemented in a development environment SharpArchitect RAD Studio, which has a strict object metamodel. To overcome the effects of object-relational impedance mismatch were used object-relational mapping patterns. The advantages and disadvantages of each of the three patterns are described for the optimal use of the area.
Particular attention is given to the range of manufactured composites and their applications. Described the need to provide the technical parameters required for production. A further development is the development of the database structure, unifies describe any finishing process and calculate the cost of each received the finished material.
Key words: hydrocarbons, deep processing of hydrocarbons, a cluster of enterprises, the coal industry, design of information systems, the unified modeling language UML, databases, object-oriented programming.
AUTHOR
Oleynik P.P., Candidate of Technical Sciences, Assistant Professor, System Architect Software, Aston OJSC, Associate Professor,
Shakhty Institute (branch) of Platov South-Russian State Polytechnic University (NPI), Shakhty, Russia, e-mail: [email protected].
REFERENCES
1. Kurakov Yu. I., Oleynik P. P. Ob"ektnye sistemy — 2014: materialy VIII Mezhdun-arodnoy nauchno-prakticheskoy konferentsii. Rostov-na-Donu, 10—12 maya 2014 g. Pod red. P. P. Oleynika (Object Systems—2014: 8th International Scientific—Practical Conference Proceedings. Rostov-on-Don, 10—12 May 2014, Oleynik P. P. (Ed.)), Rostov-on-Don, URGPU im. M.I. Platova, 2014, pp. 67-72.
2. Kurakov Yu. I., Oleynik P. P. Studencheskaya nauchnaya vesna — 2014: materialy regional'noy nauchno-tekhnicheskoy konferentsii (konkursa nauchno-tekhnicheskikh rabot) studentov, aspirantov i molodykh uchenykh vuz,ov Rostovskoy oblasti, g. Novocherkassk, 2425 maya 2014 g. (Student's Science Spring-2014: Proceedings of Regional Scientific-Technical Conference (R&D Project Competition) for Students, Postgraduates and Young Scientists of the Rostov Region, Novocherkassk, 24-25 May 2014), Novocherkassk, YuRGPU (NPI), 2014, pp. 38-39.
3. Oleynik P. P. Biznes-informatika. 2013, no 4(26), pp. 69-76.
4. Oleynik P. P. Certificate of state registration 2013618212, 04.09.2013.
UDC 541.662: 04.004
