Запропоновано підхід формальної верифікації UML 2.0 через відображення OWL-DL в UML 2.0. У результаті розроблено оригінальний метод до відображення OWL-DL в UML 2.0 через дескриптивну логіку. Забезпечено повноту відображення UML-OWL через стереотипи та мічені значення UML 2.0 на рівні М0, М1 метамоделі МОF. Запропоновано модель інформаційного об'єкта для семантичної електронної бібліотеки, яка побудована з використанням мови UML. Також здійснено перевірку запропонованої моделі шляхом відображення моделі UML в OWL з наступною валідацією побудованої онтології за допомогою різонерів. Ключові слова: електронна бібліотека, семантична електронна бібліотека, зв'язані дані, інформаційний об'єкт, відображення UML-OWL, дескриптивна логіка, різонер. Предложен подход формальной верификации UML 2.0 с использованием отражения OWL-DL в UML 2.0. В результате разработан оригинальный метод к отображению OWL-DL в UML 2.0 через дескриптивную логику. Обеспечена полнота отображения UML-OWL через стереотипы и меченые значение UML 2.0 на уровне М0, М1 метамодели МОF. Предложена модель информационного объекта для семантической электронной библиотеки, которая построена с использованием языка UML. Также осуществлена проверка предложенной модели путем отражения модели UML в OWL и последующей валидации построенной онтологии с помощью ризонеров. Ключевые слова: электронная библиотека, семантическая электронная библиотека, связанные данные, информационный объект, отображение UML-OWL, дескриптивная логика, ризонер. This article has provided the principles of building digital libraries in the Semantic Web environment with using linked data technology. The advantage of linked data is that the value and usefulness of the data increases according to how much more it is linked to other data. Therefore it is important to design a semantic digital library by using linked data and formalize the model of the information object.. Most classic digital libraries are used a relational databases. However, modern approaches to mapping relational databases to linked data do not take into account the specifics of the database schemes of traditional digital libraries. To formalize the requirements for the databases design, UML is widely used. This paper proposes a UML model of an information object for digital library that corresponds to the principles of linked data. The UML class diagram is used as the main method. The problem of building a model of an information object and its verification is topical for this method of design. This digital library design method has an urgent problem of building a model of an information object and its verification. The article develops a method of formal verification of UML 2.0 through the mapping of OWL-DL in UML 2.0. As a result, an original method for mapping OWL-DL to UML 2.0 by using description logic (DL) was developed. The completeness of OWL-DL mapping with the help of stereotypes and tagged values of UML 2.0 at the level of M0, M1 of the MOF metamodel was provided. The model of an information object for a digital library in a semantic environment, which is built by using the UML language, is proposed. The proposed model was also tested by mapping the UML model to OWL with the subsequent its validation by using Protégé reasoner. The article also discusses the significant differences between UML and OWL and the consequences that must be taken into account when constructing a mapping. This approach allows to formally evaluates the correctness of the UML class diagram and detect semantic level errors. Електронні бібліотеки наразі функціонують в мережі Інтернет. І на даний момент розвитку науки існує необхідність публікувати інформаційні ресурси в мережі Інтернет. Для публікації семантичних даних, широкого розповсюдження набула методологія зв'язаних даних (LD) [1]. Щоб опублікувати дані в Інтернеті, ми спочатку повинні ідентифікувати елементи, що представляють інтерес в нашому домені. Вони є сутності чиї властивості і відносини ми хочемо описати в даних. В термінології Веб Архітектури, всі елементи, що представляють інтерес, називаються ресурсами. У великому різноманітті технологій, що пов'язані з Semantic Web, важливо встановити співвідношення в якому перебувають LD до цих технологій. Зв'язані дані дають бачення використання Інтернету для підключення відповідних даних, які раніше не були пов'язані між собою, або використовуючи Web, знизити бар'єри для зв'язування даних, які в даний час пов'язані з використанням інших методів. Або більш конкретно, LD - це підхід, який використовується для опису методів для виявлення, спільного використання та підключення частин даних, пошуку інформації та знань в Semantic Web, використовуючи URIs, SPARQL і RDF [1, 2]. На даний момент, нема чіткого розуміння того, що являє собою ЕБ в середовищі Semantic Web. Багато робіт були присвячені даній проблемі. Зокрема в [3] робиться більше акцент на використання онтологій та побудови онтологій для ЕБ. В роботі [4] розглядається розвиток ЕБ в напрямку семантичних соціальних ЕБ, в
яких значна увага приділяється обміну знань та більш потужним механізмам взаємодії користувачів і проникнення соціальних комунікацій в семантичні ЕБ (СЕБ).
Розробка моделі даних ЕБ в рамках підходу LD дасть змогу наблизити електронні бібліотеки до повноцінної реалізації Semantic Web.
Однак, коли виникає питання розробки програмного забезпечення, одним із центральних аспектів є формалізація вимог до програмного продукту. В такій ситуації, широкого застосування набув UML (англ. Unified Modeling Language) це уніфікована мова моделювання, використовується у парадигмі об'єктноорієнтованого програмування. Вона є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, названої UML-моделлю. UML був створений для визначення, візуалізації, проектування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.
UML є стандартизованим та формалізованим засобом для розробки та аналізу програмного забезпечення. Для підтримки розробки великих додатків існують складні CASE інструменти, які забезпечують зручні умови для редагування, зберігання і доступу до діаграм UML. Однак в таких інструментах відсутні засоби інтелектуального аналізу. Для UML характерно надлишковість та протиріччя, які важко виявити. Вважається, що UML діаграма класів, є одним з найбільш важливих компонентів UML. Для перевірки моделей, створених за допомогою діаграми класів UML, необхідно провести над цією моделлю логічні судження. Тобто перевірка на несуперечність, здійснимість, класифікацію та реалізацію концептів.
В роботі [
Огляд досліджень з проблематики верифікації UML
Існують різні методології верифікації UML моделей діаграм класів. Так, найбільш простим є підхід,
пов'язаний з побудовою драйвера [
При виникненні питання щодо розроблення програмного забезпечення та інтеграції класичних ЕБ до
СЕБ, одним із центральних аспектів є формалізація вимог до моделі ІО. У такій ситуації широкого застосування
набула UML. В базис UML покладено стандарт MOF (мета-об'єктний засіб). Мета-об'єктний засіб (Meta-Object
Facility) – це стандарт для розробки, керованої моделями, розроблений OMG (Ontology Definition Metamodel)
[
M3 M2 M1 M0
MOF MetaModel UMLMetaModel
UMLModels
User Data
Рис. 1. Чотирьохрівнева архітектура метамоделі Найнижчий рівень, M0, містить дані користувача – фактичні об'єкти реального світу, якими і має маніпулювати програмне забезпечення. Наступний рівень, M1 визначають як рівень, що містить моделі, призначені для даних користувача рівня M0. Рівень M2 містить моделі інформації, що зберігається на рівні M1. Нарешті, рівень M3 містить модель інформації, що зберігається на рівні M2, і має назву метамодель. Класичним прикладом моделі рівня М2 є UML.
Для підтримання розробки великих додатків існують складні інструменти, що забезпечують умови для
редагування, зберігання й доступу до діаграм UML. Однак у таких інструментах відсутні засоби
інтелектуального аналізу. Для UML характерні надлишковість та протиріччя, які важко виявити. Діаграма
класів UML є одним з найбільш важливих компонентів UML. Для перевірки моделей, створених за допомогою
діаграми класів UML, необхідно провести відповідно до цієї моделі логічні судження. В UML немає
вбудованих засобів для її верифікації та валідації. Проте існують певні погляди вирішення цієї проблеми [
Побудова та перевірка еталонної моделі інформаційного об’єкту ЕБ В основу моделі ІО покладено ідею абстрагування ресурсу від його реалізації та уніфікації з сервісом. Для нашої моделі використаємо ресурсо-орієнтований погляд, що означає дуалізм при взаємодії з ІО. Тобто будь-який сервіс намагатиметься представитися у вигляді ІО, при цьому кожного разу такий сервіс буде обчислювати своє представлення у вигляді ІО.
У контексті зв’язаних даних будь-яке звернення до ресурсу має бути представлено як набір даних у вигляді певного графу. При цьому повинна забезпечуватися сумісність з такими мовами запитів, як SPARQL. Відповідна взаємодія може покритися архітектурним стилем REST (Representational State Transfer). У цій роботі пропонується об’єднати концепцію зв’язаних даних та концепцію сервіс-орієнтованої архітектури до побудови моделі ІО. Це дозволить маніпулювати динамічними інформаційними ресурсами в межах однієї моделі. Концептуально REST є спробою побудови архітектури, в якій сучасній архітектурі мережі Інтернет надається можливість перейти на новий рівень взаємодії між вузлами. В основі REST передбачені такі обмеження до моделювання ІО: масштабованість окремих компонентів та їх взаємодія; клієнти відокремлені від сервера єдиним інтерфейсом – розділення відповідальності означає, що клієнти не відповідають за сховище даних, що є внутрішнім для кожного сервера;
взаємодія клієнт-сервера обмежується відсутністю збереження контексту клієнта на сервері між запитами. Кожен запит від будь-якого клієнта містить усю інформацію, необхідну для його обслуговування, а будь-який стан сесії зберігається в клієнті. Сервер може бути в певному стані. Це обмеження вимагає, щоб стан на стороні сервера ідентифікувався через URL. Це не тільки робить сервери більш видимими для моніторингу, а й робить їх більш надійними в разі часткової відмови мережі. Тобто клієнти не пов'язані із зберіганням даних, ця функція залишається за сервером. Сервери в свою чергу не пов'язані з інтерфейсом або станом користувача; можливість кешування – клієнти можуть кешувати відповіді; багаторівневість системи; легкість у розгортанні сервера; єдиний інтерфейс між клієнтами і серверами спрощує й розділяє архітектуру, даючи змогу кожній частині розвиватися самостійно.
Проте Semantic Web, зокрема реалізація мережі зв’язаних даних, вносить певні зміни в проектування REST взаємодії між серверами та клієнтами. Оскільки LD є розподіленою мережею, то нівелюються розділення на клієнт-серверну частину, тому що кожен вузол може одночасно виконувати роль і клієнта і сервера. Це пов’язано з тим, що набори даних на різних серверах можуть легко об’єднуватися між собою, утворюючи певну мережу. Також дані в LD є відкритими – це означає: крім того, що кожен може ввести певні зміни в LD, у будьякий момент часу в онтологіях, на яких базується LD, можуть бути додані чи видалені відношення чи твердження, які будуть пливати на мережу LD+REST. З поміж них можна виділити такі, що подано у таблиці. Таблиця Клієнт-серверна архітектура передбачає Виконання запитів SPARQL може призводити до зміни незалежність запитів між собою, причому як станів будь-якого вузла мережі, отже, це суперечить клієнт, так і сервер може мати власні стани принципам REST Головною особливістю, яка відрізняє REST В LD визначено фактично декілька інтерфейсів архітектурний стиль від інших мережевих стилів, взаємодії з даними. Усі вони базуються на протоколі є акцент на єдиний інтерфейс між компонентами. HTTP, але мають різне призначення. Зокрема, RDF Ця особливість є найбільшою відмінністю. може мати різний тип спеціалізації (JSON/XML). Завдяки застосуванню під час розроблення Водночас доступ до даних може відбуватися або через програмного забезпечення принципу пряме звернення до ресурсу, або через точки доступу уніфікованості інтерфейсу загальна архітектура SPARQL системи спрощується і видимість взаємодії поліпшується. Реалізація відокремлених послуг сприяє незалежному розвиткові. Компроміс полягає в тому, що універсальний інтерфейс знижує ефективність, бо інформація передається в стандартизованій формі, а не у специфічній для потреб програми
На модель інформаційного об’єкта, що пропонується (рис. 2), накладаються деякі обмеження: інформаційний об’єкт (ІО) функціонує у веб-середовищі. Це означає, що доступ до ресурсів відбувається за протоколом HTТP. Центральним об’єктом моделі є ІО, який фактично є контейнером для інформаційного наповнення. Тобто контент інформаційного ресурсу міститься в ІО. Кожен ІО унаслідується від інформаційного ресурсу. Інформаційний ресурс необхідний, щоб надати можливість ІО отримати низку додаткових властивостей. Основна функція інформаційного ресурсу – це забезпечення доступу до ІО за протоколом HTTP. У межах моделі передбачається віддалений доступ за ідентифікатором URI. Між ІО можуть бути бінарні відношення, предикат для цих відношень задається в зовнішніх онтологіях. Ці бінарні відношення дозволяють розкривати семантику ІО через визначення взаємозв’язків з іншими ІО. Наприклад, вони можуть визначати видавця ІО. Бінарні відношення моделюють RDF-трійки.
Проте виділено окремий тип відношень, які агрегують ІО в колекції. Це пов’язано з тим, що в ЕБ
ресурси, як правило, зв’язані між собою певними визначеними сутностями. Наприклад, у багатьох ресурсах
може бути один і той же автор, або ресурси можуть відноситися до одного і того ж предметного
класифікатора [
Тому виникає необхідність групувати ресурси за певними суттєвими спільними ознаками. Ці групи
називаються колекції [
Resource «realize»
URI - scheme: char =http:
InformationResource
NonInformationResource 303 redirect
WebService «objectPro... - operations classInformationObjectModel Рис. 2. Модель інформаційного об’єкта в UML В ЕБ представлено множину інформаційних ресурсів, які описують певні публікації, кожна з яких описується певним набором ІО. Модель також покриває сервіс-орієнтовану архітектуру в межах REST. Кожен стан веб-сервісу в моделі розглядається як певний інформаційний ресурс. ІО можуть поєднуватися в певні набори або так звані колекції. Тобто оболонкою для ІО в моделі є інформаційний ресурс і саме наповнення інформаційного ресурсу міститься в ІО. Кожен ІО унаслідується від інформаційного ресурсу.
Відповідне відображення до OWL має вигляд, показаний на рис. 3.
Рис. 3. Модель інформаційного об’єкту в OWL
Для верифікації розробленої моделі запропоновано метод, суть якого полягає у наступному. Спочатку
кожен клас UML відображаються в концепт ДЛ SHOIQ. На наступному етапі відбувається відображення для
всіх відношень та атрибутів діаграми класів UML в ролі ДЛ. Згодом всі вирази ДЛ переносяться в Protégé.
Розроблена модель пройшла перевірку на когерентність і послідовність такими машинами виводу, як Pellet [
UM L2.0 Рис. 4. Схема верифікації розробленої моделі ІО Висновки Одним із шляхів розв’язання проблеми інтеграції даних в ЕБ є використання моделі зв’язаних даних Linked Data (LD). Перевага зв’язаних даних полягає у тому, що цінність і корисність даних збільшується відповідно до того, наскільки більше вони пов'язані з іншими даними. Більшість класичних ЕБ побудовані з використанням реляційної БД. Проте сучасні підходи до відображення реляційних баз даних до зв’язаних даних не враховують специфіку схем бази даних класичних ЕБ. Для вирішення цієї задачі необхідно розробити відповідний метод відображення. Окрім цього актуальною є проблема побудови моделі ІО та її верифікації. Для вирішення даних задач, було отримано наступні результати. Розроблено метод формальної верифікації UML 2.0 через відображення OWL-DL в UML 2.0. У результаті розроблено оригінальний метод до відображення OWLDL в UML 2.0 через ДЛ. Забезпечено повноту відображення з OWL-DL через стереотипи та мічені значення UML 2.0 на рівні М0, М1 метамоделі МОF. Запропоновано модель інформаційного об'єкта для СЕБ, яка побудована з використанням мови UML. Також здійснено перевірку запропонованої моделі шляхом відображення моделі UML в OWL з метою валідації цієї моделі засобами машин-суджень.
Література