У желания сто возможностей, у нежелания — сто причин.
Гриневич Ирина Евгеньевна
Факультет компьютерных наук и технологий
Кафедра компьютерной инженерии
Специальность Системное программирование
Научный руководитель: к.т.н., доцент Зеленёва Ирина Яковлевна
Введение
В настоящее время повсеместно используются автоматизированные системы управления. Не является исключением и государственное предприятие Укрзалiзниця
, которое для реализации сложных технологических процессов использует собственное специализированное программное обеспечение, позволяющее оптимизировать работу с учетом современных реалий. Это программное обеспечение состоит из множества частей, немаловажную роль в которых играет обеспечение автоматизированных рабочих мест (АРМ) и серверов приложений всеми необходимыми данными, для чего и предназначена система ведения отраженных моделей. Для уменьшения выполняемой операторами вручную рутинной работы требуется увеличение количества АРМ-ов, ввиду этого возникает потребность в разработке специализированной системы [1].
Актуальность
Государственное предприятие Укрзалiзниця
имеет в своем распоряжении сложную базу данных автоматизированной системы управления грузовыми перевозками (АСУГП), которая работает под управлением СУБД Oracle. Данные по работе железнодорожных объектов записываются в определенные модели конкретного типа объекта.
Однако, при хранении данных появляется проблема, суть которой состоит в преобразовании объектных объектов в форму, в которой они могут быть сохранены в файлах или базах данных, и которые легко могут быть извлечены в последующем, с сохранением свойств объектов и отношений между ними. Решением проблемы является написание объектно-реляционной системы, сочетающей в себе свойства как объектной. так и реляционной систем управления базами данных.
Построение информационной системы для мониторинга простой предметной области (однородные объекты наблюдения, небольшое фиксированное количество независимых параметров) не составляет особого труда — для этого достаточно использовать какую-либо стандартную СУБД. Дело осложняется, если требуется фиксировать результаты наблюдений над большим количеством объектов разного типа, которые проводятся множеством независимых пользователей, и сохранять данные для последующего анализа [2].
Объектно-реляционное отображение
Объектная модель хорошо себя зарекомендовала при разработке больших систем (например, при создании ERP-систем, интернет-магазинов). Однако, при создании сложных систем программисту приходится одновременно жить в двух разных мирах
- объектном и в мире SQL
. Это неизбежно приводит к увеличению сложности, разрабатываемой системы. Поэтому стремиться к целостному подходу является естественным и обоснованным. В новом подходе предлагается забыть об SQL и мыслить объектно, но в то же время использовать достижения разработчиков реляционных баз данных, путем осуществления отображения объектов и таблиц [3].
Система ведения отраженных моделей (СВОМ) представляет собой специализированное ПО для объектно-реляционного отображения баз данных.
Объектно-реляционное отображение (англ. Object-relational mappiпg - ORM) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая виртуальную объектную базу данных
. Существуют как коммерческие, так и свободные реализации этой технологии [4].
В объектно-реляционных базах данных информация организуется в виде знакомых реляционных табличных структур. Объектно-реляционные (ОР) реализации предполагают поддержку реляционной модели данных. ОР СУБД являются постепенным развитием предшествующих им реляционных СУБД. В отличие от чисто объектных баз данных, переход к объектно-реляционным системам не требует массового перепрограммирования [5].
Цели и задачи, планируемые результаты
Целью магистреской работы является разработка ORM-системы, позволяющей хранить данные о подвижных единицах и их составных частях в специальных моделях. Для хранения данных предполагается наличие различных контейнеров моделей.
Назначение контейнера моделей — объектное представление моделей АСУГП (или любых других моделей СВОМ), которое реализует функциональность размещения данных в оперативной памяти, обмена данными с внешним программным кодом, сохранение данных на жесткий диск и восстановление с жесткого диска.
Контейнер моделей позволяет сохранять в себе любое количество оперативных моделей, поэтому на этапе выполнения он взаимодействует с компонентами, которые реализуют представление моделей в оперативной памяти (библиотечными модельными классами-наследниками для конкретных моделей АСУГП).
Контейнер моделей разрабатывается как плагин, который подключается к комплексу управления вызовами, потоками и компонентами. Внутри себя контейнер моделей содержит коллекцию моделей СВОМ, с помощью которой он реализует практически всю технологическую функциональность. Можно сказать, что контейнер моделей — обертка для коллекции моделей, которая превращает последнюю из просто класса в модуль, который подключается к комплексу управления вызовами, процессами и компонентами.
Поскольку контейнер моделей хранится в оперативной памяти, возможно ускорение работы с содержащимися в нем данными. Однако для большого количества данных необходимы серверы с большим объемом оперативной памяти.
Должны использоваться объектно-ориентированные принципы, что позволяет уменьшить объёмы программного кода и формировать определенные базовые структуры и функции объектов.
Контейнер моделей должен реализовывать такие функции, как создание и наполнение коллекции типовых моделей, обеспечение сохранения и загрузки данных типовых моделей из файлов, обеспечение обновления коллекции моделей.
Обзор аналогов
Среди наиболее известных ORM-аналогов можно выделить ADO.NET Entity Framework, NHibernate и DataObjects.NET.
ADO.NET Entity Framework
ADO.NET Entity Framework позволяет разработчикам создавать приложения, работающие с концептуальной моделью данных, а не напрямую с реляционной схемой их хранения. Цель состоит в уменьшении объема кода и снижении затрат на сопровождение приложений, ориентированных на обработку данных [6]. Приложения Entity Framework предоставляют следующие преимущества:
- приложения могут работать с концептуальной моделью в терминах предметной области — в том числе с наследуемыми типами, сложными элементами и связями;
- приложения освобождаются от жестких зависимостей от конкретного ядра системы управления базами данных или схемы хранения;
- сопоставления между концептуальной моделью и схемой, специфичной для конкретного хранилища, могут меняться без изменения кода приложения;
- разработчики имеют возможность работать с согласованной моделью объектов приложения, которая может быть сопоставлена со схемами хранения, которые, возможно, реализованы в различных системах управления данными;
- несколько концептуальных моделей могут быть сопоставлены с единой схемой хранения.
NHibernate
NHibernate — ORM-решение для платформы Microsoft .NET, портированное с Java. Это бесплатная библиотека с открытым кодом, которая распространяется под лицензией GNU Lesser General Public License.
NHibernate позволяет отображать объекты бизнес-логики на реляционную базу данных. По заданному XML-описанию сущностей и связей NHibernate автоматически создает SQL-запросы для загрузки и сохранения объектов [7].
DataObjects.NET
DataObjects.NET — это библиотека, обеспечивающая хранение обычных .NET-объектов в реляционной базе данных.
Использование библиотеки позволяет существенно сократить время разработки приложений, работающих с базами данных — DataObjects.Net берет на себя практически все функции, связанные с взаимодействием с сервером, выполняя их прозрачно (т.е. не требуя написания кода, который обеспечивает их выполнение) для разработчика. Она автоматически обновляет схему БД, поддерживает все типы отношений, запросы, полнотекстовый поиск, многоязычность, версии, управление правами доступа к объектам, .NET Remoting и многое другое.
Использование DataObjects.NET делает все данные автоматически совместимыми с Microsoft SQL Server, MDSE 2000, Microsoft Access, Oracle, Firebird, MaxDB без дополнительного кода [8].
Базовая структура модели, используемая на предприятии
Для четкого контроля последовательности ввода данных в автоматизированной системе управления используется событийная модель. Каждая модель имеет типизированную структуру (рис. 1).
Элементы моделей СВОМ для связи между собой используют ссылки, что позволяет выполнять быстрый переход от одного элемента к другому.
Рисунок 1 — Базовая структура модели в комплексе АСУГП
Структура системы ведения отраженных моделей
Одной из функций комплекса АСУГП является обеспечение данными АРМ-ов. При этом, если каждый АРМ будет запрашивать информацию непосредственно из базы данных, это увеличит нагрузку на сеть и на саму базу данных. В случае расширения функциональных возможностей и работы с моделями, процесс получения статистических данных может привести к перегруженности АСУГП, а следовательно, к увеличению длительности отклика (латентности) комплекса. Следовательно, основными целями СВОМ являются разгрузка комплекса АСУГП, уменьшение сетевого потока данных и обеспечение работы АРМ-ов.
Для того, чтобы разгрузить автоматизированную систему управления должны быть разработаны специальные сервера приложений, которые получают информацию, осуществляют её отображение и обслуживание АРМ-ов (рис. 2). Сервера приложений СВОМ должны позволять выполнение масштабирования, т.е. один сервер приложений может получать данные от другого, тем самым уменьшая нагрузку на базу данных АСУГП.
Рисунок 2 — Обобщенная структура системы ведения отраженных моделей (Анимация: 7 кадров, задержка между кадрами 2 с, количество циклов воспроизведения не ограничено, размер 405*227, 116 кБ)
Структура типизированных моделей в комплексе АСУГП полностью генерируется специализированными средствами. Система ведения отраженных моделей должна в основном копировать эту структуру, при этом некоторые неиспользуемые поля или таблицы могут отсутствовать для уменьшения объемов используемой памяти на серверах приложений и АРМ-ах.
Процесс генерации
В процессе генерации происходит получение XML-описания, на основе которого генерируется код моделей СВОМ. Полученное описание может быть урезано или дополнено моделями, которые отсутствуют в базе данных. После выполнения процесса генерации из программного кода собираются библиотеки, которые могут быть использованы разработчиками прикладного кода.
В сервера приложений данные поступают при выполнении запросов, которые также были сгенерированы. Полученная информация формирует контейнеры данных, которые хранятся в оперативной памяти.
Процесс сериализации и десериализации
В настоящее время скорость передачи данных между АРМ-ами критически мала или может периодически обрываться. Поэтому к передаче данных предъявляются особые требования:
- объем передаваемых данных должен быть предельно малым;
- при записи/восстановлении данных должен использоваться минимальный объем памяти;
- скорость передачи данных должна регулироваться (например, между участками с малой пропускной способностью необходимо уменьшать скорость, чтобы избежать потерь данных).
В среде .NET большинство стандартных объектов можно преобразовывать в массив байт. Процесс преобразования принято называть сериализацией. Обратный ему процесс называется десериализацией. Однако при стандартной сериализации в большинстве случаев записывается лишняя (служебная) информация, что может значительно увеличить размер передаваемых данных. Для уменьшения этих данных предусмотрена поддержка процессов пользовательской сериализации/десериализации. Кроме того, предусмотрена возможность сжатия архиватором. Поскольку в большинстве случаев нет необходимости передавать на АРМ все поля данных, информация передается с помощью специальных схем, которые определяют состав передаваемых данных.
При разработке системы также необходимо учитывать особые требования, которые предъявляются к процессу десериализации. Поскольку большая часть выделяемой приложению оперативной памяти используется для хранения объектов СВОМ, нежелательным является превышение её объёма, в случае чего приложение завершит свою работу с ошибкой. Для решения этой проблемы в проекте используется процесс последовательного фрагментарного получения данных из потока. Итерационное выполнение этого процесса позволяет существенно сократить объем выделяемой оперативной памяти.
Взаимодействие с автоматикой
Автоматическое определение параметров операций прибытия, отправления, проследования поездов является затратным не только в аппаратном плане, но и в плане времени.
На сегодняшний день существуют различные виды автоматизированных систем. Условно их можно разделить на два вида: линейные и информационные. Линейные системы дают представление о прохождении подвижной единицей контрольного участка в определенный момент времени, информационные же системы дают информацию о конкретно взятой подвижной единице, которая должна преодолеть контрольный участок в некоторый (приблизительный) момент времени [9].
Для получения наиболее достоверной картины необходима реализация взаимодействия двух таких систем: получение точного времени прохождения и идентификация подвижной единицы.
Разработка интерфейса взаимодействия обеспечит унификацию взаимодействия микропроцессорных систем (МПЦ) диспетчерского управления, диспетчерской централизации (ДЦ) и диспетчерского контроля (ДК), с автоматизированной системой управления грузовыми перевозками (АСУГП) и, как следствие, существенно уменьшит затраты при подключении систем МПЦ различных разработчиков [10].
Структура взаимодействия
Предлагаемая структура взаимодействия АРМ и систем МПЦ показана на рис. 3:
Рисунок 3 — Предлагаемая структура взаимодействия АРМ и систем МПЦ
Информация, предоставленная системами МПЦ, передается серверной стороной клиентской стороне в виде информационных сообщений. На основе информации из сообщений формируются объекты (модели), которые будут записаны в СВОМ.
Каждые два часа серверный вариант контейнера моделей СВОМ обновляется путем внесения изменений из локальных контейнеров моделей.
Выводы
Предполагается, что разрабатываемая специализированная система ведения отраженных моделей будет максимально соответствовать всем предъявленным требованиям, и при этом позволит получать все необходимые данные. В настоящий момент проект находится в стадии доработки и корреляции с предыдущими разработками с целью сохранения данных.