CC BY
129
4. Олейник П.П. Элементы среды разработки программных комплексов на основе организации метамодели объектной системы // Бизнес-информатика. 2013. №4(26). - С. 69-76.
5. Олейник П.П. Предметно-ориентированное проектирование структуры базы данных в понятиях метамодели объектной системы // Объектные системы - 2014: материалы VIII Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2014. - С. 41-46.
6. Oleynik P.P. Using metamodel of object system for domain-driven design the database structure. Proceedings of 12th IEEE East-West Design & Test Symposium (EWDTS’2014), Kiev, Ukraine, September 26 - 29, 2014, DOI: 10.1109/EWDTS.2014.7027052
УДК 004.04
UML-ПРОФИЛЬ ПРОЕКТИРОВАНИЯ СТРУКТУРЫ ОБЪЕКТНООРИЕНТИРОВАННОЙ БАЗЫ ДАННЫХ11
Гурьянов Василий Иванович, к.т.н, доцент, Филиал Санкт-Петербургского государственного экономического университета в г.Чебоксары, Россия, Чебоксары, vg2007sns@rambler.ru Олейник Павел Петрович, к.т.н, системный архитектор программного обеспечения,
ОАО "Астон", доцент, Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, Россия, Ростов-на-Дону, xsl@list.ru
В настоящее время большинство нового программного обеспечения информационных системы разрабатывается с применением объектно-ориентированного подхода, что обусловлено наличием множества достоинств. Все чаще этот подход применяется не только для клиентского приложения, но и для реализации структуры БД (при использовании ОРСУБД и ООСУБД). Именно поэтому возникает потребность в применении методик и подходов, позволяющих упростить процесс проектирования ООБД, что является ключевой задачей данной работы.
Идея данной статьи не нова. Так в работах [1-3] один из авторов предложил свое решение описанной проблемы, основанной на построении диаграммы объектов, элементами которой являются экземпляры классов метамодели, представленной в [4-5]. На первый взгляд рабочее решение оказалось совершенно не пригодным при проектировании больших информационных систем, автоматизирующих прикладные предметные области реального мира. Это связано с громоздкостью полученных диаграмм объектов, содержащих большое количество экземпляров и связей между ними. Описанное в тех работах решение не удалось применить при обучении студентов проектированию объектно-ориентированных приложений. Это связано с тем, что обучающиеся вынуждены изучать синтаксис двух UML-диаграмм (диаграмм классов и диаграмм объектов), а это требует дополнительного времени и увеличивает время выполнения лабораторных работ.
С целью исключения описанных недостатков предыдущих работ появилась необходимость в поиске альтернативного подхода. Такое решение в настоящий момент авторы видят в разработке собственного UML-профиля, что позволит упростить процесс проектирования программных продуктов. Этот подход успешно и многократно применялся первым автором данной статьи, что описано в работах [6-8]. Именно тонкостям разработки собственного UML-профиля, который оперирует сущностями метамодели объектной системы, и посвящена данная статья.
Для демонстрации полученного решения будем использовать тестовую объектную статическую модель, описанную в [9] и представленную на рис. 1.
11 Статья рекомендована к опубликованию в журнале "Информационные технологии"
73
Рис. 1 - Унифицированная модель тестирования инструментов разработки объектно-
ориентированных приложений, заимствованная из [9]
Эта модель была построена и полностью удовлетворяет следующим критериям оптимальности [10]:
1. Наличие глубоких иерархий наследования. В реальных приложениях очень часто появляются глубокие иерархии, представляемые отношением наследования и объединяющие транзитивно не менее трех классов.
2. Присутствие нескольких иерархий наследования. Это позволит продемонстрировать различные опции и режимы, имеющиеся в инструменте.
3. Наличие абстрактных классов в иерархии. Абстрактные классы не могут иметь экземпляров в системе и описаны в качестве контейнеров для атрибутов и методов, используемых в производных реальных (инстанцируемых) классах.
4. Присутствие множественных n-арных ассоциаций. В приложениях, автоматизирующих реальные прикладные области, часто возникают ассоциации, в которых участвуют три и более классов. Подобные отношения называют множественными или n-арными ассоциациями.
5. Наличие ассоциаций с атрибутами. Многие предметные области содержат атрибуты, которые не принадлежат определенным сущностям, и их значения появляются только при организации связей между экземплярами классов. Проектируемая унифицированная модель должна иметь ассоциации с атрибутами.
6. Присутствие композиции между классами. Композиция - это ассоциация между классами, представляющими Часть и Целое. Особенность в том, что класс, представляющий Часть, может входить только в один экземпляр класса, представляющий Целое. При этом класс, представляющий Целое, управляет жизненным циклом класса, представляющего Часть. Т.е. при удалении Целого, Части также удаляются. Эта особенность поведения очень важна для многих прикладных предметных областей.
7. Наличие рекурсивных ассоциаций. Рекурсивными называют ассоциации, концы которых связывают один и тот же класс. Подобные отношения позволяют реализовать иерархию подчинения.
8. Наличие ассоциаций между классами, входящими в одну иерархию наследования. С точки зрения реализации необходимо предусмотреть реализацию ассоциаций, края которых связывают классы, входящие в одну иерархию наследования, т.е. представляют базовый и дочерний классы друг к другу.
9. Присутствие класса-ассоциации. Класс-ассоциация - это ассоциация, которая в то же время является и классом. Особенность использования в том, что класс-ассоциация
74
представляет собой уникальную ассоциацию, т.е. комбинация экземпляров классов в этой ассоциации является уникальной.
10. Наличие ассоциаций между классом-ассоциацией и другим классом. С теоретической точки зрения класс-ассоциация - это класс, поэтому он может участвовать в других ассоциациях. С точки зрения реализации класс-ассоциация приставляет собой класс, содержащий атрибуты (поля или свойства языка программирования), которые ссылаются на другие классы. В свою очередь для организации ассоциации с классом-ассоциацией необходимо в зависимом классе создать атрибут, типом которого выступает класс-ассоциация.
11. Присутствие в модели перечислений. С теоретической точки зрения перечисление -это набор предопределенных констант, при этом пользователю нельзя расширить этот набор путем добавления новых значений.
Для реализации современных программных продуктов очень часто используется подход, называемый «архитектура, управляемая моделью (MDA)». Этот подход подразумевает наличие собственной среды разработки, представляющей инструменты для разработки конечного приложения. Для целей данной статьи будем использовать унифицированную среду быстрой разработки SharpArchitect RAD Studio [4-5]. Инструмент предполагает разработку программного продукта в понятиях метамодели объектной системы с созданием в графическом интерфейсе экземпляров метаклассов, представляющих сущности предметной области и различные типы атрибутов. Поэтому необходимо выделить соответствующие метаклассы профиля UML, позволяющие упростить процесс проектирования прикладных программных продуктов. При этом рассматриваются только классы предметной области, атрибуты и ассоциации, т.к. это наиболее часто используемые элементы для разработки приложений баз данных. Полученный профиль получил название SharpArchitect UML Profile (SAUP).
UML активно используется при проектировании различных элементов информационных систем, например, при реализации клиентского приложения. Известны также профили UML, предназначенные для проектирования структуры БД. Например, UML Data Modeling Profile, разработанный Rational Software из IBM, предназначен для проектирования реляционных БД [10]. В данной статье далее предлагается профиль SharpArhitect UML Profile (SAUP), который предназначен для проектирования ООБД в понятиях метамодели объектной системы. Профиль ориентирован на среду разработки SharpArhitect RAD Studio.
Профиль SAUP разработан на основе спецификации UML 2.0 [11]. В качестве метамодели платформы используется метамодель [1-5]. Общая структура профиля показана на рис. 2.
Пакет Elements определяет основные элементы профиля. Пакет TypedAttributes определяет набор стереотипов для атрибутов с типами данных, определенных в пакете DataTypes, который в свою очередь импортирует типы данных из среды разработки SharpArhitect RAD Studio. В профиле задано ограничение - стереотипы атрибутов должны соответствовать типам данных. Это ограничение задается специальной таблицей. Для построения метамодели профиля использованы элементы стандартного профиля UML (стереотипы и типы данных).
Структура пакета Elements показана на рис. 3. Каждый стереотип определяет некоторое множество помеченных значений, которые поставляют данные классам среды проектирования SharpArhitect RAD Studio (см. метамодель объектной системы [1-5]).
Стереотип DomainClass определяет ряд помеченных значений, которые поставляют данные классу предметной области DomainClass. Стереотип DomainAssociation поставляет данные классам Association и AssociationEnd. Стереотип TypedAttribute определяет общие помеченные значения для классов типов данных (рис. 4).
75
Рис. 2 - Архитектура UML-профиля SharpArchitect UML Profile (SAUP)
Стереотипы атрибутов, определяемые в пакете TypedAttributes, находятся в отношении обобщения со стереотипом TypedAttribute, что отражено в зависимости пакета TypedAttributes от пакета Elements.
<<metadass>>
Association
5
0..1
<<metadass>>
Classifier
A
+member3nd
2,
0.. 1
+owiedEnd
• -navigableOwnedEnd
* V
<<metadass>>
Property
+ownedA
+class
tribute
<<stereotype>>
EnumClass
<<metaclass>>
Class
<<stereotype>>
TypedAttribute
+Caption: String
+Options: TypedAttributeOption
<<stereotype>>
DomainClass
<<stereotype>> DomainClassAssociation <<enumeration>> DomainAssodationOption
+Caption; String +Name: String +Options: DomainAssodationOption +None +Aggregated +AutoCreateInstance
+Caption: String +ImageName: String +Options: DomainClassOption +MultipledClassedValueAttributeOptions: MCVAOption
<<enumeration>>
TypedAttributeOption
+None
+Required
+ShowByDefault
+ImmediateCallChange
+ExdudeFrom5earch
+Invisible
+Unique
<<enumeration>> DomainClassOption
+None +Abstract +ShowInGUI +Allo|ACloneObjects +SavingObjectsInBaseClassTable +NotPersistent +Singleton ->| +Sealed
<<enumeration>>
MCVAOption
+None
+Aggregated
+Create5eparateForm
Рис. 3 - Структура пакета Elements
Девять стереотипов (DecimalAttribute, EnumAttribute, FileDataAttribute,
HelperClassAttribute, IntAttribute, MetaModelClassAttribute, TextAttribute, TypeAttribute, StringAttribute) имеют дополнительные помеченные значения. Остальные стереотипы атрибутов просто наследуют помеченные значения от стереотипа TypedAttribute. Кроме того, в профиле отдельно от рис. 3 определен стереотип «N-AryAssociation», который обозначает n-арные ассоциации. В качестве метаклассов использованы UML-элементы Class и Association. Профиль SAUP реализован на языке XML для UML-редактора StarUML (ver. 5.0). На рис. 5 показан пример применения стереотипов профиля для модели рис. 1.
Стереотипом «N-AryAssociation» помечена n-арная ассоциация Position. На диаграмме так же присутствуют стандартные UML-элементы, например, класс-ассоциация. Стереотипы отчетливо показывают, какие элементы модели должны быть доопределены.
76
Рис. 4 - Структура пакета TypedAttributes
Рис. 5 - UML диаграмма классов унифицированной модели тестирования инструментов разработки
объектно-ориентированных приложений, построенная с применением профиля SAUP
На диаграмме в качестве примера для классов со стереотипом DomainClass явно показаны помеченные значения Caption, а для класса Employee - также одно из помеченных значений стереотипа атрибута EID. Хотя все атрибуты проектной модели должны быть помечены стереотипами, их можно не отображать на диаграммах. Точно так же можно скрывать помеченные значения стереотипов. Это позволяет проводить концептуальное и логическое проектирование, не детализируя спецификацию UML-элементов.
77
Как видно из представленного рисунка, разработанный профиль позволяет проектировать объектно-ориентированные приложения баз данных для различных прикладных предметных областей. При этом проектирование с применением UML профиля по сути представляет собой построение диаграммы классов, что вполне логично и естественно по сравнению с построением диаграмм объектов метаклассов объектной системы, предложенное в работах [1-3]. Авторы считают текущее решение оптимальным и намерены использовать в будущем только его.
В данной статье предложен профиль UML для проектирования ООБД в понятиях метамодели объектной системы, который получил название SharpArhitect UML Profile (SAUP). Этот профиль расширяет спецификацию UML-элементов под потребности унифицированной среды проектирования SharpArhitect RAD Studio и свободен от основных недостатков в отличие от подхода, основанного на диаграммах объектов, предложенного ранее одним из авторов статьи. Дальнейшим развитием работы авторы видят расширение профиля для представления других видов классов, которые имеются в описанной среде разработки. Кроме того, необходимо апробировать данный профиль на проектах более крупных приложений и добавить отсутствующие элементы в SAUP.
Литература
1. 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.
2. Олейник П.П. Предметно-ориентированное проектирование структуры базы данных в понятиях метамодели объектной системы // Объектные системы - 2014: материалы VIII Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2014. -С. 41-46.
3. Oleynik P.P. Using metamodel of object system for domain-driven design the database structure // Proceedings of 12th IEEE East-West Design & Test Symposium (EWDTS’2014), Kiev, Ukraine, September 26 - 29, 2014, DOI: 10.1109/EWDTS.2014.7027052
4. Олейник П.П. Иерархия классов метамодели объектной системы // Объектные системы -2012: материалы VI Международной научно-практической конференции (Ростов-на-Дону, 1012 мая 2012 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2012. -С. 37-40.
5. Олейник П.П. Элементы среды разработки программных комплексов на основе организации метамодели объектной системы // Бизнес-информатика. 2013. №4(26). - С. 69-76.
6. Гурьянов В.И. Профиль UML для имитационного моделирования // Объектные системы -2013: материалы VII Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2013 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГТУ (НПИ),
2013. С. 39-45.
7. Гурьянов В.И. Моделирование классификаций на визуальном языке имитационного моделирования UML SP // Сборник докладов шестой всероссийской научно-практической конференции «Имитационное моделирование. Теория и практика» (ИММОД-2013). Том 1. // Издательство «ФЭН» Академии наук РТ, Казань, 2013, - С. 128-132.
8. Гурьянов В. И. Имитационное моделирование на UML SP: монография / В.И. Гурьянов. -Чебоксары : Филиал СПбГЭУ в г. Чебоксары, 2014. - 135 с.
9. Олейник П.П. Унифицированная модель тестирования инструментов разработки объектноориентированных приложений // Объектные системы - 2014 (Зимняя сессия): материалы IX Международной научно-практической конференции (Ростов-на-Дону, 10-12 декабря 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова,
2014. -С. 25-35.
10. The UML and Data Modeling, White Paper. Technical report, Rational Software, 2003.
78
11. Object Management Group. UML 2.0 Infrastructure Specification, OMG document number formal/2011-08-05, 2011.
UNIFIED METAMODEL OF OBJECT SYSTEM
Pavel P. Oleynik, PhD, System Architect Software, Aston JSC, Associate Professor, Shakhty Institute (branch) of Platov South Russian State Polytechnic University (NPI), Russia, Rostov-on-Don, xsl@list.ru
This article describes the unified metamodel of object system which can be used for domain-driven design (DDD) of information system. The idea of the design based on the metamodel is not new since metamodels are used everywhere. Works [1-3] represent the metamodel of object database compliant with the ODMG standard. The SQL:2003 standard includes metamodel that describes the object extensions of SQL [1, 3-4]. The graphical modeling language UML which is often used in the design of modern applications has the standard which governs its own metamodel described in [3, 5].
Practically all the metamodels have some disadvantages. Each author was trying to solve the problem own forces. Thus, in [3], the author has developed its own metamodel for implementing object database.
Metamodel does not exist independently of the rest of the application, and serves a certain purpose. So in [6-7] metamodel is used to facilitate the process of domain-driven design.
Metamodel is also used in the model transformations. So in [8-9] the principles of model transformations from the UML metamodel in the models of languages developed by the authors are described.
Mechanisms for evaluating the software quality based on metamodel with the introduction of various metrics are considered in [10-11]. Publications [12-13] are devoted to questions of the expansion of existing metamodels by adding new elements. In [1], the author offers his own hierarchy of atomic literal types, which can be used in any object system and built thanks to the author's experience.
In this article, we briefly review the metamodel used in a unified development environment for the rapid development of enterprise information systems, SharpArchitect RAD Studio [14]. In [6-7, 15-18] the full class diagram of metamodel was presented and detailed assignment of classes were described. Here we consider only the relevant parts for this article. Fig. 1 shows a fragment of a unified metamodel of object system with display of the key associations that are important for further discussion.
Consider some of the key hierarchies of metaclasses. Fig. 2 is a diagram of the basic metaclasses used to represent different kinds of classes applied to describe the entity classes which are presented in the domain model.
An abstract metaclass Class is the root of the hierarchy. It has two inherited classes: 1) InheritableClass is used to represent metaclasses that can be inherited, i.e. support inheritance; 2) NotInheritableClass is used to represent metaclasses that can not be inherited. Metaclass Enum allows submit an enumeration or a set of values of a simple type.
Abstract base metaclass CustomAttributedClass is used to represent metaclasses that have the attributes. Metaclass DomainClass is used to represent domain classes. Instances of domain classes allow to describe the entity classes (such as Customers, Products, Sales), which objects (eg, Ivanov, Bread) are stored in the database. To simplify the description instances of the domain classes will be called just domain classes (if not assumed otherwise).
Abstract metaclass ComputationalClass<TBaseClass> is the base for all calculated metaclasses ie those classes instances of which are not stored in the database and are computed at runtime (transient). For example, the turnover balance sheet is not stored directly in the database, and is calculated based on inventory, receipts and expenditures (which are the domain classes and
79
