Extending UML specification for semantic modeling objects
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.Problems in programming 2016; 2-3: 211-219
Збережено в:
| Дата: | 2018 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
Інститут програмних систем НАН України
2018
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/198 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-198 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/43/68c0b0e3752b722076c4ce3830421f43.pdf |
| spelling |
pp_isofts_kiev_ua-article-1982024-04-28T13:09:58Z Extending UML specification for semantic modeling objects Расширение UML спецификации для моделирования семантических объектов Розширення UML специфікації для моделювання семантичних об’єктів Novitsky, A.V. UML; description logick; semantic web; validation class diagram uml UDC 004.41 UML; дескриптивная логика; semantic web; валидация диаграмм классов UML УДК 004.41 UML; дескриптивна логіка; semantic web; валідація діаграм класів UML УДК 004.41 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.Problems in programming 2016; 2-3: 211-219 В статье предложено отображения диаграммы классов UML в дескриптивную логику диалекта SHOIQ. Предложено расширение нотаций UML путем использования стереотипов, для максимального приближения семантических конструкций. Указано на причины и проблемы, которые возникают при таком отражении.Problems in programming 2016; 2-3: 211-219 В статті запропоновано відображення діаграми класів UML до дескриптивної логіки діалекту SHOIQ. Запропоновано розширення нотацій UML, шляхом використання стереотипів, для максимального наближення семантичних конструкцій. Вказано на причини та проблеми що виникають при такому відображенні.Problems in programming 2016; 2-3: 211-219 Інститут програмних систем НАН України 2018-07-06 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/198 10.15407/pp2016.02-03.211 PROBLEMS IN PROGRAMMING; No 2-3 (2016); 211-219 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2-3 (2016); 211-219 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2-3 (2016); 211-219 1727-4907 10.15407/pp2016.02-03 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/198/193 Copyright (c) 2017 ПРОБЛЕМИ ПРОГРАМУВАННЯ |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2024-04-28T13:09:58Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UML description logick semantic web validation class diagram uml UDC 004.41 |
| spellingShingle |
UML description logick semantic web validation class diagram uml UDC 004.41 Novitsky, A.V. Extending UML specification for semantic modeling objects |
| topic_facet |
UML description logick semantic web validation class diagram uml UDC 004.41 UML дескриптивная логика semantic web валидация диаграмм классов UML УДК 004.41 UML дескриптивна логіка semantic web валідація діаграм класів UML УДК 004.41 |
| format |
Article |
| author |
Novitsky, A.V. |
| author_facet |
Novitsky, A.V. |
| author_sort |
Novitsky, A.V. |
| title |
Extending UML specification for semantic modeling objects |
| title_short |
Extending UML specification for semantic modeling objects |
| title_full |
Extending UML specification for semantic modeling objects |
| title_fullStr |
Extending UML specification for semantic modeling objects |
| title_full_unstemmed |
Extending UML specification for semantic modeling objects |
| title_sort |
extending uml specification for semantic modeling objects |
| title_alt |
Расширение UML спецификации для моделирования семантических объектов Розширення UML специфікації для моделювання семантичних об’єктів |
| description |
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.Problems in programming 2016; 2-3: 211-219 |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2018 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/198 |
| work_keys_str_mv |
AT novitskyav extendingumlspecificationforsemanticmodelingobjects AT novitskyav rasširenieumlspecifikaciidlâmodelirovaniâsemantičeskihobʺektov AT novitskyav rozširennâumlspecifíkacíídlâmodelûvannâsemantičnihobêktív |
| first_indexed |
2024-09-12T19:08:17Z |
| last_indexed |
2024-09-12T19:08:17Z |
| _version_ |
1818568165880233984 |
| fulltext |
Інтелектуальні інформаційні технології
© О.В. Новицький, 2016
ISSN 1727-4907. Проблеми програмування. 2016. № 2–3. Спеціальний випуск 211
УДК 004.41
РОЗШИРЕННЯ UML СПЕЦИФІКАЦІЇ ДЛЯ МОДЕЛЮВАННЯ
СЕМАНТИЧНИХ ОБ’ЄКТІВ
О.В. Новицький
В статті запропоновано відображення діаграми класів 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.
Key words: UML, description logick, semantic web, validation class diagram uml.
Вступ
Електронні бібліотеки (ЕБ) наразі функціонують у мережі Інтернет. Центральним об’єктом, що є
носієм інформації в ЕБ – інформаційний ресурс. Існують різноманітні підходи до моделювання, управління і
публікації інформаційних ресурсів в ЕБ. Значна частина підходів до управління інформаційними ресурсами
пов’язана з Semantic Web. Наприклад, для публікації семантичних даних, широко розповсюдження набула
ідеологія зв’язаних даних (LD) (Linked Data, 2015). Зв’язані дані дають можливість використання Інтернету
для підключення відповідних даних, що раніше не були пов’язані між собою. Або більш конкретно, LD – це
підхід, що використовується для опису методів виявлення спільного використання та підключення частин
даних, пошуку інформації та знань в Semantic Web, використовуючи URIs, SPARQL і RDF (Linked Data,
2015) (Berners-Lee, 2009).
На даний момент, у дослідників не існує чіткого розуміння, що являє собою ЕБ в середовищі Semantic
Web. Багато робіт, були присвячені даній проблемі. Зокрема, в (Sure and Studer, 2005) робиться більше
акцент на побудову та використання онтологій для ЕБ. В (Alotaibi, 2010) розглядається розвиток ЕБ у
напрямку семантичних соціальних ЕБ, в яких значна увага приділяється обміну знань та більш потужним
механізмам взаємодії користувачів. Розробка моделі даних ЕБ, в рамках підходу LD, дасть змогу наблизити
електронні бібліотеки до повноцінної реалізації Semantic Web.
Однак, коли виникає питання розробки програмного забезпечення, в тому числі ЕБ, одним із
центральних аспектів є формалізація вимог до програмного продукту. У такій ситуації, широкого
застосування набула UML (англ. Unified Modeling Language) – це уніфікована мова моделювання, що
використовується у парадигмі об’єктно-орієнтованого програмування. UML є невід’ємною частиною
уніфікованого процесу розробки програмного забезпечення. Вона є мовою широкого профілю, це відкритий
стандарт, що використовує графічні позначення для створення абстрактної моделі системи, так званої
UML-моделі. UML був створений для визначення, візуалізації, проектування й документування в основному
програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей, як
інтерпретованого коду, можлива кодогенерація.
UML є стандартизованим та формалізованим засобом для розробки та аналізу програмного
забезпечення. Для підтримки розробки великих додатків існують складні CASE інструменти, що
забезпечують зручні умови для редагування, зберігання і доступу до діаграм UML. Однак в таких
інструментах відсутні засоби інтелектуального аналізу. Для UML характерні надлишковість та протиріччя,
які важко виявити. Вважається, що UML діаграма класів, є одним з найбільш важливих компонентів UML.
Для перевірки моделей, створених за допомогою діаграми класів UML, необхідно провести над цією
моделлю логічні судження. В UML немає вбудованих засобів для її верифікації та валідації. Проте існують
певні підходи вирішення цієї проблеми (Волович and Дерюгина, 2015). Використавши семантичний підхід і
здійснивши відображення моделі UML до OWL, верифікація та валідація зводяться до перевірки на
несуперечність, здійснимість, класифікацію та реалізацію концептів.
В даній роботі ми намагаємося розшити UML для більш повноцінного відображення UML в OWL та
навпаки.
Огляд досліджень з проблематики верифікації UML
Існують різні методології верифікації UML моделей діаграм класів (Волович and Дерюгина, 2015).
Так, найбільш простим є підхід, пов’язаний з побудовою драйвера (Макгрегор and Сайкс, 2002). Даний
Інтелектуальні інформаційні технології
212
підхід дозволяє формально оцінити правильність створення діаграми класів і виявити найбільш
характерні помилки. Ще одним підходом до верифікації діаграми класів є метод шаблонів , який
запропонований в (Sturm, Balaban and Maraee, 2010). Поняття шаблону, в даному підході, відрізняється
від добре відомого і зрозумілого поняття шаблону проектування. У роботі було запропоновано декілька
шаблонів помилок для виявлення протиріч в моделі. В роботі (Thalheim, 1993) розглянуто підхід на
основі побудови ідентифікаційного графа. Суть даного методу полягає в побудові ідентифікаційного графа,
що представляє собою орієнтований граф. Вузлами даного графа є класи, а також асоціативні зв ’язки між
ними, а дуги пов’язують асоціації з тими класами, між якими на діаграмі класів і вказані відповідні
асоціативні зв’язки.
Представлення інформації про домен засобами OWL та UML
Мови OWL та UML були розроблені для різних цілей. OWL призначена для подання знань про
інформаційну складову предметної області, UML розроблено перш за все для підтримки розробки
програмного забезпечення. Хоча мови різні, але основна їх ціль є формальне представлення знань. В ранніх
роботах (Cali et al., 202), (Cranefield and Purvis, 1999), (Brockmans et al., 2004) було висвітлено, яким чином
можливо визначати онтологію засобами UML. В UML є кілька вбудованих засобів для формалізації
семантики. Наприклад, Object Constraint Language (OCL) є декларативною мовою описання правил, що
використовуються в UML, яка, на відміну від UML, має лінійну нотацію, а не графічну. На жаль так само, як
і в UML в OCL, відсутня формальна модель семантики, теоретична модель та формальний доказ теорем. І
тому, в UML не може бути механізмів для автоматизації міркувань.
Водночас, консорціум Object Management Group розробив метамодель визначення онтології (Ontology
Definition Metamodel – ODM), що визначає набір мета-моделей UML (Object Management Group, 2009) і
профілів для представлення UML в RDF, і OWL. У UML профілі в специфікації ODM адаптують нотації UML,
щоб надати форму візуального представлення для RDF і OWL.
В роботах (Simmonds, 2003), (Daniela, Diego and Giuseppe, 2005) були здійснені спроби щодо
трансформування діаграми класів 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 виділяють відмінність між термінологічними
(інтенсіональними) і екстенсіональними (твердженнями) знаннями.
Інтелектуальні інформаційні технології
213
Судження про UML діаграму класів використовуючи SHOIQ
В наслідок концептуальних розбіжностей між UML та OWL, не можливо побудувати однозначне
відображення. В деяких роботах (Berardia, Calvanese and De Giacomo, 2005) є спроби розширити OWL до
відповідного діалекту, що відповідав би UML. Ми в своєму підході намагаємося розшити UML через додаткові
нотації та стереотипи, щоб збільшити повноту відображення. І це дозволить проектувати формальні
специфікації у вигляді діаграми класів через онтології OWL. Ми робимо відображення основних конструкцій
UML до дескриптивної логіки та відповідних конструкцій OWL. В UML клас A представляється за допомогою
атомного концепту A (табл. 1).
Таблиця 1
UML Дескриптивна логіка
Абстрактний синтаксис
OWL
A Owl:Class. Атомний клас.
D⊑C rdfs:subClassOf
Фундаментальний
конструктор, який
оголошений в RDF Schema,
визначає, що клас D є
підкласом C.
D≡C owl:equivalentClass
D⊑¬C owl:disjointWith
C⊓D owl:intersectionOf
D⊑C⊔E D subClassOf unionOf C and
E
Інтелектуальні інформаційні технології
214
Механізми розширення UML. Стереотипи
Надалі, для розвинення відображення, ми будемо використовувати механізми розширення. Механізми
розширення – це вбудовані в мову способи розширити можливості мови. В UML включено багато методів так,
щоб мова виявилася придатною в різних контекстах і предметних областях. Механізми розширення дозволяють
визначати нові елементи моделі на основі існуючих.
Таких механізмів три:
мічені значення;
обмеження;
стереотипи.
Ці механізми не є незалежними, вони тісно пов’язані між собою.
Мічене значення (tagged value) – це пара, ім’я властивості і значення властивості, яка може бути додана
до будь-якого стандартного елементу моделі.
Обмеження (constraint) – це логічне твердження щодо значень властивостей елементів моделі.
Стереотип (stereotype) – це визначення нового елемента моделювання на основі існуючого елемента
моделювання.
Визначення стереотипу проводиться таким чином. Взявши за основу деякий існуючий елемент моделі, до
нього додають нові мічені значення (розширюючи тим самим внутрішнє представлення), нові обмеження
(змінюючи семантику) і доповнення, тобто нові графічні елементи (визначаючи нотацію).
Генералізація
Узагальнення або генералізація – це відношення між двома сутностями, одна з яких є окремим випадком
(спеціалізацією) іншої. Тобто це є направлене відношення між більш загальним класом і специфікованим
класом. Генералізація в UML 2 має властивість наслідування, це означає, що клас який наслідує більш
загальний клас, також наслідує його структуру та поведінку.
Узагальнення між класом C та його дочірнім класом 1C може бути представлено за допомогою
твердження включення в ALCQI, а саме у вигляді 1C ⊑C. Ієрархія класів, як показано на рис. 1, може бути
представлена твердженнями 1C ⊑ C,…. nC ⊑ C.
Рис. 1. Ієрархія класів
Кожна генералізація в специфікації UML 2 має дві основні властивості: це покриття, що може бути
повним (complete) або неповним (incomplete); та властивість перетину, яка може бути з перетином
(overlapping) або без перетину (disjoint).
Повнота означає, що кожен екземпляр, більш загального класу, повинен належати принаймні до одного
із специфікованих класів.
Перетин визначає, чи можуть специфіковані класи мати спільні екземпляри, тобто у випадку наявності
хоча б одного спільного екземпляру говорять про генералізацію з перетином.
В UML 2.x кожна генералізація є неповною. Відмінність між UML 2.x та UML 2.5 полягає у відсутності
та наявності перетину відповідно. Тому, якщо ми хочемо досягнути відсутності перетину, то обмеження класів
1C …. Cn, що не перетинаються, може бути змодельоване як Ci⊑¬ Cj, де 1≤i<j≤n. Водночас як повнота
узагальнення може бути виражена як C ⊑ 1C ⊔…. ⊔ nC (табл. 2).
Інтелектуальні інформаційні технології
215
Таблиця 2
UML Дескриптивна логіка Абстрактний синтаксис OWL
class Class Model
C
D
E
( E⊔C )⊑D owl:unionOf
C
¬C owl:complementOf(C)
R: C
∀R . C owl:allValuesFrom
class Domain Model
C
- R: D
C⊑∀R . C C subClassOf Restriction on
allValuesFrom
class Domain Model
C
- R: D [i..j]
Мультиплікативне відношення [i..j] для
ролі R класу формалізуються наступним
чином
C⊑(≥iR.D)⊓(≤jR.D) Коли j рівно
*, то ми відкидаємо другий конюкт.
Коли мультиплікативне відношення має
вигляд [0...*], тоді опускають ціле
твердження.
Коли мультиплікативне відношення має
вигляд [1...1], то твердження матиме
наступний вигляд C⊑∃R.⏉⊓(≤1R).
owl:restriction(R maxCardinality(n))
owl:restriction(R minCardinality(n))
R: C
{ }existential restriction
∃R .C owl:restriction(R
someValuesFrom(C))
class Account
C
«enum»
- a
C ( a ) owl:hasValue
class Account
- R [1..n]
≤n R restriction(R maxCardinality(n))
class Domain Model
A BR
0..n
Направлена асоціація
A⊑B⊓≤n R A subClassOf Restriction on R
maxCardinality N
Інтелектуальні інформаційні технології
216
Закінчення табл. 2
UML Дескриптивна логіка Абстрактний синтаксис OWL class Account
- R [n..*]
≥n R owl:restriction(R minCardinality(n))
class Line Styles
Customer
Order
Auto-routing style tries
to find the shortest
path using only vertical
and horizontal
segments.
Custom style allows
you freedom to add
line points (bends) and
route the connector
wherever you wish.
Direct style takes
the shortest route
from A to B.
Receiv ed
Ordered
Rejected
Unpacked
Bezier style allows you
to create curved
connectors.
Orthogonal style allows
you more freedom
than Auto-routing while
still keeping all your
segments vertical and
horizontal.
Orthogonal style can
also have rounded
corners.
Order
Internet Order Shop Front Order
Component1
Component2
Component3
This is tree style
vertical.
This is tree style
horizontal
Node1
Node2
Node3
This is lateral vertical
style useful for
displaying hierarchies of
requirements and other
elements and
organization charts.
Artifact1
Artifact2 Artifact3
And this is lateral
horizontal.
TREE STYLES
There are four different tree
sty les to choose from...
To set the line sty le for
a connector, right-click
it and use the "Line
Sty le" sub-menu.
Class3
- a: int
- dfgdf: int
- fdg: int
- R1 - R2
R 1⊑R 2 rdfs:SubPropertyOf(R1 R2)
R 1≡R 2 owl: EquivalentProperties(R1. R2)
class Domain Model
B
A
R1R2
∃A .R 1≡B . R - 2 owl:inverseOf
class Domain M...
A
R
0..1
A⊑A≤1R owl:FunctionalProperty
Розглянемо більш детально деякі конструкції. Для досягнення більшої повноти відображення ми
вводимо додаткові нотації в UML (табл. 3).
Таблиця 3
Нотація Назва нотації Опис нотації
C
Заперечення існування класу Нотація означає, що даний
клас в предметній області, яка
моделюється, існувати не
може.
R: D
Доповнення Нотація позначає існування
властивості певного типу.
R: D
A
Залежність.
Доповнення класу
Означає, що клас А має
властивість R типу D.
Інтелектуальні інформаційні технології
217
Асоціації з асоціативним класом
Подібно до того, як об’єкти класу можуть бути записані за допомогою атрибутів, асоціативне
відношення також може мати атрибути. UML дозволяє представляти інформацію такого характеру за
допомогою класів асоціацій. Клас асоціації – це асоціація, яка одночасно є класом. Подібно зв’язкам
асоціації, екземпляри класу асоціації мають індивідуальність, пов’язаної з тими об’єктами, між якими вони
проводяться. Подібно звичайним класам, класи асоціацій можуть мати атрибути та операції , і брати участь в
асоціаціях.
Для представлення мультиплікативного відношення A з асоціативним класом (рис. 2.), необхідно
використати якісне обмеження кардинальності ролі (qualified number restrictions).
class InformationObjectModel
InformationObject
«Property, objectProperty»
+ protocol {readOnly}
Collection
is Member Of (IMO)
Metadata
is Described By (IDB)
Metadata Collection
Annotation
is Annotated By (IAB)
Annotation Collection
WebResource WebServ ice
«objectProperty»
- operations
NonInformationResource
SemanticWebURI
«Property»
+ simplicity
InformationResource
Resource
+ identifier: URI
- representations
A
URI
- scheme: char = http:
http://www.w3.org/TR/cooluris/
Simplicity
Stability
Manageability
BinaryRelationship
«enumeration»
Protocols
HTTP
FTP
HTTPS
«enumeration»
Operations
GET
POST
PUT
DELETE
Class6
«enumeration»
Media
HTML
JSON
XML
Class5
C1 C2
A
redirectsTo
1..*
IMO
+r1
min1..max1
+r2
min2..max2
*
IMO
*
SubsetOf
SubClass
isIdentifiedBy
303 redirect
«realize»
*
IMO
*
HasPart
IMO
*
IMO
*
SubCalass
SubClass
+target
is related
+source
HasPart
IMO
*
Рис. 2. Асоціації з асоціативним класом
Кожен екземпляр класу 1C асоційований з екземплярами класу 2C , через асоціативний клас A . При
цьому клас A може мати певні атрибути.
Відношення через асоціативний клас може мати n-арність на полюсах. В такому випадку, ми отримуємо
відношення:
,
.
Розглянемо випадок, коли ми маємо асоціативне відношення між класами A та D через клас C з
асоціацією R (рис. 3).
class Domain Model
A D
C
R
Рис. 3. Відношення з асоціацією R
В цьому випадку, щоб побудувати співставлення на ДЛ, є певні складності. Така діаграма класів UML є
насправді окремим випадком n-арного відношення. В ДЛ SHOIQ немає конструкторів для моделювання
n-арного відношення, тому вводять додатковий клас С’ (рис. 4), який дає змогу будувати тільки бінарні
відношення між додатковим класом та зв’язаними класами.
На ДЛ SHOIQ даний запис буде представлений наступним чином:
.
Інтелектуальні інформаційні технології
218
Рис. 4. Моделювання n-арного відношення
Асоціації в UML
Кожні бінарні асоціації (чи агрегації) між класами 1C і 2C мають вигляд (рис. 5).
Рис. 5. Бінарна асоціація
Такі асоціації можуть бути трансформовані до твердження дескриптивної логіки через використання
атомарної ролі A разом з твердженням включення:
.
Мультиплікативність асоціативного відношення A формалізується наступними твердженнями:
Кожний екземпляр концепту C1 зв’язаний через атомну роль A з, принаймні, min1 і не більше max1
екземплярами концепту C2:
C1⊑(≥min1A)⊓(≤max1A).
Кожний екземпляр концепту C2 зв’язаний через атомну роль з, принаймні, min2 і не більше max2
екземплярами концепту C1.
.
Слід відмітити, що агрегація в UML – це особливий вид бінарної асоціації без асоціативного класу.
Висновок
В роботі розглянуто проблематику верифікації діаграм класів UML за допомогою відображення до OWL.
В даному підході також передбачена можливість зворотного відображення. Ця методика надає можливість
верифікувати діаграму класів UML через механізми судження, що суттєво розвинуті в дескриптивній логіці.
Представлене відображення не є однозначним, в наслідок того, що UML була з самого початку націлена на
визначення формальних специфікації для розробки ПЗ з властивістю гнучкості та простотою нотацій. Так
гнучкість та неоднозначність призвела до наслідків важкості автоматизованого аналізу діаграми класів UML.
Зокрема, асоціація в UML описує набір кортежів, чиї значення відносяться до типу екземплярів. Іншими
словами, асоціація специфікує семантичні відношення, які можуть виникнути між екземплярами певних типів.
За замовчуванням, асоціація є ненаправленою, проте при нотаціях може бути використаний (OMG, 2010)
символ %, який просто визначає напрямок читання і допомагає інтерпретувати асоціацію. І окремо виділяються
направлені асоціації, в яких чітко вказується напрямок відношень між класами. Такі слабкі формальні
відмінності не дозволяють побудувати однозначне та повне відображення.
1. Alotaibi S. 'The 4th Saudi International Conference' // Semantic Web Technologies for Digital Libraries: From Libraries to Social Semantic
Digital Libraries (SSDL), Over Semantic Digital Libraries (SDL)., Manchester. 2010.
2. Berardia, , Calvanese, D. and De Giacomo, G. 'Reasoning on UML class diagrams', Artificial Intelligence. – 2005. – Vol. 168, N 1–2.
P. 70–118.
3. Berners-Lee, T. (2009) Linked Data, [Online], Available: HYPERLINK "http://www.w3.org/DesignIssues/LinkedData.html"
http://www.w3.org/DesignIssues/LinkedData.html [Jul 2015].
4. Brockmans S., Volz R., Eberhart A. and Löffler. 'Visual modeling of owl dl ontologies using uml', in The Semantic Web – ISWC 2004, Springer.
Інтелектуальні інформаційні технології
219
5. Cali A., Calvanese D., De Giacomo G. and Lenzerini M. 'A Formal Framework for Reasoning on UML Class Diagrams' // in Foundations of
Intelligent Systems, Springer Berlin / Heidelberg. – 2002.
6. Cranefield and Purvis 'Uml as an ontology modelling language' // In Proceedings of the Workshop on Intelligent Information Integration, 16th
International Joint Conference on Artificial Intelligence (IJCAI-99). – 1999.
7. Daniela B., Diego C. and Giuseppe D. 'Reasoning on UML class diagrams' // Artificial Intelligence. – 2005. – Vol. 168, N 1–2.
8. Dereferencing HTTP URIs (2007), Oct, [Online], Available: HYPERLINK "http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-
31/HttpRange-14" http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14.
9. Fielding R.T. (2005) [httpRange-14] Resolved, Jan, [Online], Available: HYPERLINK "http://lists.w3.org/Archives/Public/www-
tag/2005Jun/0039.html" http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html.
10. Linked Data (2015), Jul, [Online], Available: HYPERLINK "http://www.w3.org/standards/semanticweb/data"
http://www.w3.org/standards/semanticweb/data.
11. Object Management Group (2009) Documents associated with Ontology Definition Metamodel (ODM) Version 1.0, May, [Online], Available:
HYPERLINK "http://www.omg.org/spec/ODM/1.0/" http://www.omg.org/spec/ODM/1.0/ [Jul 2015].
12. OMG (2010) 'OMG Unified Modeling LanguageTM (OMG UML), Superstructure' Object Management Group, Available:
http://www.omg.org/spec/UML/2.3/Superstructure.
13. Simmonds J. (2003) Consistency Maintenance of UML Models with Description Logics, Brussel.
14. Sturm A., Balaban M. and Maraee A. 'Management of Correctness Problems in UML Class Diagrams Towards a Pattern-Based Approach',
International Journal of Information System Modeling and Design. – 2010. – Vol. 1, N 4. – P. 24–47.
15. Sure Y. and Studer. 'Semantic Web technologies for digital libraries', Library Management. – 2005. – Vol. 4/5, N 26. – P. 190–195.
16. Thalheim B. 'Foundations of entity-relationship modeling', Annals of Mathematics and Artificial Intelligence. – 1993. – Vol. 7, N 1–4,
Available: 10.1007/BF01556354.
17. Волович М.Е., Дерюгина, О.А. 'Верификация UML программных систем', Cloud of Science. – 2015. – Vol. 2, № 1, Available: 2409-031Х.
18. Макгрегор Д., Сайкс Д. Тестирование объектно-ориентированного программного обеспечения. – 2002, ТИД "ДС".
References
1. Alotaibi, S. (2010) 'The 4th Saudi International Conference', Semantic Web Technologies for Digital Libraries: From Libraries to Social
Semantic Digital Libraries (SSDL), Over Semantic Digital Libraries (SDL)., Manchester.
2. Berardia, , Calvanese, D. and De Giacomo, G. (2005) 'Reasoning on UML class diagrams', Artificial Intelligence, Vol. 168, N 1–2, P. 70–118.
3. Berners-Lee, T. (2009) Linked Data, [Online], Available: HYPERLINK "http://www.w3.org/DesignIssues/LinkedData.html"
http://www.w3.org/DesignIssues/LinkedData.html [Jul 2015].
4. Brockmans, S., Volz, R., Eberhart, A. and Löffler, (2004) 'Visual modeling of owl dl ontologies using uml', in The Semantic Web – ISWC
2004, Springer.
5. Cali, A., Calvanese, D., De Giacomo, G. and Lenzerini, M. (202) 'A Formal Framework for Reasoning on UML Class Diagrams', in
Foundations of Intelligent Systems, Springer Berlin / Heidelberg.
6. Cranefield , and Purvis, (1999) 'Uml as an ontology modelling language', in In Proceedings of the Workshop on Intelligent Information
Integration, 16th International Joint Conference on Artificial Intelligence (IJCAI-99.
7. Daniela, B., Diego, C. and Giuseppe, D. (2005) 'Reasoning on UML class diagrams', Artificial Intelligence, Vol. 168, N 1–2.
8. Dereferencing HTTP URIs (2007), Oct, [Online], Available: HYPERLINK "http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-
31/HttpRange-14" http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14 .
9. Fielding, R.T. (2005) [httpRange-14] Resolved, Jan, [Online], Available: HYPERLINK "http://lists.w3.org/Archives/Public/www-
tag/2005Jun/0039.html" http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html .
10. Linked Data (2015), Jul, [Online], Available: HYPERLINK "http://www.w3.org/standards/semanticweb/data"
http://www.w3.org/standards/semanticweb/data .
11. Object Management Group (2009) Documents associated with Ontology Definition Metamodel (ODM) Version 1.0, May, [Online], Available:
HYPERLINK "http://www.omg.org/spec/ODM/1.0/" http://www.omg.org/spec/ODM/1.0/ [Jul 2015].
12. OMG (2010) 'OMG Unified Modeling LanguageTM (OMG UML), Superstructure' Object Management Group, Available:
http://www.omg.org/spec/UML/2.3/Superstructure.
13. Simmonds, J. (2003) Consistency Maintenance of UML Models with Description Logics, Brussel.
14. Sturm, A., Balaban, M. and Maraee, A. (2010) 'Management of Correctness Problems in UML Class Diagrams Towards a Pattern-Based
Approach', International Journal of Information System Modeling and Design, Vol. 1, N 4, P. 24–47.
15. Sure, Y. and Studer, (2005) 'Semantic Web technologies for digital libraries', Library Management, Vol. 4/5, N 26, P. 190–195.
16. Thalheim, B. (1993) 'Foundations of entity-relationship modeling', Annals of Mathematics and Artificial Intelligence, Vol. 7, N 1–4,
Available: 10.1007/BF01556354.
17. Volovich М.Е. and Deryugina O.A. (2015) 'Verification of UML software systems ', Cloud of Science, Vol. 2, N 1, Available: 2409-031Х.
18. Makgregor D. and Sayks D. (2002) Testing Object-Oriented Software, ТID "DS".
Про автора:
Новицький Олександр Вадимович,
молодший науковий співробітник.
Кількість наукових публікацій в українських виданнях – 15.
Кількість наукових публікацій в іноземних виданнях – 4.
Індекс Гірша – 4.
http://orcid.org/0000-0002-9955-7882.
Місце роботи автора:
Інститут програмних систем НАН України,
03181, Київ-187, проспект Академика Глушкова, 40.
Тел.: (067) 44 5 173.
E-mail: alex.googl@gmail.com
mailto:alex.googl@gmail.com
|