CC BY
64
функции сгруппированы по категориям, к ним обычно прилагаются многочисленные структуры данных. Этот интерфейс очень далёк от объектной модели, часто бывает запутанным, нелогичным, избыточным, а также плохо документированным. Разработчики систем всегда оставляют недокументированные средства, благодаря которым могут достраивать систему или управлять её скрытыми настройками.
Своеобразным исключением можно считать безвременно забытую операционную систему BeOS, обладавшую API, реализованным на С++, и предлагавшей концепцию серверов для программных приложений. Идеи, заложенные в BeOS, надолго опередили своё время, и вот теперь их можно встретить в свободной реализации под названием Haiku [5].
Microsoft сделала ряд важных шагов в плане унификации API через прослойку .NET, которая фактически является системой классов и виртуальной машиной, преобразующей вызовы команд CLR в native-инструкции. Благодаря .NET удалось создать немало прикладных программ, имеющих объектный стиль взаимодействия с ресурсами системы. Несомненно, создание .NET было важным маркетинговым и техническим ходом компании, и его развитие было подготовлено предшествующей историей технологии COM.
Выводы
Подводя итоги, мы должны признать, что в операционных средах объектные технологии можно встретить чаще, чем в операционных системах, но и здесь нет общепринятого стандарта на их использование и развитие. Остаётся выразить надежду, что современные активные разработки пользовательских окружений будут учитывать положительный опыт прошлых проектов с использованием ООП, а разработчики системных API будут расширять объектные возможности своих ресурсов.
Литература
1. Штанюк А.А. Перспективы развития объектно-ориентированных операционных систем //
Объектные системы - 2013: Материалы VII Международной научно-практической
конференции (Ростов-на-Дону, 10-12 мая 2013) - ШИ(Ф) ЮГТУ, 2013, с. 35-39.
2. Коробко И. PowerShell как средство автоматического администрирования. М.: ДМК Пресс,
2014.
3. Гифт Н., Джонс Д. Python в системном администрировании Unix и Linux. М.: Символ-плюс,
2009.
4. CDE 2.1 Data Sheet [Электронный ресурс]. - Режим доступа
http://www.opengroup.org/desktop/cde/cde.data.sheet.htm (дата обращения 12.04.2014).
5. Haiku Book [Электронный ресурс]. - Режим доступа https://api.haiku-os.org/ (дата обращения
12.04.2014).
УДК 004.04
ПРЕДМЕТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ СТРУКТУРЫ БАЗЫ ДАННЫХ В ПОНЯТИЯХ МЕТАМОДЕЛИ ОБЪЕКТНОЙ СИСТЕМЫ
Олейник Павел Петрович, к.т.н., Системный архитектор программного обеспечения, ОАО «Астон»,
Россия, Ростов-на-Дону, xsl@list.ru
Введение
В настоящее время широкую популярность получило предметно-ориентированное проектирование, предполагающее создание модели предметной области, основу которой составляет диаграмма классов, представленная в нотации UML [1-2]. Предполагается, что при реализации информационной системы впоследствии применяется объектноориентированный язык программирования, а для хранения информации в долговременной памяти - используется СУБД. При проектировании структуры БД можно выделить три основных этапа: концептуальное, логическое и физическое проектирование [3]. Последний
41
этап напрямую зависит от типа выбранной СУБД, поэтому при реализации приложения в инструментальной среде разработки, охватывающий полный жизненный цикл, возникают сложности при построении физической модели. В статье рассматривается только статическая структура, представляющая, по сути, диаграмму классов.
1. Структура метамодели объектной системы
Процесс проектирования рассматривается на основе метамодели, первоначально опубликованной в работе [4]. Текущая версия метамодели объектной системы представлена на рисунке 1 и имеет следующие ключевые отличия от версии, описанной в [4]:
1. Добавлены классы, представляющие атрибуты различных типов данных такие как геометрические объекты (точки, линии, замкнутые фигуры), географические координаты и атрибуты, позволяющие представлять экземпляры классов.
2. Добавлены вычисляемые классы в систему, экземпляры которых не сохраняются в базе
данных и используемые для реализации алгоритмов и бизнес-процессов прикладной предметной области.
3. Спроектирована и реализована иерархия классов, представляющая значения по умолчанию для атрибутов классов. При этом имеется возможность наследования значений и переопределения значений в производных классах (полиморфизм).
4. Добавлены различные опции (в виде множества) для классов, позволяющие управлять
поведением экземпляров. Например, имеется возможность указать, что класс реализует шаблон проектирования Singleton и тем самым позволяет запретить возможность создания более одного экземпляра и возможность удаления.
2. Основные этапы проектирования структуры базы данных
Перейдем к процессу предметно-ориентированного проектирования с позиций разработки структуры БД. Выделяют три основных этапа проектирования: концептуальное, логическое и физическое [3]. Концептуальное проектирование базы данных позволяет описать высокоуровневую модель и начинается с создания концептуальной модели данных предприятия, полностью независимой от любых деталей реализации. К последним относятся выбранный тип СУБД, состав программ приложения, используемый язык программирования, конкретная аппаратная платформа, вопросы производительности и любые другие физические особенности реализации. Для целей данной статьи рассмотрим простую предметную область, концептуальная и логические модели которой представлены на рисунке 2.
Следующим этапом является логическое проектирование БД, под которым понимается конструирование информационной модели предприятия на основе существующих конкретных моделей данных, но без учёта специфики используемой СУБД и прочих условий реализации [3].
В общем случае логическое проектирование базы данных заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (в нашем случае, в понятия объектной СУБД). Логическая модель данных является источником информации для этапа физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет важное значение для выбора эффективного проектного решения.
При разработке логической структуры (модели) БД используется объектноориентированная модель данных (ООМД), поэтому необходимо удалить элементы, присутствующие на концептуальной модели, которые не поддерживаются в ООМД и добавить те элементы, которыми отличается ООМД. В нашем случае необходимо выполнить:
1. Обобщение/специализацию.
2. Преобразовать связи с атрибутами в отдельные классы.
42
3. Преобразование сложных связей в отдельные классы.
4. Проектирование правил поведения.
43
Рассмотрим каждый пункт более подробно. Некоторые объекты могут иметь подобные, но не идентичные атрибуты и методы. Если степень такого подобия высока, то имеет смысл совместно использовать эти свойства (атрибуты и методы). Наследование позволяет определять один класс на основе общего класса-предка. Такие менее общие классы называются подклассами (производными, унаследованными классами), а более общие — суперклассами (родительскими классами). Процесс образования суперкласса называется обобщением (генерализация), а процесс образования подкласса — специализацией. По умолчанию подкласс наследует все свойства суперкласса и в дополнение к ним может определить свои собственные уникальные. В подклассе могут быть переопределены унаследованные свойства. Все экземпляры подкласса являются также экземплярами суперкласса и, согласно принципу подстановки, для любого метода и конструкции вместо экземпляра суперкласса всегда можно использовать экземпляр его подкласса. Отметим, что расширенная модель «сущность-связь» поддерживает механизм уточнения/обобщения (предполагающий использование дискриминанта), но данная конструкция более ограничена по сравнению с концепцией наследования, применяемой в объектно-ориентированном программировании.
Проанализировав рис. 2, можно утверждать, что два выделенных класса (Client и Product) полностью идентичны, так как характеризуются одинаковыми атрибутами (в данном случае названием). Поэтому имеет смысл выделить общий базовый класс (выполнить процедуру обобщения), содержащий название (например, класс NamedObject), а классы Client и Product сделать производными от NamedObject.
Рис. 2 - Концептуальная (слева) и логическая (справа) модели
В сложных связях участвуют три и более сущностей. Такие связи не поддерживаются непосредственно и требуют введения промежуточного класса, который соединяется с остальными бинарными связями (как правило, с типом «один ко многим»). Из концептуальной модели видно, что в предметной области отсутствуют сложные связи, поэтому описанные преобразования выполнять не нужно. Результат описанных действий представлен на рис. 2.
Последним этапом является физическое проектирование базы данных, под которым понимается описание конкретной реализации базы данных, размещаемой во внешней памяти. Физический проект описывает базовые отношения, определяет организацию файлов и состав индексов, применяемых для обеспечения эффективного доступа к данным, а также регламентирует все соответствующие ограничения целостности и меры защиты. Физическое проектирование базы данных предусматривает принятие разработчиком окончательного решения о способах реализации создаваемой базы. Поэтому физическое проектирование обязательно производится с учетом всех особенностей целевой СУБД.
3. Физическая модель структуры БД в понятиях метамодели объектной системы
В нашем случае используется собственная среда разработки, поэтому физическая модель представляется в понятиях экземпляров классов метамодели, изображенной на рис. 1.
44
Т.е. необходимо построить диаграмму объектов языка UML [2]. Один из возможных вариантов представлен на рис. 3.
Рассмотрим представленный рисунок более подробно. Из рисунка видно, что представлена диаграмма объектов языка UML [2], содержащая некоторую дополнительную информацию, необходимую для понимания. Для представления классов предметной области используются объекты типа DomainClass. Для организации ассоциаций используются объекты трех классов. Объекты типа Association позволяют описать ассоциации между классами. В настоящий момент используются только бинарные ассоциации (сложные ассоциации могут быть представлены в виде набора бинарных ассоциаций) поэтому необходим механизм описания обоих краев ассоциации. Для этого используются экземпляры классов AssociationEnd. Для каждого края ассоциации генерируется атрибут типа DomainClassAttribute.
В зависимости от типа (домена) атрибута класса используется соответствующий экземпляр класса метамодели объектной системы. Так, для атрибута Dates, позволяющего сохранять дату и время продажи, использован экземпляр класса DateTimeAttribute. Из рисунка видно, что подобным образом может быть представлена модель любой предметной области.
Рис. 3 - Физическая модель структуры БД в понятиях метамодели объектной системы
Выводы
В данной статье подробно рассмотрен процесс предметно-ориентированного проектирования структуры БД тестовой предметной области. Предполагается, что физическая модель структуры базы данных изображается в виде диаграммы объектов языка UML. Классы отображаемых экземпляров представляются классами метамодели объектной
45
системы. В будущем предполагается реализовать механизм автоматического построения физической модели по имеющимся экземплярам классов. Кроме того, необходимы механизмы представления поведения системы, т.е. ее динамической составляющей.
Литература
1. Эрик Эванс. Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем : Пер. с англ. - М.: Издательский дом "Вильямс", 2010. - 448 с. : ил. -Парал. тит. англ.
2. Новиков Ф.А., Иванов Д.Ю. Моделирование на UML. Теория, практика, видеокурс. - СПб.: Профессиональная литература, Наука и Техника, 2010. - 640 с.: ил. + цв. Вклейки (+ 2 DVD).
3. Коннолли, Томас, Бегг, Каролин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. - М.: Издательский дом "Вильямс", 2003. - 1440 с. : ил. - Парал. тит. англ.
4. Олейник П.П. Иерархия классов метамодели объектной системы // Объектные системы -2012: материалы VI Международной научно-практической конференции (Ростов-на-Дону, 1012 мая 2012 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2012. -С. 37-40
УДК 681.3
ВИЗУАЛИЗАЦИЯ ОНТОЛОГИЧЕСКИХ МОДЕЛЕЙ И СТАТИЧЕСКИХ
ДАННЫХ
Мухутдинов Руслан Маисович, студент, ГОУ ВПО «Уральский федеральный университет имени первого Президента России Б.Н.Ельцина», Нижнетагильский технологический институт (фил.), Факультет экономики и менеджмента, кафедра информационных технологий, Россия. Нижний Тагил,
spider9323@gmail.com
Шишкина Вероника Валерьевна, студент, ГОУ ВПО «Уральский федеральный университет имени первого Президента России Б.Н.Ельцина», Нижнетагильский технологический институт (фил.), Факультет экономики и менеджмента, кафедра информационных технологий, Россия. Нижний Тагил Грегер Сергей Эдуардович, доцент, ГОУ ВПО «Уральский федеральный университет имени первого Президента России Б.Н.Ельцина», Нижнетагильский технологический институт (фил.), Факультет экономики и менеджмента, кафедра информационных технологий, Россия. Нижний Тагил,
segreger@gmail.com
Предоставление провайдерами возможностей беспроводного доступа к сети Интернет, расширение каналов связи играет важную роль в развитии современных информационных технологий. Потребители любого вида информационных услуг хотят получать доступ к необходимым сервисам в любое время и в любом месте. В связи с этим, важным этапом в развитии информационных технологий любой сложности и уровня (будь то база данных клиентов банка или графический редактор для художника) является их переход на вебинтерфейс, развитие распределённых систем, облачных инфраструктур.
С быстрым ростом численности населения, с вовлечением новых поколений в различные сферы деятельности, требующие постоянно растущего уровня знаний, умений и навыков, появились онтологические модели. Теперь информация и знания стали структурированы и описаны таким образом, чтобы получатель (клиент) был способен понять и текст, и контекст сообщения.
Автор рассмотрел проблему визуализации онтологических моделей и статистических данных посредством современных веб-технологий. Накопление и анализ данных, представление наглядных графиков — достаточно распространённая задача. Составление прогноза погоды, отображение статистики посещаемости веб-ресурсов, анализ данных любого технического производства (например, на предмет установления частоты появления бракованных изделий) — примеры областей и задач для которых необходимо отображать наглядные графики.
46
