CC BY
51
4. Скворцов Н.А. Вопросы согласования неоднородных онтологических моделей и онтологических контекстов // Онтологическое моделирование. - 2008. - С. 149-166.
5. Beck H., H. S. (2002). Overview of approach, methodologies, standards, and tools for ontologies. Материалы Third Agricultural Ontology Workshop. Food and Agricultural Organization of the United Nations. Получено из http://aims.fao.org.
6. Голенков В.В. Принципы построения массовой семантической технологии компонентного проектирования интеллектуальных систем / В.В.Голенков, Гулякина Н.А. // Материалы междунар. науч.-техн. конф. «Открытые семантические технологии проектирования интеллектуальных систем» (0STIS-2011). Минск, 10—12 февраля 2011 г. - Минск, 2011. - С. 21—58.
7. Грегер С.Э., Сковородин Е.Ю. Построение онтологического портала с использованием объектной базы // Объектные системы - 2010: Материалы I Международной научно-практической конференции. Россия, Ростов-на-Дону, 10-12 мая 2010 г / под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2010. С. 74-78.
8. Загорулько Ю.А. Подход к построению интеллектуальных информационных систем на основе семантических сетей // Международная научно-техническая конференция «Открытые семантические технологии проектирования интеллектуальных систем» (Open Semantic Technologies for Intelligent Systems)— OSTIS-2011, 10-12 февраля 2011 года, Минск, Белоруссия, Белорусский государственный университет информатики и радиоэлектроники.
9. Stephane JEAN, Y. A.-A. (б.д.). An Object-Oriented Based Algebra for Ontologies and their Instances, Advances in Databases and Information Systems (ADBIS'07), Varna Bulgaria,2007, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.82.68
УДК 04.004
ОСНОВНЫЕ ЭТАПЫ МЕТОДОЛОГИИ МЕТАМОДЕЛЬНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ ПРИЛОЖЕНИЙ БАЗ ДАННЫХ
Олейник Павел Петрович, к.т.н, Системный архитектор программного обеспечения, ОАО "Астон", доцент, Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, Ростов-на-Дону, xsl@list.ru
Введение
Многие современные информационные системы являются программными приложениями баз данных. При этом в качестве хранилища информации используются реляционные системы управления базами данных (РСУБД), а для реализации бизнес-логики применяют объектно-ориентированные языки программирования (ООЯП). Из-за различий в подходах к управлению данными возникает так называемое объектно-ориентированное несоответствие (ОРН), для преодолений последствий которого применяется множество частных решений. В данной статье кратко описана разработанная автором методология метамодельно-ориентированного проектирования приложений баз данных (МММОППБД) которая позволяет реализовать различные этапы проектирования разрабатываемой информационной системы и в конечном итоге реализовать приложение с развитым графическим интерфейсом.
1. Этапы методологии метамодельно-оиентированного проектирования приложений баз данных
Данная методология разрабатывалась автором в течение последних нескольких лет и протестирована на множестве проектов в различных сферах деятельности: от
высокочастотного биржевого трейдинга и до автоматизированного управления сетью салонов красоты. МММОППБД подразумевает следующие этапы:
1. Концептуальное проектирование.
2. Метамодельное проектирование.
3. Сущностное проектирование.
4. Имплементационное проектирование.
5. Презентационное проектирование.
Рассмотрим каждый этап более подробно. Концептуальное проектирование представляет собой высокоуровневое проектирование, основная цель которого заключается в создании обобщенного графического представления будущей информационной системы [12]. Концептуальное проектирование также называют инфологическим и используют для построения модели предметной области, применяя при этом различные графические нотации. В настоящее время очень часто для описанных целей применяют модель «сущность-связь», цель создания которой заключается в отображении сущностей моделируемой предметной области, атрибутов сущностей, описывающих характеристики объектов и имеющихся связей. При этом для графического представления применяют нотацию наиболее популярного сегодня графического унифицированного языка моделирования UML.
Метамодельное проектирование представляет собой своеобразное логическое проектирование, то есть описание элементов концептуальной модели в понятиях выбранной модели данных. Преобразование концептуальной модели в логическую модель должно осуществляться по определённым ранее формальным правилам. Т.е. при метамодельном проектировании учитывается специфика выбранной конкретной модели данных. При этом не учитывается специфика конкретной реализации структуры БД и используемой СУБД. Для данного вида проектирования используется унифицированная метамодель объектной системы [3-4]. При этом для формализации представления моделей прикладных предметных областей в понятиях унифицированной метамодели объектно-ориентированных приложений баз данных и выполнения её проверки (валидации и верификации) имеется разработанный автором математический аппарат [5-6]. Для упрощения графического представления результатов данного проектирования был разработан пользовательский UML-профиль [7].
Многие новые современные программные продукты разрабатываются с помощью объектно-ориентированных языков программирования (ООЯП). Такая популярность вызвана наличием апробированной многолетним использованием ОО-парадигмы и наличия инкапсуляции, наследования и полиморфизма, позволяющих повторно использовать написанные ранее программные классы и компоненты. Это сокращает время на разработку как нового продукта, так и на доработку существующего. Таким образом, возникает задача представления модели предметной области в понятиях выбранного языка программирования. Именно для этого предназначено сущностное проектирование, суть которого заключается в выделении сущностей предметной области после метамодельного проектирования в виде синтаксических конструкций языка программирования. По своей сути это первая программная реализация приложения и она зависит от выбранного языка программирования. Наличие её позволяет прототипировать и отлаживать программный продукт еще на этапе проектирования. Кроме того, сущностное проектирование позволяет использовать такие подходы, которые не поддерживаются напрямую в языке программирования, так называемый «синтаксический сахар». Например, многие современные ООЯП не поддерживают механизм множественного наследования реализаций и технологию примесей, которая может быть представлена в виде синтаксической конструкции interface. Затем, описанные концепции могут быть реализованы с помощью дополнительного программного кода [8].
Имплементационное проектирование необходимо для реализации модели, полученной при сущностном проектировании, в виде синтаксических конструкций выбранного языка программирования и объектов баз данных. Т.к. в настоящее время чаще всего применяют ООЯП, а для сохранения информации реляционную модель данных, то при имплементационном проектировании необходимо выполнить два вида проектирования. Первым является имплементационное объектно-ориентированное проектирование, суть которого заключается в построении UML-диаграммы классов, содержащей классы и ассоциации для выделенных ранее сущностей. Вторым является имплементационное реляционное проектирование, цель которого заключается в создании ER-диаграммы реляционных отношений для выбранной СУБД.
Презентационное проектирование применяется для наглядного представления графических форм приложения, предназначенных для просмотра и редактирования существующей информации и ввода новой. В ходе данного этапа создается набор моделей, содержащих графическое представление сущностей предметной области в разработанной нотации [9].
Несмотря на наличие множества трудоёмких, с точки зрения разработчика, этапов, часть из них можно автоматизировать. Опыт показал, что разработчику информационной системы необходимо корректно выполнить только метамодельное проектирование. Т.е. благодаря наличию собственного UML-профиля нет необходимости в концептуальном проектировании, т.к. имеет смысл сразу проектировать в понятиях экземпляров метаклассов объектной системы. Сущностное проектирование может быть выполнено автоматически на основании информации, заносимой в ходе метамодельного проектирования, добавив соответствующие атрибуты и набор предопределённых значений в полученную UML-диаграмму классов. Имплементационное проектирование также можно автоматизировать с помощью генераторов программного кода, позволяющих создавать имплементационные ОО-модели. Применением методов (паттернов) объектно-ориентированного отображения можно автоматизировать имплементационное реляционное проектирование для РСУБД. Для автоматизации презентационного проектирования можно отделить представление данных в интерфейсе пользователя от механизмов хранения данных. Предоставляя механизмы настройки конечному пользователю, можно добиться быстрого прототипирования приложения и освободить разработчика от этой обязанности. Описанная методология успешно реализована в созданной автором данной статьи унифицированной среде быстрой разработки корпоративных информационных систем SharpArchitect RAD Studio [10].
2. Примеры реализации описанных этапов МММОППБД
Для наглядной демонстрации всех этапов метамодельного проектирования необходимо выбрать любую прикладную предметную область. Рассмотрим в качестве примера унифицированную модель тестирования инструментов разработки объектно-ориентированных приложений [1-2].
Перед проектированием унифицированной модели тестирования были выдвинуты критерии оптимальности (КО), представляющие собой требования о наличии определенных структурных элементов на диаграмме классов и которым должна соответствовать готовая реализация. Были выдвинуты следующие требования для унифицированной модели тестирования инструментов разработки объектно-ориентированных приложений:
1. Необходимо наличие глубоких иерархий наследования. В реальных приложениях очень часто появляются глубокие иерархии, представляемые отношением наследования и объединяющие транзитивно не менее трех классов.
2. Присутствие нескольких иерархий наследования. Это позволит продемонстрировать различные опции и режимы, имеющиеся в инструменте.
3. Наличие абстрактных классов в иерархии. Абстрактные классы не могут иметь
экземпляров в системе и описаны в качестве контейнеров для атрибутов и методов, используемых в производных реальных (инстанцируемых) классах.
4. Присутствие множественных (п-арных) ассоциаций. В приложениях, автоматизирующих реальные прикладные области, часто возникают ассоциации, в которых участвуют три и более классов. Подобные отношения называют множественными или п-арными ассоциациями.
5. Наличие ассоциаций с атрибутами. Многие предметные области содержат атрибуты, которые не принадлежат определенным сущностям, и их значения появляются только при организации связей между экземплярами классов. Поэтому проектируемая унифицированная модель должна иметь ассоциации с атрибутами.
6. Присутствие композиции между классами. Композиция - это ассоциация между классами, представляющими Часть и Целое. Особенность в том, что класс, представляющий Часть, может входить только в один экземпляр класса, представляющий Целое. При этом класс, представляющий Целое, управляет жизненным циклом класса, представляющего Часть. Т.е. при удалении Целого, Части также удаляются. Эта особенность поведения очень важна для многих прикладных предметных областей.
7. Наличие рекурсивных ассоциаций. Рекурсивными называют ассоциации, концы которых связывают один и тот же класс. Подобные отношения позволяют реализовать иерархию подчинения.
8. Наличие ассоциаций между классами, входящими в одну иерархию наследования. С точки зрения реализации необходимо предусмотреть ассоциации, края которых связывают классы, входящие в одну иерархию наследования, т.е. противопоставляют базовый и дочерний класс друг другу.
9. Присутствие класса-ассоциации. Класс-ассоциация - это ассоциация, которая в то же время является и классом. Особенность использования в том, что класс-ассоциация представляет собой уникальную ассоциацию, т.е. комбинация экземпляров классов в этой ассоциации является уникальной.
10. Наличие ассоциаций между классом-ассоциацией и другим классом. С теоретической точки зрения, класс-ассоциация - это класс, поэтому он может участвовать в других ассоциациях. С точки зрения реализации, класс-ассоциация представляет собой класс, содержащий атрибуты (поля или свойства языка программирования), которые ссылаются на другие классы. В свою очередь для организации ассоциации с классом-ассоциацией необходимо в зависимом классе создать атрибут, типом которого выступает класс-ассоциация.
11. Присутствие в модели перечислений. С теоретической точки зрения перечисление -это набор предопределенных констант, при этом пользователю нельзя расширить этот набор путем добавления новых значений.
В ходе выполнения концептуального проектирования использовался подход построения модели «сущность-связь», который заключался в графическом представлении выделенных сущностей предметной области, их атрибутов и имеющихся связей. Результат представлен на рис. 1.
Как видно из рисунка, в результате была получена диаграмма классов в нотации ЦМЬ. Выполнение метамодельного проектирования основано на создании экземпляров метаклассов унифицированной метамодели объектной системы. По сути, разработчику предоставляются несколько видов сущностей, которые используются для построения модели предметной области.
Виды создаваемых сущностей могут быть следующего типа:
1. Сохраняемые. Они используются для преставления информации, которая физически хранится в базе данных. Описание подобных сущностей выполняется с помощью создания экземпляров метакласса DomainClass.
2. Вспомогательные. Экземпляры этих сущностей не сохраняются в БД, но их представление в системе необходимо для упрощения как в реализации бизнес-логики, так и для отображения вспомогательной информации в интерфейсе пользователя. Описание подобных сущностей выполняется с помощью создания экземпляров метакласса HelperClass.
3. Классы-параметры методов. Основная бизнес-логика приложения реализуется в виде методов классов. Этот подход соответствует объектно-ориентированной парадигме. При этом в конечном итоге методы представляются пользователю в виде элементов графического интерфейса, например, в виде кнопок. При этом методы могут принимать набор параметров. Описание подобных сущностей выполняется с помощью создания экземпляров метакласса MethodParameterClass.
4. Классы-перечисления/множества. Эти классы используются в том случае, когда атрибут может принимать определенное значение из описанного ранее набора и этот набор не может расширяться пользователями. Описание подобных сущностей выполняется с помощью создания экземпляров метакласса Enum.
Для получения графических моделей создан собственный UML-профиль.
Post Name
-5—5"
ExperiencePost MinExperMonth
ScientificPost AcademicRank
Рис. 1 - Результирующая модель концептуального проектирования UML активно используется при проектировании различных элементов информационных систем, в том числе приложений баз данных. Известны так же профили UML, предназначенные для проектирования структуры реляционных БД. Далее предлагается профиль SharpArhitect UML Profile (SAUP), который предназначен для проектирования ООБД (Объектно-ориентированные БД) в понятиях метамодели объектной системы [7-8].
В настоящее время объектно-ориентированный подход используется повсеместно, в том числе и при реализации уровня хранения данных. Использование ОО-парадигмы на уровне БД позволяет применять такие механизмы как наследование, что отсутствует в других моделях данных, например, в РБД (Реляционная БД). Например, мы может объявить базовый класс и реализовать в нём наиболее общие атрибуты, а затем унаследовать их в производных классах. При использовании РСУБД разработчику необходимо в каждом отношении, реализуемом таблицей, повторно объявлять одинаковые атрибуты. Также ОО-подход позволяет реализовать древовидные (иерархические) структуры с реализацией рекурсивных запросов, что довольно трудоёмкая задача для РБД. Профиль ориентирован на среду разработки SharpArhitect RAD Studio. На рис. 2 представлена графическая модель, полученная в ходе выполнения метамодельного проектирования.
Department
Rate
1..1
Salary
Date Value
Contragent
Name
Worker
DateOfBirth
1..1 0..1
0.;
Include
Company
ÖZT
Employee
EID
0..*
0..*
1..1
о.;
Manager
0..1
Telephone
Number
«enumeration»
TelephoneKind
Home
Personal
Work
Address
Country City Street Building
Office
——
1..1
CompanyAddress
IsRegistered
0
■ EmployeeAddress
< <DomainClass > > Post
■{Caption = Должность}
+Name: String Attribute
&
< <DomainClass > > EHperiencePost {Caption = Рядовая должность}
+MinExperMonth: Int Attribute
< <DomainClass > > Department
■{Caption = Отдел}
+Name: String Attribute
IT
< <DomainClass > > Contragent ■{Caption = Контрагент}
+Name: String Attribute
< <DomainClass > > ScietificPost
-{Caption = Эксперт}
<<N-AryAssociation>> Position
■{Caption = Список сотрудников}
+Rate: Decimal Attribute
+AcademicRank: StringAttribute
1
0..*
< <DomainClass > > Salary
■{Caption = Зарплата}
■fDate: DataTimeAttribute +Value: Money Attribute
HE
0.. 1
0..
<<DomainClass>> Company ■{Caption = Компания}
< <DomainClass > > Worker
■{Caption = Работник}
+DateOf Birth: DataTime Attribute
Ж
< <DomainClass > > Employee ■{Caption = Сотрудник}
< <DomainClass > > Telephone ■{Caption = Телефон}
+Number: TelethoneKind
<<EnumClass>> TelephoneKind
+Home
+Personal
+Work
< <DomainClass > >
Address ■{Caption = Адрес}
+Country: StringAttribute +City: StringAttribute +5treet: StringAttribute +Building: StringAttribute +Office: StringAttribute
й Л
< <DomainClass > > CompanyAddress
■{Caption = Адрес компании}
+EID: StringAttribute -{Caption = Табельный номер}
£
< <DomainClass >■>.. Manager {Caption = Менеджер}
0,,*
0,,*
<<DomainClassäSr. ^ EmpioyeeAddress
-[Caption = Адрес сотрудника}-
IsRegistered
Рис. 2 - Результирующая модель метамодельного проектирования
Как видно из рис. 2, была получена диаграмма классов с помощью пользовательского UML-профиля SharpArhitect UML Profile. Перейдем к формальному описанию представленной модели с помощью аппарата, рассмотренного в [5-6]. На основании формулы (1) получаем следующее:
dmfm = (DC)
т.е. унифицированная модель тестирования состоит только из классов предметной области, которыми являются элементы множества DC, определенного как
DC = {Post, ExperiencePost, ScientificPost, Department, Position, Salary, Contagent, Company, Worker, Employee, Manager, Telephone, Address, CompanyAddress, EmployeeAddress, EmployeeEmployeeAddress}
На основании формулы (2) в нашем случае будем использовать формулу вида:
DC = {(ATT, BCdc)}
Т.е. рассмотрим только формальные описания атрибутов и базовых классов, при этом либо атрибуты, либо базовые классы могут быть пустыми (но не оба одновременно).
Post = ({(Name, StringAttribute), (Positions, DomainClassAttribute, 0..*, Position)})
ExperiencePost = ({(MinExperMonth, IntAttribute)}, {Post})
ScientificPost = ({(AcademicRank, StringAttribute)}, {Post})
Department = ({(Name, StringAttribute) ,(Positions, DomainClassAttribute, 0..* , Position)})
Position = ({(Rate, DecimalAttribute), (Post, DomainClassAttribute, 1..1, Post), (Department, DomainClassAttribute, 1..1, Department), (Company, DomainClassAttribute, 1..1, Company), (Worker, DomainClassAttribute, 1..1, Worker), (Salaries, DomainClassAttribute, 0..*, Salary)})
Salary = ({(Date, DateTimeAttribute), (Value, DecimalAttribute), (Position, DomainClassAttribute, 1..1, Position)})
Contragent = ({(Name, StringAttribute), (Telephones, DomainClassAttribute, 0..*, Telephone)})
Telephone = ({(Number, StringAttribute), (Contragent ,
DomainClassAttribute, 1..1, Contragent), (TelephoneKind, EnumAttribute, TelephoneKind)})
Company = ({(CompanyAddress, DomainClassAttribute, 1..1, CompanyAddress), (Owner, GeneratedAttribute, 0..1, Company), (Nodes, GeneratedAttribute, 0..*, Company), (CompanyAddress, DomainClassAttribute, 1..1,
CompanyAddress), (Positions, DomainClassAttribute, 0..*, Position)}, {Contragent, IBaseRunTimeTreeNodeDomainClass})
Worker = ({(DateOfBirth, DateTimeAttribute), (Positions,
DomainClassAttribute, 0..*, Position)}, {Contragent})
Employee = ({(EID, StringAttribute), (Manager, DomainClassAttribute, 0..1, Manager), (EmployeeEmployeeAddresses, DomainClassAttribute, 0..*, EmployeeEmployeeAddress)}, {Worker})
Manager = (Employees, DomainClassAttribute, 0..*, Employee)}, {Employee})
Address = ({(Country, StringAttribute), (City, StringAttribute), (Street, StringAttribute), (Building, StringAttribute), (Office,
StringAttribute)})
CompanyAddress = ({(Company, DomainClassAttribute, 1..1, Company)}, {Address})
EmployeeAddress = ({(EmployeeEmployeeAddresses, DomainClassAttribute, 0..*, EmployeeEmployeeAddress)}, {Address})
EmployeeEmployeeAddress = ({(IsRegistered, LogicalAttribute), (Employee, DomainClassAttribute, 1..1, Employee), (EmployeeAddress,
DomainClassAttribute, 0..*, EmployeeAddress)})
Для описания перечислений/множеств будем использовать запись вида:
EC = {(TelephoneKind, Enum, {Home = 0,Personal = 1, Work = 2})}
Из представленного выше видно, что мы получили полное формальное описание унифицированной модели тестирования инструментов разработки объектно-ориентированных приложений, описываемой в понятиях метамодели, которое может использоваться для проверки корректности (валидации/визуализации) модели в ходе метамодельного проектирования.
Перейдем к сущностному проектированию. Полученная модель представлена на рис. 3. Рассмотрим назначение основных классов представленной диаграммы. Как говорилось ранее, данная диаграмма классов является вымышленной и не предназначена для описания конкретной предметной области, поэтому содержит некоторые нелогичные (вымышленные) классы и ассоциации.
Для представления сотрудников и организаций выделен базовый абстрактный класс Contragent. Унаследованный класс Company представляет организацию, а класс Worker является базовым для сотрудника организации. Унаследованный класс Employee представляет служащего и содержит атрибут EID, сохраняющий табельный номер. Класс Manager представляет сотрудников, которые являются руководителями для других работников.
Абстрактный класс Post представляет собой должность, которую может занимать сотрудник. Унаследованный класс ExperiencePost представляет должность, которая требует от претендента минимального количество опыта, выражаемого количеством месяцев работы
(атрибут MinExperMonth). Второй реализованный класс ScientificRank описывает должность от соискателя, на которую требуется наличие ученой степени, название которой записано в атрибуте AcademicRank.
Для представления отделов организации и вхождения в n-арную ассоциацию введен класс Department. Класс Salary представляет выплаченную заработную плату, начисленную работнику, занимающему должность, представленную сложной ассоциацией Position.
Класс Telephone позволяет представить номер телефона контрагента. Тип телефона (Домашний, Личный, Рабочий) представлен перечислением TelephoneKind. Для представления адреса используется базовый абстрактный класс Address. Два производных класса CompanyAddress и EmployeeAddress используются для представления адреса организации и адреса служащего соответственно.
Post Ä
Interface >
-fr IBaseRunTimeDc main Class
0 Properties
f* Name
V
Department
IBaseRunTimeDo nainClass
В Properties
> Name
0 Properties
f* MinExperMonth
Contragent *
-fr IBaseRunTimeDo maindass
В Properties
Л* Mame
Л Telephones
—;-^
Telephone
-HBaseRunTimeDor nainCiass
В Properties
/* Number
V
Position
Interface IBaseRunTimi
В Properties Р Rate
Worker
Interface ■fr Contr agent
0 Properties
f* DateOfBirth
Company Л
■fr Contragent
-frIB-aielïunTimeTreeNodeDomainClass
S Properties
У AcädemicRänk
Personal Work
Address
IBaseRunTimeDorr ainClass
В Properties
> Bidding
Л- City
f1 Country
У Office
ft Street
f> Compän у Address
■fr IBaseRunTimeDom-ainCiass
0 Properties M Date f> Vahe
Employee
■fr Worker
0 Properties
ЕЮ
У
CompanyAddress A
Interface
fr Employee
EmpIoyeeEmployeeAddress
■fr IBa:eRunîimeDomainClass
0 Properties
f* ¡sRegistered
Manager
Interface -fr Employee
A1 EmpbyeeEmpbyeeAddresses
EmployeeAddress
Interface ■* Address
f* EmpbyeeA ddress
Рис. 3 - Результирующая модель сущностного проектирования
Теперь проверим соответствие представленной модели выделенным ранее критериям оптимальности. Необходимость наличия глубокой иерархии классов, представленной как минимум тремя транзитивно унаследованными классами, описана КО1 и реализована классами Contragent, Worker, Employee, Manager. Кроме этой имеются еще две иерархии: 1) Post, ExperiencePost (ScientificPost); 2) Address, CompanyAddress (EmployeeAddress). Т.е. в модели присутствуют несколько иерархий наследования, следовательно, выполнено условие КО2. Наличие абстрактных классов в иерархии обусловлено КО3 и выполнено классами Post, Contragent и Address.
Требования КО4 также выполнены, т.к. имеется n-арная ассоциация Position, объединяющая классы Post, Department, Worker, Company. Т.к. описываемая ассоциация содержит атрибут Rate, реализованный классом-ассоциацией, и бинарная ассоциация, соединяющая классы Employee и EmployeeAddress также содержит атрибут (IsRegistered), то можно утверждать, что требование КО5 выполнено.
У каждого контрагента, описываемого производными от Contragent классами, имеется список номеров телефонов, представленных экземплярами класса Telephone, и оба класса связаны композицией, т.е. требование КО6 выполнено. Унифицированная модель позволяет сохранять информацию о группе компаний, т.е. организовать древовидную структуру с помощью рекурсивной ассоциации, соединяющей класс Company с собой. Наличие рекурсивной ассоциации продиктовано КО7.
В КО8 записано требование наличия ассоциаций между классами, входящими в одну иерархию наследования. На рис. 3 между классами Employee и Manager имеется подобная ассоциация, удовлетворяющая КО8.
Рис. 4 - Результирующая модель имплементационного объектно-ориентированного проектирования
88
Как отмечалось ранее, в модели имеется наличие класса-ассоциации Position, что соответствует КО9. Описанный класс-ассоциация соединен дополнительной ассоциацией с классом Salary. Это следствие выполнения КОю. Присутствие в модели перечислений обусловлено выполнением КОц. Из представленного описания видно, что унифицированная модель полностью соответствует всем выделенным ранее критериям оптимальности.
Одной из основных особенностей SharpArchitect RAD Studio является поддержка множественного наследования, реализуемого с помощью интерфейсов (interface) языка C#. Применяемый язык C# не поддерживает такой синтаксической конструкции, как ассоциация.
Для представления бинарных ассоциаций независимо от множественности используются свойства (property), содержащие одно значение или коллекцию значений.
Множественные n-арные ассоциации представляются отдельным классом, атрибуты этих ассоциаций (как и атрибуты бинарных ассоциаций) превращаются в свойства классов. Для упрощения поиска информации и извлечения все ассоциации являются двунаправленными, т.е. на обоих краях в соответствующих классах присутствуют свойства, тип которых соответствует классу противоположного конца ассоциации.
Как видно из рис. 3, при реализации использовались интерфейсы языка C#, поэтому невозможно курсивом выделить абстрактные классы. Двунаправленные ассоциации показаны соответствующими стрелками, соединяющими классы. При реализации ассоциаций использовался следующий подход. Со стороны «один» создавалось свойство (property), типом которого является список (C# тип IList()), содержащий элементы, типом которых является класс, расположенный со стороны «ко-многим». При этом со стороны «ко-многим» в классе объявляется свойство, типом которого является класс, расположенный со стороны «один». Ассоциация типа «многие-ко-многим» (без атрибутов) может быть представлена двумя списками, объявленными в противоположных классах. В среде разработки SharpArchitect RAD Studio имеется ряд базовых классов, в которых реализован наиболее общий функционал. Например, класс IBaseRunTimeDomainClass является корневым для всех классов предметной области. Для реализации древовидной структуры достаточно унаследоваться от IBaseRunTimeTreeNodeDomainClass. В момент кодогенерации автоматически будут генерироваться дополнительные атрибуты Nodes и Owner, позволяющие сохранять ссылки на вложенные и родительский узлы соответственно. Именно таким способом реализуются рекурсивные ассоциации. Для представления перечислений и множеств используется синтаксическая конструкция enum.
Post
S OID
Name
_ ObjectType
_ MinExperMonth
AcademicRank
Department
ою
I Name
Contragent
S OID
Name
ObjectType
Я OID
Rate
Post
Department
Company
Worker
J?| OID
J
Salary
OID
_I Date
_I Value
I Position
Manager
Ы OID
Telephone
OID
Telephone Kind
Contragent
Company
OID I Owner
I CompanyAddress
Employee
OID
EID
Manager
Company Address
|j?| OID
_I Country
_| City
_I Street
I Building
_I Office
_I Company
EmployeeEmployeeAddress
0|c h
_I Employee
I EmployeeAddress
EmployeeAddress
OID
_I Country
_| City
_J Street
I Building ._I Office
Рис. 5 - Результирующая модель имплементационного реляционного проектирования
Т.к. для реализации приложений БД в SharpArchitect RAD Studio использован объектно-ориентированный язык программирования C#, то для реализации интерфейсов
используются классы (синтаксическая конструкция class). На рис. 4 представлена результирующая модель имплементационного объектно-ориентированного проектирования.
Как видно из рис. 4, модель представляет собой диаграмму классов UML. Набор и структура этих классов генерируется автоматически на основании метамодели объектной системы.
Для хранения данных в БД реализована модель имплементационного реляционного проектирования, представленная на рис. 5. Для её формирования использованы классические методы (паттерны) объектно-реляционного отображения [1-2].
ЕГ
Company: DetailView
^acNewObject^acSave^acSaveAndClosej[acSaveAndNewj
^acDelete^acValidate)^acUndo)^ acRef resh) ^ acClose^
CCompany.Name> CCompany.Owner>
<Company.CompanyAddress>
CCompany.Positions>
<Position.Post> <Position.Departments <Position.Worker> <PositionRate>
<Company.Nodes>
CCompany.Name>
<Company.CompanyAddress>
<Company.Telephones>
<Telephone.Number>
<Telephone.TelephoneKind>
Рис. 6 - Результирующая модель презентационного проектирования
Из рис. 5 видно, что модель представляет собой диаграмму реляционных отношений, на которой представлены таблицы, столбцы и связи созданной БД. Сама структура РБД формируется автоматически с помощью сгенерированных SQL-запросов, созданных на основе результирующей модели, построенной на этапе метамодельного проектирования.
На рис. 6 имеется результирующая модель презентационного проектирования, описанная с помощью нотации, представленной в [9]. В верхней части формы представлен класс, экземпляры которого представляет форма и тип формы. В данном примере рассматривается форма редактирования одного объекта. Для ссылки на используемые элементы модели метамодельного проектирования используются угловые скобки "<...>". Для представления методов классов, преобразованных в графические элементы (в нашем случае в кнопку), в конце записи используются круглые скобки "()". Для действий, которые оперируют другими графическими элементами, используется префикс "ас", при этом в угловых скобках "<...>" указывается класс или свойство, на которые направлено действие.
Для физической реализации модели презентационного проектирования пользователю предоставлен механизм настройки графического интерфейса в момент выполнения приложения (runtime) без участия разработчика.
Выводы
В данной статье представлен созданный автором подход к разработке программного обеспечения, названный методологией метамодельно-ориентированного проектирования приложений баз данных. Были кратко описаны все основные этапы, суть которых заключается в выполнении различных видов проектирования и получения соответствующих моделей в различных графических моделях. Во второй части статьи представлен пример
выполнения описанных этапов и созданные модели для унифицированной модели тестирования инструментов разработки объектно-ориентированных приложений баз данных. Многолетний опыт применения описанной методологии позволил доказать её практическую значимость. При этом каждый этап является относительно независимым от остальных, что позволяет привлекать группу разработчиков и выполнять их параллельно.
Литература
1. Олейник П.П. Тестовая модель для обучения проектированию объектно-ориентированных баз данных // Объектные системы - 2014: материалы VIII Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2014. - С. 86-89.
2. Олейник П.П. Унифицированная модель тестирования инструментов разработки объектно-ориентированных приложений // Объектные системы - 2014 (Зимняя сессия): материалы IX Международной научно-практической конференции (Ростов-на-Дону, 10-12 декабря 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова,
2014. С. 23-32.
3. Олейник П.П. Иерархия классов метамодели объектной системы // Объектные системы -2012: материалы VI Международной научно-практической конференции (Ростов-на-Дону, 1012 мая 2012 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2012. -С. 37-40
4. Олейник П.П. Унифицированная метамодель объектной системы // Прикладная информатика.
2015. Том 10. №4 (58). - С. 70-81.
5. Олейник П.П. Формальное описание прикладных предметных областей в понятиях унифицированной метамодели объектно-ориентированных приложений баз данных // Объектные системы - 2015: материалы X Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2015 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2015, С. 108-114, http://objectsystems.ru/files/2015/0bject Systems 2015 Proceedings.pdf
6. Олейник П.П. Формальное представление моделей прикладных предметных областей в понятиях унифицированной метамодели объектно-ориентированных приложений баз данных / П.П. Олейник // Вестник ЮУрГУ. Серия «Компьютерные технологии, управление, радиоэлектроника». - 2015. - Т. 15, № 4. - С. 12-25. DOI: 10.14529/ctcr150402
7. Гурьянов В.И., Олейник П.П. UML-профиль проектирования структуры объектно-ориентированной базы данных // Объектные системы - 2015: материалы X Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2015 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2015, С. 73-79, http://objectsystems.ru/files/2015/0bject_Systems_2015_Proceedings.pdf
8. Олейник П.П., Гурьянов В.И. Реализация примесей в современных объектно-ориентированных средах разработки приложений баз данных // Научные коммуникации. Научная этика. Инженерная этика : сб. докл. Первой регион. науч. конф. (Россия, Омск, 30 сент. - 1 окт. 2015 г.) / ОмГТУ, ОНЦ СО РАН, ОФ ИМ СО РАН ; [гл. науч. ред. П. Г. Макухин]. - Омск : Изд-во ОмГТУ, 2015. C.90-94.
9. Николенко О.И., Олейник П.П. Прототипирование и реализация графической формы заказа для информационной системы ресторанов быстрого питания // Объектные системы - 2015: материалы X Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2015 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2015, С. 68-73, http://objectsystems.ru/files/2015/0bject_Systems_2015_Proceedings.pdf
10. Олейник П.П., программа для ЭВМ "Унифицированная среда быстрой разработки корпоративных информационных систем SharpArchitect RAD Studio", свидетельство о государственной регистрации № 2013618212 от 04 сентября 2013 г.
