CC BY
49
№ 6 (54) 2014
П. П. Олейник, канд. техн. наук, системный архитектор программного обеспечения ОАО «Астон»,
доцент ШИ (Ф) ЮРГПУ (НПИ) им. М. И. Платова, г. Шахты, xsl@list.ru Ю. И. Кураков, докт. техн. наук, профессор, директор ШИ (Ф) ЮРГПУ (НПИ) им. М. И. Платова,
г. Шахты, phisycs@yandex.ru
концепция создания обслуживающей корпоративной информационной системы экономического производственно-энергетического кластера
В статье описана разработка информационной системы для автоматизации деятельности группы угольных предприятий, организованных в экономический производственно-энергетический кластер с целью повышения рентабельности и снижения себестоимости конечного продукта . Представлен примерный план организации экономического кластера угольной промышленности, детально рассмотрена необходимость наличия фабрик и цехов . В работе описана номенклатура выпускаемой продукции, получаемой при глубокой переработке угле-родсодержащих материалов, и актуальные цены на них . Представлена метамодель объектной системы, используемой для описания классов, ассоциаций и атрибутов . Описана иерархия классов для представления валидационных правил . Описаны наиболее популярные методы (паттерны) объектно-реляционного отображения . В статье представлена базовая архитектура разрабатываемой корпоративной информационной системы, обеспечивающей эффективное функционирование звеньев в едином кластере
Ключевые слова: экономический производственно-энергетический кластер, глубокая переработка углеродсодержащих, корпоративные информационные системы, объектно ориентированное проектирование, базы данных, метамодель объектной системы, методы (паттерны) объектно-реляционного отображения .
введение
В настоящий момент каждое крупное предприятие или группа компаний использует корпоративную информационную систему для удовлетворения информационных потребностей. Обоснованность внедрения подобного продукта во многом зависит от эффективности организации производства конечного продукта.
В данной статье рассматривается вопрос создания единой информационной системы, автоматизирующей ключевые бизнес-процессы группы предприятий горной промышленности, оптимально организо-
ванных с целью повышения рентабельности и снижения себестоимости конечного продукта. Представлен примерный план организации экономического кластера угольной промышленности, детально рассмотрена необходимость наличия фабрик и цехов. В работе описаны номенклатура выпускаемой продукции, получаемой при глубокой переработке углеродсодержащих материалов, и актуальные цены на них. В конце статьи представлена базовая архитектура разрабатываемой корпоративной информационной системы, обеспечивающей эффективное функционирование звеньев в едином кластере.
No. 6 (54) 2014
Проектирование конечной системы выполнено на базе собственной среды разработки, созданной на основе MDA архитектуры (Model Driven Architecture — архитектура, управляемая моделью). Эта архитектура в настоящее время одна из самых популярных и предполагает наличие развитой мета-модели объектной системы. Таким образом, в статье продемонстрирован процесс разработки реального приложения в перспективной среде разработки.
структурные элементы экономического
производственно-энергетического
кластера
Идея объединения группы горнопере-рабатывающих предприятий в единый комплекс (кластер) не нова. Базовая организационная структура рассматривалась одним из авторов уже давно, и основные наработки были представлены в работах [1-5].
В [6] предложена схема углеперерабаты-вающего комплекса для выработки из бурых углей Ланковского и Мелководнинского месторождений Магаданской области твердого облагороженного, газообразного и синтетического жидкого топлива. Кроме выработки топлива предусмотрено производство таких ценных продуктов, как горный воск и гуматы.
Технологическая схема, по мнению автора [6], следующая: 1 — блок добычи, 2 — блок транспортировки, 3 — блок углеперера-ботки, 4 — блок транспортировки продукции.
Основой этой схемы является модульный углеперерабатывающий завод, включающий: подготовительный модуль, ги-дрогенизационный модуль, экстракционный модуль, брикетный модуль и газогенераторный модуль. Из общей массы бурого угля (2695 тыс. т/год), поступающего на подготовительный модуль, на ги-дрогенизационный модуль направляется 1695 тыс. т для получения жидкого синтетического топлива. На брикетный модуль поступает 131 тыс. т из подготовительного модуля и 116 тыс. т из экстракционного модуля. Экстракционный модуль пере-
рабатывает 168 тыс. т угля. Из брикетного модуля 124 тыс. т брикетов подается на газогенераторный модуль, в котором получают высококалорийный метановый газ, который использует Магаданская ТЭЦ. Из экстракционного модуля выходит сырой горный воск — 1000 т и гуматы — 50 тыс. т. Другими словами, 6,2% — это нетопливное использование угля, а все остальное под тем или иным видом сжигается. Вместе с тем даже при таком подходе ожидаемый уровень валовой прибыли при достижении проектной мощности 10 млн т/год составляет более 20 млрд руб./год.
Вопросам комплексной переработки углей посвящено немало работ [7-17]. Для экономики России актуальна проблема переработки углеродсодержащих материалов (торф, сланец, каменный уголь, антрацит) в изделия широкого назначения(мотор-ные топлива, горюче-смазочные материалы, фильтранты, адсорбенты, карбюризаторы, носители катализаторов и т. д.).
В [18] приведены оптимальные значения структурно-химических параметров углей для их нетопливного использования с получением активных углей, жидкого топлива, сульфоуглей, ваграночного топлива, термографита, углеграфитовых материалов.
Российскими учеными и производственниками разработаны современные технологии по добыче, обогащению и комплексному использованию углей и отходов переработки, но все это разрозненно, по отдельным производствам.
Организация производств по глубокой переработке антрацитов в угледобывающем регионе будет способствовать повышению рентабельности производства и преодолению многолетнего кризиса в горнодобывающей отрасли. Одним из эффективных путей реализации данного подхода может стать организация горнодобывающего комплекса (кластера), обеспечивающего технологию глубокой переработки.
Основной задачей предприятия в современных экономических условиях является повышение рентабельности за счет приме-
№ 6 (54) 2014
нения современных технологий и высокопроизводительной техники. Топливно-энергетический комплекс вносит важный вклад в экономику страны и занимает одно из ведущих мест в ее отраслевой структуре. В соответствии с распоряжением Правительства Российской Федерации № 1234-р от 28.08.2003 г. об утверждении Энергетической стратегии России на период до 2020 г. по разделу «Угольная промышленность» предусмотрено «...внедрение новых технологий обогащения и глубокой переработки энергетических углей». В угольной промышленности намечена программа, предусматривающая увеличение добычи угля на новых угольных предприятиях и высокоэффективных действующих. Повышение экономической эффективности угольной отрасли возможно за счет создания производственно-технологических кластеров по добыче и переработке угля (производство из угля химико-технологических продуктов и материалов различного назначения).
Суть производственно-энергетического кластера заключается в новом хозяйственном подходе к его организации.
В качестве примера рассмотрим Ростовскую область. Область располагает запасами более 24 млрд т угольных ресурсов. Доля антрацита в общих запасах угля составляет более 90%. Кроме антрацита имеются угли марок Г, Ж, КЖ, К, ОС, которые используются при производстве кокса.
Главной задачей горных предприятий является внедрение современных технологий отработки угольных пластов, высокоэффективной техники.
Основные этапы создания кластера следующие (рис. 1). Строится шахта нового типа «шахта-лава», на которой применена технология струговой выемки.
Опыт отработки тонких пластов (в России они составляют 60% промышленных запасов угля) в Германии, Польше, США показал высокую рентабельность этой технологии. Производительность струговой установ-
Рис. 1. Структурный план организации экономического производственно-энергетического кластера
No. 6 (54) 2014
ки в 2,5 раза выше, чем производительность комбайна. Струговая выемка обеспечивает: высокую нагрузку на очистной забой; высокую сортность угля; высокую безопасность работ; удобство технического обслуживания и т. д. [19].
Струговые установки могут работать как с индивидуальными, так и с механизированными крепями. Средняя производительность стругового комплекса составляет 1500 т/сутки на пластах мощностью 0,8-1,8 м. Объем инвестиций для строительства шахты нового типа составляет 1,3 млрд руб., срок реализации 4 года.
В наше время антрацит — основное технологическое сырье (нетопливного использования) при производстве продукции, используемой в цветной и черной металлургии, при производстве карбида кальция и кремния, фосфора, удобрений, в качестве карборизатора для производства стали, синтетического чугуна и т. д.
Антрациты нетопливного направления используются для производства электродной продукции (это катодные и доменные блоки, угольные пасты и массы, угольные электроды и др.), они расположены в двух бассейнах — Донецком и Горловском. Изменения в экономике России сделали неконкурентоспособными поставки антрацита и термоантрацита (производимого на металлургическом заводе г. Красный Сулин Ростовской области) на Урал и в Сибирь. Новосибирский электродный завод (ЗАО «НовЭЗ») получает антрацит Горлов-ского, Колыванского и Ургунского месторождений Горловского бассейна [20, 21].
Продукция ЗАО «НовЭЗ» весьма разнообразна, востребованна на внутреннем и международном рынках, соответствует международным стандартам качества. Поставщиком технологического антрацита является ЗАО «Сибирский Антрацит».
Примером топливно-энергетического кластера с технологией глубокой переработки антрацита могло бы послужить предприятие, образованное путем объединения таких организаций, как ЗАО «Сибирский Ан-
трацит» (которое в настоящее время занимается лишь добычей антрацита) и завода НовЭЗ, занимающегося глубокой переработкой углеродсодержащих материалов.
На наш взгляд, экономически целесообразно организовать производственно-технологический кластер по добыче и глубокой переработке угля на основании схемы, представленной на рис. 1 (структурные элементы кластера и номенклатура выпускаемой продукции).
критерии оптимальности метамодели объектной системы
Во всех перечисленных литературных источниках внимание было уделено лишь структурной составляющей энергетического кластера, так как уровень аппаратно-программной составляющей на момент публикации статей был довольно низок. На текущий момент ситуация изменилась кардинально, и появилась возможность реализации корпоративной информационной системы (КИС), автоматизирующей деятельность кластера. Сейчас необходима ИС, позволяющая автоматизировать экономическую деятельность нескольких взаимосвязанных предприятий одной сферы промышленности. В России все большую популярность приобретают международные стандарты, регламентирующие функциональные особенности современных КИС [22]. В частности, стандарты ERP, ERP II и CSRP оказали большое влияние на процесс организации взаимоотношений между контрагентами. Положительный опыт внедрения продуктов описанных стандартов, имеющийся у авторов, был использован при написании данной статьи. В ней представлен комплексный подход организации экономического кластера и рассмотрены как структурные составляющие, так и проблемы организации КИС.
Перейдем к рассмотрению реализации программного обеспечения для экономического кластера. В настоящее время наибольшую популярность получила разработка в соответствии с принципами MDA, пред-
№ 6 (54) 2014
полагающими наличие развитой метамоде-ли объектной системы, используемой при выполнении приложения. Реализация мета-модели, используемая при проектировании ядра кластера, описана в работах [23, 24] и представлена в виде диаграммы классов языка UML на рис. 2. При проектировании иерархии были выделены следующие критерии оптимальности метамодели КОмм [24].
1. Разработать единую иерархию, позволяющую представить ключевые элементы объектно ориентированной парадигмы, такие как классы, атрибуты, наследование (одиночное и множественное), ассоциации и т. п.
2. Предусмотреть возможность предоставления базовых (системных) классов, в которых реализован наиболее общий функционал.
3. Разработать иерархию атомарных литеральных типов, представляющих наиболее распространенные типы данных современных объектно ориентированных языков программирования.
Рассмотрим требования более подробно. Реализация требования КОмм1 позволит унифицированно обрабатывать все элементы с помощью различных структур данных, например с помощью итераторов при формировании цикла. При этом пользователю предоставляется возможность применять хорошо зарекомендовавшие себя объектно ориентированные подходы, как, например, наследование и организация ассоциаций.
КОмм2 требует наличия системных (встроенных) классов. В общем случае пользователи не могут модифицировать поведение этих классов, но имеют возможность наследоваться от них. При этом наличие множественного наследования предоставляет широкие возможности моделирования задач предметной области.
Современные объектно ориентированные языки программирования (ООЯП) имеют в своем арсенале богатый набор встроенных атомарных литеральных типов. Поэтому необходимо предоставить подобный функционал в разрабатываемой системе, что соответствует требованию КОммЗ.
иерархия классов метамодели объектной системы
Перейдем к рассмотрению классов иерархии метамодели. Базовым классом является MetaModelltem, который содержит общие свойства и методы, характерные для всех элементов метамодели. Основное свойство описываемого класса содержит тип самого элемента и используется многократно для получения метаинформации. Элементы метамодели, которые должны иметь название и заголовок (класс, атрибут класса, ассоциация и т. п.), должны быть унаследованы от CaptionedMetaModelltem. Для представления различных классов системы используется корневой абстрактный класс Class.
В системе предусмотрено два вида наследования. Первое предполагает простое наследование классов без возможности добавления атрибутов пользователем. Данный тип наследования может использоваться классами лингвистического транслятора, который предполагает создание иерархии классов, представляющей элементы русского языка (например, морфемы). Для решения описанной задачи используется абстрактный класс SimplelnheritanceClass.
Для реализации классического наследования, предполагающего добавление как унаследованных классов, так и определения имеющихся атрибутов, используются производные от CustomAttributedClass классы. В частности, реализованный (неабстрактный) DomainClass класс используется для реализации сущностей предметной области, каждая из которых может быть унаследована от нескольких базовых. Множественное наследование позволяет проектировать более гибкие системы, автоматизирующие широкий спектр предметных областей. Например, при проектировании классов, представляющих некоторые товары, может потребоваться представить их структуру в виде дерева. То есть необходимо, чтобы одновременно происходило наследование от базового класса, представляющего то-
No. 6 (54) 2014
вар, и от системного класса, представляющего древовидную структуру.
При проектировании иерархии атомарных литеральных типов (целых чисел, строк, дробных чисел и т. п.) использовался общий подход, подробно описанный в работе [7]. Однако с целью упрощения процесса ре-факторинга было принято решение о сокращении набора классов и применении параметризованных типов (Generic в языке C#). Корневым является класс AbstractAttribute, от которого унаследованы SystemAttribute и ConcreteAttribute. Первый используется для описания атрибутов системных классов, которые не могут редактироваться или добавляться пользователем. Второй представляет непосредственно атрибуты, добавляемые пользователем в режиме выполнения приложения.
Базовый параметризованный класс TypedAttribute является корневым для всех атрибутов, у которых параметр типа выступает в качестве типа данных для значения атрибута. Абстрактный класс SimpleTypedAttribute является корнем иерархии атомарных литеральных типов. В свою очередь, ClassedValueAttribute выступает корнем для всех атрибутов, значениями которых выступают объекты определенного класса.
Для представления связей между классами используется механизм ассоциаций языка UML [23], для реализации которого выделен класс Association. В системе предусмотрена возможность описания только бинарных связей, так как для них проще всего определить кратность каждого участника. Поэтому для представления отдельного края ассоциации используется экземпляр класса AssociationEnd.
Метамодель представления валидационных правил объектной системы
Валидация — это процесс проверки вводимых данных на допустимость и соответствие бизнес-правилам организации. Объемы обрабатываемой информации современного предприятия настолько велики, что
пользователю невозможно самостоятельно отслеживать соблюдение подобных правил, поэтому необходим общий механизм, позволяющий декларировать их и проверять в момент сохранения данных. В настоящем разделе статьи подробно описана иерархия классов представления валидационных правил объектной системы. Особый интерес представляют именно объектные системы, так как они наиболее популярны в настоящее время [29, 30].
Для рассматриваемой задачи были сформулированы следующие критерии:
1. Разработать механизм валидации значения каждого отдельного атрибута класса, представляющего сущность реального мира.
2. Предусмотреть возможность валида-ции на уровне классов, предполагающую проверку комбинации атрибутов класса с помощью логического условия.
3. Реализовать возможность валидации атрибутов, тип которых предполагает дискретные значения заданного диапазона.
4. Предусмотреть возможность наследования валидационных правил.
Рассмотрим требования каждого критерия более подробно. Разработка программного обеспечения предполагает создание иерархии классов и выделение атрибутов, представляющих сущности реального мира и их связи в соответствии с бизнес-процессами организации. Реализация требования критерия оптимальности № 1 (КО1) позволит унифицированно прописывать валидацион-ные правила, задающие ограничения на значения каждого отдельного атрибута классов. Например, при создании нового клиентского заказа, предполагающего продажу товара, необходимо предусмотреть обязательный ввод названия товара и цены. То есть необходимо обязать пользователя выбрать продукт из справочника и ввести положительное число, представляющее цену товара. Именно выполнение КО1 позволит реализовать подобные валидационные правила.
Бизнес-правила многих предметных областей гораздо сложнее описанных выше
№ 6 (54) 2014
11
No. 6 (54) 2014
и накладывают ограничения сразу на значения нескольких атрибутов. Именно реализация подобных правил предусмотрена при выполнении КО2. То есть задается логическое выражение, накладываемое сразу на несколько атрибутов и предполагающее его проверку при сохранении объекта в базе данных. Примером подобного правила является требование непревышения суммы заказа (не более ста тысяч рублей) при оплате наличными.
Многие атрибуты классов позволяют сохранить дискретное значение, попадающее в заданный диапазон. Например, количество техники может быть представлено только целым положительным числом, входящим в определенный диапазон, например от одного до тысячи. Так же документы, соз-
данные в текущем году, должны иметь значения в поле «Дата», попадающие в диапазон дат текущего года. Именно реализация подобных правил предусмотрена в КО3.
Одной из особенностей объектно ориентированного проектирования/программирования является наследование, предполагающее, в частности, использование атрибутов базового класса в производном классе. Подобная функциональность, которая требует выполнения КО4, необходима и при реализации валидационных правил.
На рис. 3 в виде диаграммы классов унифицированного языка UML представлена разработанная иерархия валидационных правил.
При проектировании объектной системы принято выделять единый базовый класс,
Рис. 3. Иерархия классов представления валидационных правил
12 !
№ 6 (54) 2014
представляющий собой корень иерархии, которым в рассматриваемой диаграмме является абстрактный ValidationRule. Для определения валидационных правил на уровне всего класса выделены абстрактный класс ClassCheckingValidationRule, имеющий наследника InvertableClassCheckingValidation-Rule, позволяющий инвертировать результат проверки и таким образом упростить реализацию бизнес-правил. В настоящее время для класса предусмотрена возможность описания только логических условий, которые представляются реализованным классом CriteriaCheckingValidationRule.
Абстрактный класс AttributesValidation-Rule позволяет описывать валидацион-ные правила, которые распространяются на отдельные атрибуты. При этом он параметризованный, что обусловлено возможностью применения в качестве параметра различных типов атрибутов в производных классах. Унаследованный класс ConcreteAttributesValidationRule позволяет описывать бизнес-правила для атрибутов типа Сопс^еАйпЬ^е, которые являются основными и добавляются разработчиками.
Одним из самых простых правил является необходимость внесения значения в определенные атрибуты класса. Для подобных правил введен реализованный класс RequiredAttributesValidationRule.
Часто необходимо создать бизнес-правила, требующие наличия уникальной комбинации значений определенных атрибутов. Например, одновременно не может быть продаж одного и того же товара одному клиенту. Для представления подобных правил введен класс UniqueCombinationAt-tributesValidationRule, имеющий двух наследников — UniqueCombinationRunTimeClassed-CollectionAttributesValidationRule и Unique-CombinationSimpleTypedAttributesValida-tionRule. Первый класс позволяет указать уникальную комбинацию атрибутов элементов одной коллекции, тип которой создан разработчиком и описывает сущность реального мира предметной области. В текущей реализации присутствует лишь один
наследник UniqueCombinationDomainClass-CollectionAttributesValidationRule, параметризованный классом DomainClassAttribute.
Второй наследник UniqueCombination-SimpleTypedAttributesValidationRule позволяет создать правило уникальности атрибутов простых типов, таких как целые числа, строки, даты, и других типов языка С#, а также атрибутов, значением которых может быть только один (не коллекция) объект предметной области.
Базовый абстрактный класс TypedValue-RangedAttributesValidationRule является корневым для валидационных правил, проверяющих диапазон вводимых значений. Реализованный наследник RangeDateTimeAt-tributesValidationRule позволяет проверить диапазон введенной даты. Класс RangeInt-AttributesValidationRule служит для проверки диапазона целочисленных атрибутов, а RangeDecimalAttributesValidationRule используется для атрибутов дробного значения. Класс RangeTimeAttributesValidationRule предназначен для описания правил, накладываемых на атрибуты, принимающие временные значения.
После описания всех классов рассмотрим соответствие данной иерархии выделенным ранее критериям оптимальности. Система соответствует КО1, так как выделен базовый корневой абстрактный класс AttributesValidationRule, позволяющий разработать механизм валидации значения каждого отдельного атрибута класса, представляющего сущность реального мира. При этом унаследованные классы позволяют реализовать требуемое поведение.
Базовый класс ClassCheckingValidation-Rule представляет возможность валидации на уровне классов и реализовать проверку комбинации атрибутов класса с помощью логического условия, что выполнено в конкретном классе CriteriaCheckingValidationRule. Следовательно, требование КО2 выполнено.
Для реализации требований КО3, предоставляющего возможность валидации атрибутов, тип которых предполагает дискретные значения заданного диапазона, введен
No. 6 (54) 2014
базовый параметрированный класс Typed-ValueRangedAttributesValidationRule, имеющий несколько конкретных наследников, позволяющих выполнить проверку атрибутов, сохраняющих значения даты, времени, а также целочисленные и дробные значения.
Требования КО4 выполнены, так как при разработке данной иерархии классов представления валидационных правил используется унифицированная метамодель объектной системы, описанная в работе и предполагающая встроенную возможность наследования. Так как требования всех критериев выполнены, то можно утверждать, что разработанная система является оптимальной.
Методология проектирования информационной системы экономического производственно-энергетического кластера
При реализации любой информационной системы необходимо следовать выбранной методологии проектирования. В настоящее время широкую популярность получило предметно ориентированное проектирование, предполагающее создание модели предметной области, основу которой составляет диаграмма классов, представленная в нотации UML [25, 26, 28]. Именно этой методологии придерживаются авторы при проектировании ИС. Предполагается, что при реализации информационной системы применяется объектно ориентированный язык программирования, а для хранения информации в долговременной памяти
используется СУБД. При проектировании структуры БД можно выделить три основных этапа: концептуальное, логическое и физическое проектирование [27]. Последний этап напрямую зависит от типа выбранной СУБД, поэтому при реализации приложения в инструментальной среде разработки, охватывающей полный жизненный цикл, возникают сложности при построении физической модели.
Перейдем к процессу предметно ориентированного проектирования с позиций разработки структуры БД. Выделяют три основных этапа проектирования: концептуальное, логическое и физическое [3]. Концептуальное проектирование базы данных позволяет описать высокоуровневую модель и начинается с создания концептуальной модели данных предприятия, полностью независимой от любых деталей реализации. К последним относятся выбранный тип СУБД, состав программ приложения, используемый язык программирования, конкретная аппаратная платформа, вопросы производительности и любые другие физические особенности реализации. Для целей данной статьи рассмотрим простую предметную область, концептуальная и логические модели которой представлены на рис. 4.
Следующим этапом является логическое проектирование БД, под которым понимается конструирование информационной модели предприятия на основе существующих конкретных моделей данных, но без учета специфики используемой СУБД и прочих условий реализации [27].
Рис. 4. Концептуальная (слева) и логическая (справа) модели
№ 6 (54) 2014
В общем случае логическое проектирование базы данных заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (в нашем случае в понятия объектной СУБД). Логическая модель данных является источником информации для этапа физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет важное значение для выбора эффективного проектного решения.
При разработке логической структуры (модели) БД используется объектно ориентированная модель данных (ООМД), поэтому необходимо удалить элементы, присутствующие на концептуальной модели, которые не поддерживаются в ООМД, и добавить те элементы, которыми отличается ООМД. В нашем случае необходимо выполнить следующее:
1) обобщение/специализацию;
2) преобразование связей с атрибутами в отдельные классы;
3) преобразование сложных связей в отдельные классы;
4) проектирование правил поведения.
Рассмотрим каждый пункт более подробно. Некоторые объекты могут иметь подобные, но не идентичные атрибуты и методы. Если степень такого подобия высока, то имеет смысл совместно использовать эти свойства (атрибуты и методы). Наследование позволяет определять один класс на основе общего класса предка. Такие менее общие классы называются подклассами (производными, унаследованными классами), а более общие — суперклассами (родительскими классами). Процесс образования суперкласса называется обобщением (генерализация), а процесс образования подкласса — специализацией. По умолчанию подкласс наследует все свойства суперкласса и в дополнение к ним может определить свои собственные уникальные. В подклассе могут быть переопределены унас-
ледованные свойства. Все экземпляры подкласса являются также экземплярами суперкласса и согласно принципу подстановки для любого метода и конструкции вместо экземпляра суперкласса всегда можно использовать экземпляр его подкласса. Отметим, что расширенная модель «сущность-связь» поддерживает механизм уточнения/ обобщения (предполагающий использование дискриминанта), но данная конструкция более ограничена по сравнению с концепцией наследования, применяемой в объектно ориентированном программировании.
Проанализировав рис. 4, можно утверждать, что два выделенных класса (Client и Product) полностью идентичны, так как характеризуются одинаковыми атрибутами (в данном случае названием). Поэтому имеет смысл выделить общий базовый класс (выполнить процедуру обобщения), содержащий название (например, класс NamedObject), а классы Client и Product сделать производными от NamedObject.
В сложных связях участвуют три и более сущностей. Такие связи не поддерживаются непосредственно и требуют введения промежуточного класса, который соединяется с остальными бинарными связями (как правило, с типом «один ко многим»). Из концептуальной модели видно, что в предметной области отсутствуют сложные связи, поэтому описанные преобразования выполнять не нужно. Результат описанных действий представлен на рис. 2.
Последним этапом является физическое проектирование базы данных, под которым понимается описание конкретной реализации базы данных, размещаемой во внешней памяти. Физический проект описывает базовые отношения, определяет организацию файлов и состав индексов, применяемых для обеспечения эффективного доступа к данным, а также регламентирует все соответствующие ограничения целостности и меры защиты. Физическое проектирование базы данных предусматривает принятие разработчиком окончательного решения о способах реализации создаваемой базы.
No. 6 (54) 2014
Поэтому физическое проектирование обязательно производится с учетом всех особенностей целевой СУБД.
В нашем случае используется собственная среда разработки, поэтому физическая модель представляется в понятиях экземпляров классов метамодели, изображенной на рис. 2. То есть необходимо построить диаграмму объектов языка UML. Один из возможных вариантов представлен на рис. 5.
Из рисунка видно, что представлена диаграмма объектов языка UML [26], содержащая некоторую дополнительную информацию, необходимую для понимания. Для представления классов предметной области используются объекты типа DomainClass. Для организации ассоциаций используются объекты трех классов. Объекты типа Association позволяют опи-
сать ассоциации между классами. В настоящий момент используются только бинарные ассоциации (сложные ассоциации могут быть представлены в виде набора бинарных ассоциаций), поэтому необходим механизм описания обоих краев ассоциации. Для этого используются экземпляры классов AssociationEnd. Для каждого края ассоциации генерируется атрибут типа DomainClassAttribute.
В зависимости от типа (домена) атрибута класса используется соответствующий экземпляр класса метамодели объектной системы. Так, для атрибута Dates, позволяющего сохранять дату и время продажи, использован экземпляр класса DateTimeAttribute.
Из рисунка видно, что подобным образом может быть представлена модель любой предметной области, в том числе и модель
Attributes
BaseClasses
О
Client : DomainClass Caption = Client ImageName = Client Options = ShowInGUI
Name : StringAttribute
Caption = Name
Options = Required
Sales : DomainClassAttribute Caption = Sales
Multiplicity = ZeroOrMany_
Dates : DateTimeAttribute -
Caption = Date
Options = Required
Client : DomainClassAttribute
Caption = Client Multiplicity = One Options = Required
Caption = Product Multiplicity = One Options = Required
Client Sale : Association Product Sale : Association
Caption = Client - Sale
Caption = Product - Sale
RightEnd : AssociationEnd
Multiplicity = ZeroOrMany
Attribute
RightEnd
. LeftEnd : AssociationEnd. Multiplicity = One
i
111
=3
Q.
RightEnd
RightEnd : AssociationEnd
Multiplicity = ZeroOrMany
LeftEnd : AssociationEnd
Attribute
Multiplicity = One
Рис. 5. Физическая модель структуры тестовой БД в понятиях метамодели объектной системы 16 ,
№ 6 (54) 2014
экономического производственно-энергетического кластера.
иерархия классов экономического производственно-энергетического кластера
На рис. 6 представлена иерархия классов экономического производственного-энергетического кластера.
Рассмотрим изображенную иерархию более подробно. Для представления территориальных объектов создан класс TerritoryObject. Класс TerritoryObjectKind описывает виды территориальных объектов: страна, округ, город и т. п. Для представления поставщиков/потребителей углеродсодержащих материалов используется класс Organization, а для организационно-правовой формы — класс OrganizationForm. Для сохранения информации о товарах и услугах используется
класс Product, структура которого соответствует Общероссийскому классификатору продукции. Каждая организация одновременно может быть поставщиком одного вида продукции и потребителем другого. Для унифицированной реализации подобной структуры выделено два класса: 1) ActivityKind для описания видов деятельности (продажа, производство, логистика и т. п.); 2) Activity для непосредственного описания деятельности (например, указания конкретного антрацита, выработанного на определенной угольной шахте в конкретном населенном пункте). Одной из ключевых особенностей объектно ориентированного проектирования является наследование, предоставляющее возможность выделения базовых абстрактных классов, содержащих общие свойства для производных классов. Так, класс BaseNamedDomainClass содержит атрибут Name, содержащий название. Класс
Рис. 6. Иерархия классов экономического производственно-энергетического кластера
17
No. 6 (54) 2014
BaseCodedTreeNodeDomainClass содержит атрибут Code, используемый для сохранения кодов классификаторов.
Многие из представленных классов (TerritoryObject, Organization, Product, Activi-tyKind) необходимо организовать в древовидную структуру данных. Именно поэтому рассматриваемые классы унаследованы от системного класса IBaseRunTimeDomain-Class, имеющегося в метамодели объектной системы [23]. Описанные действия привели к автоматической генерации свойства Nodes, содержащего дочерние (вложенные) узлы. Все выделенные ассоциации являются бинарными и двунаправленными. То есть каждый класс, участвующий в ассоциации, имеет атрибут, представляющий класс противоположного края ассоциации.
способы представления классов и отображения объектов на строки таблиц реляционной системы управления базами данных
В настоящий момент для реализации хранилища информации используют чаще всего реляционные системы управления базами данных (РСУБД) [27, 29]. При этом для отображения объектов (экземпляров классов) и представления объектной системы в РСУБД используют методы объектно-реляционного отображения (ОРО) [31, 32].
Рассмотрим основные методы ОРО, используемые для представления иерархии классов в виде таблиц РБД (рис. 7). Метод «Наследование с одной таблицей» (Single Table Inheritance) физически представляет иерархию наследования классов в виде одной таблицы реляционной базы данных, столбцы которой соответствуют атрибутам всех классов, входящих в иерархию, и позволяет отобразить структуру наследования и минимизировать количество соединений, которые необходимо выполнить для извлечения информации. В данном методе каждому экземпляру класса соответствует одна строка таблицы. При создании объекта значения заносятся только в те столбцы та-
блицы, которые соответствуют атрибутам класса, а все остальные остаются пустыми (имеют null-значения).
Достоинства метода:
• в структуре БД присутствует лишь одна таблица, представляющая все классы иерархии;
• для извлечения экземпляров классов иерархии нет необходимости выполнять соединение таблиц;
• перемещение полей из базового класса в производный (также из производного в базовый) не требует внесения изменений в структуру таблицы.
Недостатки метода:
• при изучении структуры таблиц БД могут возникнуть проблемы, ведь не все имеющиеся столбцы таблицы предназначены для описания каждого класса предметной области. Это усложняет процесс доработки системы в будущем; при наличии глубокой иерархии наследования с большим количеством атрибутов многие столбцы могут иметь пустые значения (null-маркеры). Это приводит к неэффективному использованию свободного пространства в БД. Однако современные СУБД способны сжимать строки, содержащие большое количество отсутствующих значений;
• итоговая таблица может оказаться слишком большой и содержать огромное число столбцов. Основной способ оптимизировать запрос (сократить время выполнения) — создать покрывающий индекс. Однако множество индексов и большое количество запросов к одной таблице способны привести к частым блокировкам, что будет оказывать негативное влияние на производительность программного приложения.
Альтернативным является метод «Наследование с таблицами для каждого класса» (Class Table Inheritance), представляющий иерархию классов по одной таблице для любого класса (как абстрактного, так и реализованного). Атрибуты класса отображаются непосредственно на столбцы соответствующей таблицы. При использовании данного
№ 6 (54) 2014
метода ключевой является задача соединения соответствующих строк нескольких таблиц БД, представляющих единый объект предметной области.
Преимущества метода:
• в каждой таблице присутствуют лишь поля, соответствующие атрибутам определенного класса. Поэтому таблицы легки для понимания и занимают мало места на жестком диске;
• взаимосвязь между объектной моделью и схемой базы данных проста и понятна.
Недостатки метода:
• при создании экземпляра определенного класса необходимо выполнить загрузку данных из нескольких таблиц, что требует либо их естественного соединения, либо множества обращений к базе данных с последующим соединением результатов в оперативной памяти;
• перемещение полей в производный класс или суперкласс требует изменения структуры нескольких таблиц;
• таблицы суперклассов могут стать слабым местом в вопросах производительности, поскольку доступ к таким таблицам будет осуществляться слишком часто, что приведет к множеству блокировок;
• высокая степень нормализации может стать препятствием к выполнению незапланированных заранее запросов.
Метод «Наследование с таблицами для каждого конкретного класса» (Concrete Table Inheritance) представляет иерархию наследования классов, используя по одной таблице для каждого реализованного (неабстрактного) класса этой иерархии. С практической точки зрения данный метод предполагает, что каждый экземпляр класса (объект), который находится в оперативной памяти, будет отображен на отдельную строку таблицы. При этом каждая таблица в нашем случае содержит столбцы, соответствующие атрибутам как конкретного класса, так и всех его предков.
Преимущества:
• таблицы не содержат лишних полей, вследствие чего их удобно использовать
в других приложениях, в которых не использован инструмент объектно-реляционного отображения;
• при создании объектов определенного класса в памяти приложения и извлечения данных из реляционной базы данных выборка выполняется из одной таблицы, т. е. не требуется выполнять реляционные соединения;
• доступ к таблице осуществляется только в случае доступа к конкретному классу, что позволяет снизить количество блокировок, накладываемых на таблицу, и распределить нагрузку на систему.
Недостатки:
• первичные ключи могут быть неудобны в обработке;
• отсутствует возможность моделировать отношения (связи) между абстрактными классами;
• если атрибуты классов перемещаются между суперклассами и производными классами, требуется изменять структуру нескольких таблиц. Эти изменения будут не так часты, как в случае наследования с таблицами для каждого класса, однако их нельзя игнорировать (в отличие от метода «Наследование с одной таблицей», в котором эти изменения вообще отсутствуют);
• если в суперклассе изменить определение хотя бы одного атрибута (например, поменять тип данных), это потребует изменить структуру каждой таблицы, представляющей производный класс, поскольку поля суперкласса дублируются во всех таблицах его производных классов;
• при реализации метода поиска данных в абстрактном классе потребуется просматривать все таблицы, представляющие экземпляры производных классов. Это требует большого количества обращений к базе данных.
Выбор соответствующего метода ОРО зависит от исходной логической модели, т. е. от иерархии классов предметной области. При этом одновременно могут использоваться два и более метода ОРО, что связано с необходимостью оптимизировать
No. 6 (54) 2014
BaseClass (абстрактный класс)
СЫИС1а881 (класс)
СМк1С1а882
(класс)
5иЬСШС1а8821 (класс)
ТаЫеС1а88 (таблица)
BaseFieldl Child1Field2 Child2Field3 SubCh¡ld21 F¡eld4
Метод «Наследование с одной таблицей»
ВавеС/авв (абстрактный класс)
СЫМС1ав81 (класс)
сшааюг
(класс)
ЗиЬСИИсЮ1а5з21 (класс)
ТаЫеВаве (таблица)
TableChildl (таблица)
ТаЫеСЫИ2 (таблица)
ТаЫеЗиЬСЫИ21 (таблица)
Метод «Наследование с таблицами для каждого класса»
ВавеС/авв (абстрактный класс)
Attributel
I
ChildClassI (класс) ChildClass2 (класс)
Attribute2 Attribute3
I
ЭиЬСЬ11с1С1аз521 (класс)
>
Attríbute4
ТаЫеСЫкЛ (таблица)
Field 1 Field2
ТаЫеСИПс12
(таблица)
Field 1 Field3
ТаЫеЭиЬСЬ1И21 (таблица)
Field 1 Field3 Field4
Метод «Наследование с таблицами для каждого конкретного класса» Рис. 7. Методы объектно-реляционного отображения
структуру реляционной БД и сократить количество используемых таблиц. Это позволит увеличить скорость выполнения запросов на выборку данных.
Заключение
Представленная иерархия классов экономического кластера является базовым ядром разрабатываемой системы. В настоящий момент в систему заносится информация об угольных шахтах Ростовской области и обо всех ключевых потребителях углеродсодержащих материалов. Дальнейшее развитие предполагает миграцию в сторону веб-приложения и реализацию различных элементов личного кабинета
20
пользователя, а также развитых средств поиска информации по введенным параметрам. Отметим, что представленная иерархия является унифицированной и позволяет реализовать информационную систему для экономического кластера любой отрасли (а не только угольной). Дальнейшим развитием является разработка алгоритмов вычисления оптимальных схем производства конечной продукции с возможностью расчета себестоимости и рентабельности. Для описания классов иерархии была разработана метамодель объектной системы, основные классы которой описаны в статье. В метамодели применены современные тенденции разработки ПО, основанные на технологии MDA.
№ 6 (54) 2014
Список литературы
1. Кураков Ю. И. Влияние отвалов угольных шахт на состояние атмосферы // Химия твердого топлива. 2005. № 6. С. 70-76.
2. Кураков Ю. И., Передерий М. А., Самофалов В. С. Углеродные молекулярные сита из антрацита // Известия вузов. Сев.-Кавк. регион. Естественные науки. Приложение. 2004. № 1. С. 84-92.
3. Кураков Ю. И., Передерий М. А., Самофалов В. С. Дробленые и гранулированные сорбенты из антрацита // Химия твердого топлива. 2004. № 3. С. 46-59.
4. Кураков Ю. И. Износостойкость композитов на основе антрацитов // Известия вузов. Сев.-Кавк. регион. Технические науки. Спец. выпуск. 2005. С. 46-53.
5. Кураков Ю. И. Применение антрацитов Донбасса в качестве наполнителей электродных изделий // Химия твердого топлива. 2006. № 3. С. 68-76.
6. Пеканов С. В. Комплексная переработка бурых углей Примагаданской группы месторождений // Разведка и охрана недр. 2006. № 11. С. 39-42.
7. Кличко А. А. Нетопливное использование углей. М.: Недра, 1978. — 215 с.
8. Липович В. Г. Химия и переработка угля. М.: Химия, 1988. — 336 с.
9. Зайденварг В. Е. Производство и использование водоугольного топлива. М.: Издательство Академии горных наук, 2001. — 173 с.
10. Кинле Х. Активные угли и их промышленное применение. Л.: Химия, 1984. — 326 с.
11. Мухин В. М. Активные угли России. М.: Металлургия, 2000. — 352 с.
12. Передерий М. А. Углеродные сорбенты из ископаемых углей: состояние проблемы и перспективы развития // Химия твердого топлива. 2005. № 1. С. 76-91.
13. Передерий М. А. Получение углеродных адсорбентов и носителей катализаторов из углей различных стадий метаморфизма // Химия твердого топлива. 1997. № 3. С. 39-47.
14. Кличко А. А. Жидкое топливо из углей // Российский химический журнал. 1997. Том ХЫ. № 6. С. 16-22.
15. Горлов Е. Г. Получение из горючих сланцев топливной и нетопливной продукции // Россий-
ский химический журнал. 1994. Том XXXVIII. № 5. С. 70-74.
16. Шпирт М. Я. Рациональное использование отходов добычи и обогащения углей. М.: Недра, 1990. — 221 с.
17. Косинский В. А., Гонцов А. А. Получение фильтрующих материалов, адсорбентов и пигментов из высокозольных антрацитов и отходов их обогащения // Разведка и охрана недр. 2006. № 11. С. 46-48.
18. Гальмалиев А. М., Головин Г. С., Гагарин С. Г. Классификация горючих ископаемых по структурно-химическим показателям и основные пути использования ископаемых углей. М.: НТК «Трек», 2007. — 152 с.
19. Луганцев Б. Б, Ошеров Б. Н., Аверкин А. Н. Расчет и конструирование струговых установок. М.: Горная книга, 2011. — 291 с.
20. Селезнев А. Н. Углеродистое сырье для электродной промышленности. М.: Профиздат, 2000. — 256 с.
21. Чалых Е. Ф. История электродной и электроугольной промышленности. М.: Металлургия, 1992. — 224 с.
22. Олейник П. П. Корпоративные информационные системы: учебник для вузов. Стандарт третьего поколения. СПб.: Питер, 2012. — 176 с.
23. Олейник П. П. Иерархия классов метамодели объектной системы // Объектные системы — 2012: материалы VI Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2012 г.) / под общ. ред. П. П. Олей-ника. Ростов н/Д: ШИ ЮРГТУ (НПИ), 2012. С. 37-40.
24. Олейник П. П. Элементы среды разработки программных комплексов на основе организации метамодели объектной системы // Бизнес-информатика. 2013. № 4 (26). С. 69-76.
25. Эрик Эванс. Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем: пер. с англ. М.: Издательский дом «Вильямс», 2010. — 448 с.
26. Новиков Ф. А., Иванов Д. Ю. Моделирование на UML. Теория, практика, видеокурс. СПб.: Профессиональная литература; Наука и техника, 2010. — 640 с.
27. Коннолли Томас, Бегг Каролин. Базы данных. Проектирование, реализация и сопровождение.
No. 6 (54) 2014
Теория и практика. 3-е издание: пер. с англ. М.: Издательский дом «Вильямс», 2003. — 1440 с.
28. Oleynik P. P. Domain-driven design the database structure in terms of metamodel of object system // Proceedings of 11th IEEE East-West Design & Test Symposium (EWDTS'2013), Institute of Electrical and Electronics Engineers (IEEE), Rostov-on-Don, Russia, September 27-30, 2013, pp. 469-472.
29. Грэхем И. Объектно-ориентированные методы. Принципы и практика. 3-е издание: пер. с англ. М.: Издательский дом «Вильямс», 2004. — 880 с.
30. Олейник П. П. Иерархия классов представления валидационных правил объектной системы // Объектные системы — 2013: материалы VII Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2013 г.) / под общ. ред. П. П. Олейника. Ростов н/Д: ШИ (ф) ЮРГТУ (НПИ), 2013. С. 14-17.
31. Ambler S. W. Agile Database Techniques — Effective Strategies for the Agile Soft-ware, John Wiley & Sons, 2003. — 373 p.
32. Флауер М. Архитектура корпоративных программных приложений: пер. с англ. М.: Издательский дом «Вильямс», 2004. — 544 с.
References
1. Kurakov Yu. I. Vliyanie otvalov ugol'nykh shakht na sostoyanie atmosfery. Khimiya tverdogo topliv, 2005, no. 6, рр. 70-76.
2. Kurakov Yu. I., Perederiy M. A., Samofalov V. S. Uglerodnye molekulyarnye sita iz antratsita. Izvesti-ja vuzov. Sev.-Kavk. region. Estestvennyje nauki. Prilozhenie, 2004, no. 1, рр. 84-92.
3. Kurakov Yu. I., Perederiy M. A., Samofalov V. S. Droblennye i granulirovannye sorbenty iz antratsita. Khimiya tverdogo topliva. 2004, no. 3, рр. 46-59.
4. Kurakov Yu. I. Iznosostoykost' kompozitov na os-nove antratsitov. Izvestija vuzov. Sev.-Kavk. region. Tekhnicheskie nauki. Spets. Vypusk, 2005, рр. 46-53.
5. Kurakov Yu. I. Primenenie antra-tsitov Donbassa v ka-chestve napolniteley elektrodnykh izdeliy. Khimiya tverdogo topliva, 2006, no. 3, рр. 68-76.
6. Pekanov S. V. Kompleksnaya pererabotka burykh ugley primagadanskoy gruppy mestorozhdeniy. Razvedka i okhrana nedr, 2006, no. 11, рр. 39-42.
7. Klichko A. A. Netoplivnoe ispol'zovanie ugley. M.: Nedra, 1978. 215 р.
8. Lipovich V. G. Khimiya ipererabotka uglya. M.: Khimiya, 1988. 336 р.
9. Zaydenvarg V. E. Proizvodstvo i ispol'zovanie vodougol'nogo topliva. M.: Izdatelstvo Akademii Gornyh Nauk, 2001. 173 р.
10. Kinle Kh. Aktivnye ugli i iz promyshlennoe primenenie. L.: Khimiya, 1984. 326 р.
11. Mukhin V. M. Aktivnye ugli Rossii. M.: Metallurgiya, 2000. 352 р.
12. Perederiy M. A. Uglerodnye sorbenty iz iskopae-mykh ugley: sostoyanie problemy i perspektivy razvitiya. Khimiya tverdogo topliva, 2005, no. 1, рр. 76-91.
13. Perederiy M. A. Poluchenie uglerodnykh adsorben-tov i nositeley katalizatorov iz ugley razlichnykh sta-diy metamorfizma. Khimiya tverdogo topliva, 1997, no. 3, рр. 39-47.
14. Klichko A. A. Zhidkoe toplivo iz ugley. Rossiyskiy kh-imicheskiy zhurnal, 1997, T. XLI, no. 6, рр. 16-22.
15. Gorlov E. G. Poluchenie iz goryuchikh slantsev toplivnoy i netoplivnoy produktsii. Rossiyskiy khimi-cheskiy zhurnal, 1994, T. XXXVIII, no. 5, рр. 70-74.
16. Shpirt M. Ya. Ratsional'noe ispol'zovanie otkhodov dobychi i obogashcheniya ugley. M.: Nedra, 1990. 221 р.
17. Kosinskiy V. A., Gontsov A. A. Poluchenie fil'truyushchikh materialov, adsorbentov i pigmen-tov iz vysokozol'nykh antratsitov i otkhodov ikh obogashcheniya. Razvedka i okhrana nedr, 2006, no. 11, рр. 46-48.
18. Gal'maliev A. M., Golovin G. S., Gagarin S. G. Klassifikatsiya goryuchikh iskopaemykh po struk-turno-khimicheskim pokazatelyam i osnovnye puti ispol'zovaniya iskopaemykh ugley. M.: NTK «Trek», 2007. 152 р.
19. Lugantsev B. B., Osherov B. N., Averkin A. N. Ra-schet i konstruirovanie strugovykh ustanovok. M.: Gornaya kniga, 2011. 291 р.
20. Seleznev A. N. Uglerodistoe syfye dlya elektrodnoy promyshlennosti. M.: Profizdat, 2000. 256 р.
21. Chalykh E. F. Istoriya elektrodnoy i elektrougol'noy promyshlennosti. M.: Metallurgiya, 19992. 224 р.
22. Oleynik P. P. Korporativnye informatsionnye siste-my: Uchebnik dlya vuzov. Standart tret'yego poko-leniya. SPb.: Piter, 2012. 176 р.
23. Oleynik P. P. Ierarkhiya klassov metamodeli ob''ektnoy sistemy. Ob''ektnye sistemy — 2012: materialy VI Mezhdunarodnoy nauchno-praktiches-
№ 6 (54) 2014
koy konferentsii (Rostov-na-Donu, 10-12 maya 2012 g.) pod obshch. red. P. P. Oleynika. Rostov-na-Donu: ShI YuRGTU (NPI), 2012, pp. 37-40.
24. Oleynik P. P. Elementy sredy razrabotki pro-grammnykh kompleksov na osnove organizatsii metamodeli ob''ektnoy sistemy. Biznes-informati-ka, 2013, no. 4 (26), pp. 69-76.
25. Erik Evans. Predmetno-orientirovannoe proek-tirovanie (DDD). Strukturizatsiya slozhnykh pro-grammnykh sistem: per. s angl. M.: Izdatel'skiy dom «Vil'yams», 2010. 448 p.
26. Novikov F. A., Ivanov D. Yu. Modelirovanie na UML. Teoriya, praktika, videokurs. SPb.: Professional'naya literatura, Nauka i tekhnika, 2010. 640 p.
27. Konnolli Tomas, Begg Karolin. Bazy dannykh. Pro-ektirovanie, realizatsiya i soprovozhdenie. Teoriya i praktika. 3-e izdanie: per. s angl. M.: Izdatel'skiy dom «Vil'yams», 2003. 1440 p.
28. Oleynik P. P. Domain-driven design the database structure in terms of metamodel of object system.
Proceedings of 11th IEEE East-West Design & Test Symposium (EWDTS'2013), Institute of Electrical and Electronics Engineers (IEEE), Rostov-na-Donu, Russia, September 27-30, 2013, pp. 469-472.
29. Grekhem I. Ob"ektno-orientirovannye metody. Printsipy i praktika. 3-e izdanie.: per. s angl. M.: Izdatel'skiy dom «Vil'yams», 2004. 880 p.
30. Oleynik P. P. Ierarkhiya klassov predstavleniya val-idatsionnykh pravil ob''ektnoy sistemy. Ob''ektnye sistemy — 2013: materialy VII Mezhdunarodnoy nauchno-prakticheskoy konferentsii (Rostov-na-Donu, 10 -12 maya 2013 g.), pod obshch. red. P. P. Oleynika. Rostov-na-Donu: ShI (f) YuRGTU (NPI), 2013, pp. 14-17.
31. Ambler S. W. Agile Database Technique — Effective Strategies for the Agile Soft-ware, John Wiley & Sons, 2003. 373 p.
32. Flauer M. Arkhitektura korporativnykh pro-grammnykh prilozheniy: per. s angl. M.: Izdatel'skiy dom «Vil'yams», 2004. 544 p.
P. Oleynik, PhD in Technique, System Architect Software, Aston OJSC, Associate Professor, SI (b) Platov SRSPU (NPI), Shakhty, xsl@list.ru
Yu. Kurakov, Dr of Technique, Professor, Director of SI (b) Platov SRSPU (NPI), Head of the chair of «Pure Sciences», Shakhty, phisycs@yandex.ru
The concept for creation of service corporate information systems of economic industrial energy cluster
The article discusses the creation of an information system that automates the activities of the group of coal companies organized in economic production and energy cluster in order to increase profitability and reduce the cost of the final product. The article considers the metamodel of object system, the basic elements to represent the classes, associations, attributes. Represented by a class hierarchy to represent validation rules of object domain. Describes the most popular object-relation mapping patterns. Presents Single Table Inheritance, Class Table Inheritance and Concrete Table Inheritance patterns. Metamodel described repeatedly tested on a variety of application domains. At its base are implemented information systems for agrosystems, fast food restaurants, beauty salons and in the scientific field. An exemplary organization plan economic cluster coal industry, considered in detail the need for factories and workshops. Presented a unified methodology for designing information systems and describes in detail all its main stages. The article describes the range of products obtained during deep processing of carbonaceous materials and prices on them. The article shows the basic architecture of a corporate information system developed to ensure effective functioning of the units in a single cluster. All submitted material is illustrated with class diagrams unified modeling language UML.
bywords: economic production and energy cluster, deep processing of carbonaceous, corporate information systems, object-oriented design, database, object system metamodel, object-relational mapping patterns.
