Система ведения отраженных моделей
Источник: Информатика и компьютерные технологии (ИКТ-2011) /
Электронный сборник трудов VII международной научно-технической конференции студентов,
аспирантов и молодых ученых. — Донецк, ДонНТУ — 2011, с. 22-26
Авторы: Гриневич И.Е., Жевжик С.Е., Зеленёва И.Я.
В статье рассмотрена задача разработки специализированной ORM-системы, позволяющей работать с данными в терминах предметной области. Приведены некоторые существующие аналоги разработанной системы. Рассмотрена базовая структура типизированной модели, используемой на предприятии для записи данных. Предложены методы реализации процессов пользовательской сериализации и десериализации с учетом особых требований, предъявленных к процессам передачи данных.
Введение
В настоящее время повсеместно используются автоматизированные системы управления. Не является исключением и государственное предприятие «Укрзалiзниця», которое для реализации сложных технологических процессов использует собственное специализированное программное обеспечение, позволяющее оптимизировать работу с учетом современных реалий. Это программное обеспечение состоит из множества частей, немаловажную роль в которых играет обеспечение автоматизированных рабочих мест (АРМ) и серверов приложений всеми необходимыми данными, для чего и предназначена система ведения отраженных моделей, рассмотренная в данной работе. Для уменьшения выполняемой операторами вручную рутинной работы требуется увеличение количества АРМ-ов, ввиду этого возникает потребность в разработке специализированной системы.
Система ведения отраженных моделей (СВОМ) представляет собой специализированное ПО для объектно-реляционного отображения баз данных.
Объектно-реляционное отображение (англ Object-relational mappiпg - ORM) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». Существуют как коммерческие, так и свободные реализации этой технологии [1].
Существующие аналоги
ADO.NET Entity Framework позволяет разработчикам создавать приложения, работающие с концептуальной моделью данных, а не напрямую с реляционной схемой их хранения. Цель состоит в уменьшении объема кода и снижении затрат на сопровождение приложений, ориентированных на обработку данных [2]. Приложения Entity Framework предоставляют следующие преимущества.
- приложения могут работать с концептуальной моделью в терминах предметной области — в том числе с наследуемыми типами, сложными элементами и связями;
- приложения освобождаются от жестких зависимостей от конкретного ядра системы управления базами данных или схемы хранения;
- сопоставления между концептуальной моделью и схемой, специфичной для конкретного хранилища, могут меняться без изменения кода приложения;
- разработчики имеют возможность работать с согласованной моделью объектов приложения, которая может быть сопоставлена со схемами хранения, которые, возможно, реализованы в различных системах управления данными;
- несколько концептуальных моделей могут быть сопоставлены с единой схемой хранения.
NHibernate — ORM-решение для платформы Microsoft .NET, портированное с Java. Это бесплатная библиотека с открытым кодом, которая распространяется под лицензией GNU Lesser General Public Licence. NHibernate позволяет отображать объекты бизнес-логики на реляционную базу данных. По заданному XML-описанию сущностей и связей NHibernate автоматически создает SQL-запросы для загрузки и сохранения объектов [3].
DataObjects.NET — это библиотека, обеспечивающая хранение обычных .NET-объектов в реляционной базе данных. Использование библиотеки позволяет существенно сократить время разработки приложений, работающих с базами данных — DataObjects.Net берет на себя практически все функции, связанные с взаимодействием с сервером, выполняя их прозрачно (т.е. не требуя написания кода, который обеспечивает их выполнение) для разработчика. Она автоматически обновляет схему БД, поддерживает все типы отношений, запросы, полнотекстовый поиск, многоязычность, версии, управление правами доступа к объектам, .NET Remoting и многое другое.
Использование DataObjects.NET делает все данные автоматически совместимыми с Microsoft SQL Server, MDSE 2000, Microsoft Access, Oracle, Firebird, MaxDB без дополнительного кода [4].
Базовая структура модели, используемая на
предприятии
Государственное предприятие «Укрзалiзниця» имеет в своем распоряжении сложную базу данных автоматизированной системы управления грузовыми перевозками (АСУГП), которая работает под управлением СУБД Oracle. Данные по работе железнодорожных объектов записываются в определенные модели конкретного типа объекта. При этом для четкого контроля последовательности ввода данных в автоматизированной системе управления используется событийная модель. Каждая модель имеет типизированную структуру (рис. 1).
Элементы моделей СВОМ для связи между собой используют ссылки, что позволяет выполнять быстрый переход от одного элемента к другому.
Рисунок 1 – Базовая структура модели в комплексе АСУГП
Контейнер моделей
Назначение контейнера моделей – объектное представление моделей АСУГП (или любых других моделей СВОМ), которое реализует функциональность размещения данных в оперативной памяти, обмена данными с внешним программным кодом, сохранение данных на жесткий диск и восстановление с жесткого диска.
Контейнер моделей позволяет сохранять в себе любое количество оперативных моделей, поэтому на этапе выполнения он взаимодействует с компонентами, которые реализуют представление моделей в оперативной памяти (библиотечными модельными классами-наследниками для конкретных моделей АСУГП).
Контейнер моделей разрабатывается как плагин, который подключается к комплексу управления вызовами, потоками и компонентами.
Внутри себя контейнер моделей содержит коллекцию моделей СВОМ. С её помощью он реализует практически всю технологическую функциональность. Можно сказать, что контейнер моделей – обертка для коллекции моделей, которая превращает последнюю из просто класса в модуль, который подключается к комплексу управления вызовами, процессами и компонентами.
Т.к. контейнер моделей хранится в оперативной памяти, возможно ускорение работы с содержащимися в нем данными. Однако для большого количества данных необходимы серверы с большим объемом оперативной памяти.
Должны использоваться объектно-ориентированные принципы, что позволяет уменьшить объёмы программного кода и формировать определенные базовые структуры и функции объектов.
Контейнер моделей должен реализовывать такие функции, как:
- создание и наполнение коллекции типовых моделей;
- обеспечение сохранения и загрузки данных типовых моделей из файлов;
- обеспечение обновления коллекции моделей.
Структура системы ведения отраженных
моделей
Одной из функций комплекса АСУГП является обеспечение данными АРМ-ов. При этом, если каждый АРМ будет запрашивать информацию непосредственно из базы данных, это увеличит нагрузку на сеть и на саму базу данных. В случае расширения функциональных возможностей и работы с моделями, процесс получения статистических данных может привести к перегруженности АСУГП, а следовательно, к увеличению длительности отклика (латентности) комплекса. Следовательно, основными целями СВОМ являются разгрузка комплекса АСУГП, уменьшение сетевого потока данных и обеспечение работы АРМ-ов.
Для того, чтобы разгрузить автоматизированную систему управления должны быть разработаны специальные сервера приложений, которые получают информацию, осуществляют её отображение и обслуживание АРМ-ов (рис. 2). Сервера приложений СВОМ должны позволять выполнение масштабирования, т.е. один сервер приложений может получать данные от другого, тем самым уменьшая нагрузку на базу данных АСУГП.
Рисунок 2 – Обобщенная структура системы ведения отраженных моделей
Структура типизированных моделей в комплексе АСУГП полностью генерируется специализированными средствами. Система ведения отраженных моделей должна в основном копировать эту структуру, при этом некоторые неиспользуемые поля или таблицы могут отсутствовать для уменьшения объемов используемой памяти на серверах приложений и АРМ-ах.
Процесс генерации
В процессе генерации происходит получение XML-описания, на основе которого генерируется код моделей СВОМ. Полученное описание может быть урезано или дополнено моделями, которые отсутствуют в базе данных. После выполнения процесса генерации из программного кода собираются библиотеки, которые могут быть использованы разработчиками прикладного кода.
В сервера приложений данные поступают при выполнении запросов, которые также были сгенерированы. Полученная информация формирует контейнеры данных, которые хранятся в оперативной памяти.
Процесс сериализации и десериализации
Объектом разработки авторов является программа, обеспечивающая выполнение процессов сериализации и десериализации.
В настоящее время скорость передачи данных между АРМ-ами критически мала или может периодически обрываться. Поэтому к передаче данных предъявляются особые требования:
- объем передаваемых данных должен быть предельно малым;
- при записи/восстановлении данных должен использоваться минимальный объем памяти;
- скорость передачи данных должна регулироваться (например, между участками с малой пропускной способностью необходимо уменьшать скорость, чтобы избежать потерь данных).
В среде .NET большинство стандартных объектов можно преобразовывать в массив байт. Процесс преобразования принято называть сериализацией. Обратный ему процесс называется десериализацией. Однако при стандартной сериализации в большинстве случаев записывается лишняя (служебная) информация, что может значительно увеличить размер передаваемых данных. Для уменьшения этих данных был разработан программный проект с поддержкой процессов пользовательской сериализации/десериализации. Кроме того, была реализована возможность сжатия архиватором. Т. к. в большинстве случаев нет необходимости передавать на АРМ все поля данных, информация передается с помощью специальных схем, которые определяют состав передаваемых данных.
Разработанный проект также учитывает особые требования, которые предъявляются к процессу десериализации. Поскольку большая часть выделяемой приложению оперативной памяти используется для хранения объектов СВОМ, нежелательным является превышение её объёма, в случае чего приложение завершит свою работу с ошибкой. Для решения этой проблемы в проекте используется процесс последовательного получения данных из потока. Итерационное выполнение этого процесса позволяет существенно сократить объем выделяемой оперативной памяти.
Выводы
Разработанная специализированная система ведения отраженных моделей максимально соответствует всем предъяваленным требованиям, и при этом позволяет получать все необходимые данные. В настоящий момент проект находится в стадии корреляции с предыдущими разработками с целью сохранения данных.
Литература
[1] Object-relational mapping. Материал из Википедии – свободной
энциклопедии. Электронный ресурс. Режим доступа:
http://ru.wikipedia.org/wiki/ORM
[2] ADO.NET Entity Framework. Электронный ресурс. Режим доступа:
http://msdn.microsoft.com/ru-ru/library/bb399572.aspx
[3] NHibernate. Материал из Википедии – свободной энциклопедии. Электронный ресурс. Режим доступа: http://ru.wikipedia.org/wiki/NHibernate
[4] DataObjects.Net. Электронный ресурс. Режим доступа:
http://mescontrol.ru/features/do.html