Думати ні про що легше, ніж ні про що не думати. (Леонид С. Сухоруков)
Гриневич Iрина Євгенівна
Факультет комп'ютерних наук і технологій
Кафедра комп'ютерної інженерії
Спеціальність Системне програмування
Науковий керівник: к.т.н., доцент Зеленьова Ірина Яківна
Вступ
У наш час розповсюджене використання автоматизованих системи керування. Не є вийнятком і державне підприємство Укрзалізниця
, яке задля реалізації складних технологічних процесів використовує власне спеціалізоване програмне забезпечення, що дозволяє оптимізувати роботу з урахуванням сучасних реалій. Це програмне забезпечення складається з великої кількості частин, важливу роль в яких грає забезпечення автоматизованих робочих місць (АРМ) і серверів додатків усіма необхідними даними, для чого і призначена система ведення відображених моделей. Для зменшення виконуваної операторами вручну рутинної роботи потрібне збільшення кількості АРМ-ів, з огляду на це виникає потреба в розробці спеціалізованої системи [1].
Актуальнiсть
Державне підприємство Укрзалізниця
має в своєму розпорядженні складну базу даних автоматизованої системи керування вантажними перевезеннями (АСКВП), яка працює під управлінням СУБД Oracle. При роботі за автоматизованими робочими місцями дані про використання залізничних об'єктів та їх стан записуються в певні представлення об'єктів. Однак, при зберіганні даних з'являється проблема, суть якої полягає в перетворенні об'єктів у форму, в якій вони можуть бути збережені в файл або базу даних, і які легко можуть бути вилучені в подальшому, із збереженням властивостей об'єктів і відносин між ними. Рішенням проблеми є написання об'єктно-реляційної системи, що поєднує в собі властивості як об'єктної, так і реляційної систем управління базами даних.
Побудова інформаційної системи для моніторингу звичайної предметної області (однорідні об'єкти спостереження, невелика фіксована кількість незалежних параметрів) не складає особливих труднощів — для цього досить використовувати будь-яку стандартну СУБД. Справа ускладнюється, якщо потрібно фіксувати результати спостережень над великою кількістю об'єктів різного типу, які проводяться безліччю незалежних користувачів, і зберігати дані для наступного аналізу [2].
Об'єктно-реляційне відображення
Об'єктна модель добре себе зарекомендувала при розробці великих систем (наприклад, при створенні ERP-систем, інтернет-магазинів). Однак, при створенні складних систем програмісту доводиться одночасно жити в двох різних світах
- об'єктному і в світі SQL
. Це неминуче призводить до збільшення складності, розроблюваної системи. Тому прагнення до цілісного підходу є природним і обгрунтованим. У новому підході пропонується забути про SQL і мислити об'єктно, але в той же час використовувати досягнення розробників реляційних баз даних, шляхом здійснення відображення об'єктів і таблиць [3].
Система ведення відображених моделей (СВВМ) являє собою спеціалізоване програмне забезпечення для об'єктно-реляційного відображення баз даних.
Об'єктно-реляційне відображення (англ. Object-relational mappiпg — ORM) — технологія програмування, яка зв'язує бази даних з концепціями об'єктно-орієнтованих мов програмування, створюючи віртуальну об'єктну базу даних
. Існують як комерційні, так і безкоштовні реалізації цієї технології [4].
В об'єктно-реляційних базах даних інформація організується у вигляді знайомих реляційних табличних структур. Об'єктно-реляційнi (ОР) реалізації припускають підтримку реляційної моделі даних. ОР СУБД є поступовим розвитком попередніх їм реляційних СУБД. На відміну від чисто об'єктних баз дані, перехід до об'єктно-реляційних систем не вимагає масового перепрограмування [5].
Мета і завдання, плановані результати
Метою магістерської роботи є розробка ORM-системи, що дозволяє зберігати дані про рухомі одиницi і їх складовi частини в спеціальних моделях. Для зберігання даних передбачається наявність різних контейнерів моделей.
Призначення контейнера моделей — об'єктне представлення моделей АСКВП (або будь-яких інших моделей СВВМ), яке реалізує функціональність розміщення даних в оперативній пам'яті, обміну даними із зовнішнім програмним кодом, збереження даних на жорсткий диск і відновлення з жорсткого диска.
Контейнер моделей дозволяє зберігати в собі будь-яку кількість оперативних моделей, тому на етапі виконання він взаємодіє з компонентами, які реалізують уявлення моделей в оперативній пам'яті (бібліотечними модельними класами-спадкоємцями для конкретних моделей АСКВП).
Контейнер моделей розробляється як плагін, який підключається до комплексу управління викликами, потоками і компонентами. Усередині себе контейнер моделей містить колекцію моделей СВВМ, за допомогою якої він реалізує практично всю технологічну функціональність. Можна сказати, що контейнер моделей — обгортка для колекції моделей, яка перетворює останню з просто класу в модуль, який підключається до комплексу управління викликами, процесами і компонентами.
Оскільки контейнер моделей зберігається в оперативній пам'яті, можливо прискорення роботи з даними, що мiстяться в ньому. Однак для великої кількості даних необхідні сервери з великим об'ємом оперативної пам'яті.
Повинні використовуватися об'єктно-орієнтовані принципи, що дозволяють зменшити обсяги програмного коду і формувати певні базові структури і функції об'єктів.
Контейнер моделей повинен реалізовувати такі функції, як створення і наповнення колекції типових моделей, забезпечення збереження і завантаження даних типових моделей з файлів, забезпечення оновлення колекції моделей.
Огляд аналогів
Серед найбільш відомих 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, 148 кБ)
Структура типізованих моделей в комплексі АСКВП повністю генерується спеціалізованими засобами. Система ведення відображених моделей повинна в основному копіювати структуру АСКВП, при цьому деякі поля чи таблиці, що не використовуються, можуть бути відсутніми для зменшення обсягів використовуваної пам'яті на серверах додатків і АРМ-ах.
Процес генерації
В процесі генерації відбувається отримання XML-опису, на основі якого генерується код моделей СВВМ. Отриманий опис може бути зменшений або доповнений моделями, які відсутні в базі даних. Після виконання процесу генерації з програмного коду збираються бібліотеки, які можуть бути використані розробниками прикладного коду.
У сервера додатків дані надходять при виконанні запитів, які також є згенерованими. Отримана інформація формує контейнери даних, які зберігаються в оперативній пам'яті.
Процес серіалізації і десеріалізації
На жаль, в даний час швидкість передачі даних між АРМ-ами критично мала та може періодично обриватися. Тому до передачі даних пред'являються особливі вимоги:
- обсяг переданих даних повинен бути вкрай малим;
- при запису та відновленні даних повинен використовуватися мінімальний обсяг пам'яті;
- швидкість передачі даних повинна регулюватися (наприклад, між ділянками з малою пропускною здатністю необхідно зменшувати швидкість, щоб уникнути втрат даних).
У середовищі .NET більшість стандартних об'єктів можна перетворювати в масив байт. Процес перетворення прийнято називати серіалізацією. Зворотній йому процес називається десеріалізацією. Однак при стандартній серіалізації в більшості випадків записується зайва (службова) інформація, що може значно збільшити розмір даних, що передаються. Для зменшення цих даних передбачена підтримка процесів спеціалізованої серіалізації / десеріалізації. Крім того, передбачена можливість стиснення архіватором. У більшості випадків немає необхідності передавати на АРМ всі поля даних, тому інформація передається за допомогою спеціальних схем, які визначають склад даних, що передаються.
При розробці системи також необхідно враховувати особливі вимоги, які пред'являються до процесу десеріалізації. Оскільки більша частина виділеної додатком оперативної пам'яті використовується для зберігання об'єктів СВВМ, небажаним є перевищення її обсягу, в разі чого додаток завершить свою роботу з помилкою. Для вирішення цієї проблеми у проекті використовується процес послідовного фрагментарного отримання даних з потоку. Ітераційне виконання цього процесу дозволяє істотно скоротити обсяг виділеної оперативної пам'яті.
Взаємодія з автоматикою
У наш час існують різні види автоматизованих систем. Умовно їх можна поділити на два види: лінійні та інформаційні. Лінійні системи дають уявлення про проходження рухомою одиницею контрольної ділянки в певний момент часу, інформаційні ж системи дають інформацію про конкретно взяту рухому одиницю, яка повинна подолати контрольну ділянку в деякий (приблизний) момент часу [9].
Для отримання найбільш достовірної картини необхідна реалізація взаємодії двох таких систем: отримання точного часу проходження та ідентифікація рухомої одиниці.
Розробка інтерфейсу взаємодії забезпечить уніфікацію взаємодії мікропроцесорних систем (МПЦ) диспетчерського управління, диспетчерської централізації (ДЦ) і диспетчерського контролю (ДК), з автоматизованою системою управління вантажними перевезеннями (АСКВП) і, як наслідок, суттєво зменшить витрати при підключенні систем МПЦ різних розробників [10].
Структура взаємодії
Заропонована структура взаємодії АРМ і систем МПЦ зображена на рис. 3:
Рисунок 3 — Запропонована структура взаємодії АРМ і систем МПЦ
Інформація, що надається системами МПЦ, передається від серверної сторони до клієнтської стороні у вигляді інформаційних повідомлень. На підставі інформації з повідомлень формуються об'єкти (моделі), які будуть записані в СВВМ.
Серверний варіант контейнера моделей СВВМ також може оновлюватися шляхом внесення змін, які надходять з локальних контейнерів моделей.
Висновки
Передбачається, що спеціалізована система ведення відображених моделей, яка розробляється, буде максимально відповідати всім висунутим вимогам, і при цьому дозволить отримувати всі необхідні дані. На даний момент проект знаходиться в стадії доопрацювання та кореляції з попередніми розробками з метою збереження даних.