В статті запропоновано відображення діаграми класів UML до дескриптивної логіки діалекту SHOIQ. Запропоновано розширення нотацій UML, шляхом використання стереотипів, для максимального наближення семантичних конструкцій. Вказано на причини та проблеми що виникають при такому відображенні. Ключові слова: UML, Дескриптивна логіка, semantic web, валідація діаграм класів UML. В статье предложено отображения диаграммы классов UML в дескриптивную логику диалекта SHOIQ. Предложено расширение нотаций UML путем использования стереотипов, для максимального приближения семантических конструкций. Указано на причины и проблемы, которые возникают при таком отражении. Ключевые слова: UML, дескриптивная логика, semantic web, валидация диаграмм классов UML. In the article, propose mapping from UML class diagrams to SHOIQ. descriptive logic. Made approach through extension the UML notations by using stereotypes as close to semantic structures. Specified on the causes and problems that arise in such mapping.
Огляд досліджень з проблематики верифікації UML
характерні помилки. Ще одним підходом до верифікації діаграми класів є метод шаблонів, який
запропонований в
Мови OWL та UML були розроблені для різних цілей. OWL призначена для подання знань про
інформаційну складову предметної області, UML розроблено перш за все для підтримки розробки
програмного забезпечення. Хоча мови різні, але основна їх ціль є формальне представлення знань. В ранніх
роботах (Cali et al., 202),
Водночас, консорціум Object Management Group розробив метамодель визначення онтології (Ontology
Definition Metamodel – ODM), що визначає набір мета-моделей UML
В роботах
Представлення знань та інформації про розробку програмного забезпечення, як правило, мають різні цілі при записі інформації. Робляться відповідні, але різні припущення щодо інтерпретації мовних висловів, чи заяв. Безліч припущень впливають на семантичну відповідність між мовними конструкторами і їх нотаціями. Якщо в OWL такі невідповідності можуть бути усунені, а вирази більш однозначні, то в UML вони більш різноманітні. UML дозволяє різні інтерпретації конструкцій мови в залежності від точки зору. Є певні суттєві відмінності між UML та OWL:
• в діаграмі класів UML ми працюємо з припущенням про закритість світу. Тобто всі твердження, що не були явно вказані, є хибними. Натомість OWL використовує припущення відритого світу. Припущення ж про відкритість світу, в цьому випадку, припускає, що деяке твердження є ні істинним, ні хибним; • UML має поняття профілів, що дозволяють розширювати мета-моделі елементів UML. Водночас OWL немає відповідної конструкції. У більшості випадків профілі UML використовуються для визначення стереотипів, щоб розширити класи. Представлення цих стереотипів може бути відображено до OWL через створення ряду нових класів та узагальнення тверджень. Однак більша частина профілю UML доволі специфічна і вимагає відповідні правила перетворення, адаптовані для певного профілю; • абстрактні класи UML не можуть бути перетворені в OWL. Якщо клас визначається як абстрактний в UML, то це означає що екземпляри цього класу (об’єкти) не можуть бути створені. В OWL не закладено функцію, що вказувала б на те, що клас не повинен містити екземплярів. Одним із підходів до збереження семантики абстрактного класу є використання DisjointUnion. Це буде гарантувати, що будь-який екземпляр, який належить до підкласу, також відноситься до абстрактного суперкласу. Тим не менш, це не забороняє створювати екземпляри абстрактного суперкласу;
• в UML видимість елементів моделі може бути зменшена шляхом маркування їх як public, private, і т. д. Також можна оголосити елементи UML моделі, які доступні тільки для читання. В OWL відсутній механізм управління, щоб обмежити доступ до елементів моделі. OWL онтології також не можуть містити будь-яких операцій;
• в OWL можливо визначати властивості об’єкту на рівні онтології. І такі властивості не обов’язково повинні бути прив’язані до класу. Водночас, UML пропонує два способи прив’язки атрибутів. Через атрибут класу та через асоціації. Як випливає з назви, в першому випадку, атрибут класу відноситься до класу. Асоціації визначені на рівні пакету діаграми класів. Тим неменше, такі асоціації повинні мати на полюсах класи як типи. Тому UML асоціації не повністю підходять для представлення загальних властивостей об’єкту.
При моделюванні тверджень про об’єкти реального світу обидві мови використовують відповідні конструктори (наприклад, класи і об’єктів). OWL та UML виділяють відмінність між термінологічними (інтенсіональними) і екстенсіональними (твердженнями) знаннями. Судження про UML діаграму класів використовуючи SHOIQ
В наслідок концептуальних розбіжностей між UML та OWL, не можливо побудувати однозначне
відображення. В деяких роботах
Таблиця 1
UML
Дескриптивна логіка A D ⊑C D≡C D ⊑¬C C ⊓D UML
Дескриптивна логіка D ⊑C ⊔E
Надалі, для розвинення відображення, ми будемо використовувати механізми розширення. Механізми розширення – це вбудовані в мову способи розширити можливості мови. В UML включено багато методів так, щоб мова виявилася придатною в різних контекстах і предметних областях. Механізми розширення дозволяють визначати нові елементи моделі на основі існуючих.
Рис. 1. Ієрархія класів Кожна генералізація в специфікації UML 2 має дві основні властивості: це покриття, що може бути повним (complete) або неповним (incomplete); та властивість перетину, яка може бути з перетином (overlapping) або без перетину (disjoint).
Повнота означає, що кожен екземпляр, більш загального класу, повинен належати принаймні до одного із специфікованих класів.
Перетин визначає, чи можуть специфіковані класи мати спільні екземпляри, тобто у випадку наявності хоча б одного спільного екземпляру говорять про генералізацію з перетином.
В UML 2.x кожна генералізація є неповною. Відмінність між UML 2.x та UML 2.5 полягає у відсутності та наявності перетину відповідно. Тому, якщо ми хочемо досягнути відсутності перетину, то обмеження класів C1 …. Cn, що не перетинаються, може бути змодельоване як Ci⊑¬ Cj, де 1≤i<j≤n. Водночас як повнота узагальнення може бути виражена як C ⊑ C1 ⊔…. ⊔ Cn (табл. 2).
Дескриптивна логіка Абстрактний синтаксис OWL Таблиця 2
D
UML E
C C R: C ∀R .C C ⊑∀R .C owl:unionOf owl:complementOf(C) owl:allValuesFrom C subClassOf Restriction on allValuesFrom Мультиплікативне відношення [i..j] для owl:restriction(R maxCardinality(n)) ролі R класу формалізуються наступним owl:restriction(R minCardinality(n)) чином C⊑(≥iR.D)⊓(≤jR.D) Коли j рівно *, то ми відкидаємо другий конюкт. Коли мультиплікативне відношення має вигляд [0...*], тоді опускають ціле твердження. Коли мультиплікативне відношення має вигляд [1...1], то твердження матиме наступний вигляд C⊑∃R.⏉⊓(≤1R). {existential restriction }
R: C ∃R .C owl:restriction(R someValuesFrom(C))
R [1..n]
A Направлена асоціація
R 0..n
B UML Дескриптивна логіка Розглянемо більш детально деякі конструкції. Для досягнення більшої повноти відображення ми вводимо додаткові нотації в UML (табл. 3).
Таблиця 3 Нотація R: D R: D Назва нотації Заперечення існування класу Доповнення Опис нотації Нотація означає, що даний клас в предметній області, яка моделюється, існувати не може. Нотація позначає існування властивості певного типу.
A Залежність. Доповнення класу Означає, що клас А властивість R типу D.
має Асоціації з асоціативним класом
Подібно до того, як об’єкти класу можуть бути записані за допомогою атрибутів, асоціативне відношення також може мати атрибути. UML дозволяє представляти інформацію такого характеру за допомогою класів асоціацій. Клас асоціації – це асоціація, яка одночасно є класом. Подібно зв’язкам асоціації, екземпляри класу асоціації мають індивідуальність, пов’язаної з тими об’єктами, між якими вони проводяться. Подібно звичайним класам, класи асоціацій можуть мати атрибути та операції, і брати участь в асоціаціях.
Для представлення мультиплікативного відношення A з асоціативним класом (рис. 2.), необхідно використати якісне обмеження кардинальності ролі (qualified number restrictions).
C1 +r1 min1..max1 +r2
C2 min2..max2
A Рис. 2. Асоціації з асоціативним класом Кожен екземпляр класу C1 асоційований з екземплярами класу C2 , через асоціативний клас A . При цьому клас A може мати певні атрибути.
Відношення через асоціативний клас може мати n-арність на полюсах. В такому випадку, ми отримуємо відношення: , class Domain Model
A
R Асоціації в UML Кожні бінарні асоціації (чи агрегації) між класами C1 і C2 мають вигляд (рис. 5).
Рис. 5. Бінарна асоціація Такі асоціації можуть бути трансформовані до твердження дескриптивної логіки через використання атомарної ролі A разом з твердженням включення: Мультиплікативність асоціативного відношення A формалізується наступними твердженнями: Кожний екземпляр концепту C1 зв’язаний через атомну роль A з, принаймні, min1 і не більше max1 екземплярами концепту C2:
C1⊑(≥min1A)⊓(≤max1A).
Кожний екземпляр концепту C2 зв’язаний через атомну роль екземплярами концепту C1. з, принаймні, min2 і не більше max2 .
Слід відмітити, що агрегація в UML – це особливий вид бінарної асоціації без асоціативного класу.
В роботі розглянуто проблематику верифікації діаграм класів UML за допомогою відображення до OWL.
В даному підході також передбачена можливість зворотного відображення. Ця методика надає можливість
верифікувати діаграму класів UML через механізми судження, що суттєво розвинуті в дескриптивній логіці.
Представлене відображення не є однозначним, в наслідок того, що UML була з самого початку націлена на
визначення формальних специфікації для розробки ПЗ з властивістю гнучкості та простотою нотацій. Так
гнучкість та неоднозначність призвела до наслідків важкості автоматизованого аналізу діаграми класів UML.
Зокрема, асоціація в UML описує набір кортежів, чиї значення відносяться до типу екземплярів. Іншими
словами, асоціація специфікує семантичні відношення, які можуть виникнути між екземплярами певних типів.
За замовчуванням, асоціація є ненаправленою, проте при нотаціях може бути використаний