Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи

Тема дослідження роботи - багатоаспектна атестація та пошук програмних компонент в онтологічній системі (ОС). Запропоновано метод використання онтологій аспектів для автоматизованого керування зміною стратегії встановлення релевантності під час пошуку програмних компонент в ОС....

Повний опис

Збережено в:
Бібліографічні деталі
Дата:2007
Автор: Поляничко, С.Л.
Формат: Стаття
Мова:Українська
Опубліковано: Інститут програмних систем НАН України 2007
Теми:
Онлайн доступ:https://nasplib.isofts.kiev.ua/handle/123456789/280
Теги: Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи / С.Л. Поляничко // Пробл. програмув. — 2007. — N 1. — — Бібліогр.: 11 назв. — укp.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine
_version_ 1860086482441601024
author Поляничко, С.Л.
author_facet Поляничко, С.Л.
citation_txt Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи / С.Л. Поляничко // Пробл. програмув. — 2007. — N 1. — — Бібліогр.: 11 назв. — укp.
collection DSpace DC
description Тема дослідження роботи - багатоаспектна атестація та пошук програмних компонент в онтологічній системі (ОС). Запропоновано метод використання онтологій аспектів для автоматизованого керування зміною стратегії встановлення релевантності під час пошуку програмних компонент в ОС.
first_indexed 2025-12-07T17:19:55Z
format Article
fulltext Інформаційні системи © С.Л. Поляничко, 2007 ISSN 1727-4907. Проблеми програмування. 2007. № 1 61 УДК 681.3. С.Л. Поляничко КЕРУВАННЯ СТРАТЕГІЯМИ ЗМІНИ РЕЛЕВАНТНОСТІ ПРИ ПОШУКУ ПРОГРАМНИХ КОМПОНЕНТ В РЕПОЗИТОРІЇ ОНТОЛОГІЧНОЇ СИСТЕМИ Тема дослідження даної роботи - багатоаспектна атестація та пошук програмних компонент в онтологі- чній системі. Пропонується метод використання онтологій аспектів для автоматизованого керування зміною стратегії встановлення релевантності при пошуку програмних компонент в онтологічній сис- темі. Одна з базових проблем у побудові інформаційно-пошукових систем (ІПС) - проблема визначення критеріїв релевант- ності образів ресурсів у процесі інформа- ційного пошуку. Користувач формулює свою інформаційну потребу у вигляді по- шукового виразу, який прийнято називати пошуковим запитом (ПоЗ), а система ви- конує запит шляхом співставлення відпо- відного пошукового виразу зі специфікаці- ями ресурсів в ІПС, які є образами ресурсів (ПоБ). Форма представлення такого ПоЗ зафіксована для конкретної ІПС. При первинному формулюванні за- питу пошук ресурсів може дати резуль- тати, які не відповідають потребам корис- тувача ІПС. У випадку занадто конкрет- ного ПоЗ системою не буде знайдено жод- ного ПоБ ресурсу, який відповідає ПоЗ. Іншим граничним випадком є такий, коли у відповідь на узагальнений запит корис- тувача система вкаже йому на таку мно- жину релевантних ПоЗ ресурсів, потуж- ність якої не дозволяє здійснити якісний відбір ресурсів. У обох випадках виникає потреба виробити ефективні стратегії змі- ни первинного пошукового виразу шляхом встановлення спеціального критерію реле- вантності між ПоЗ та ПоБ. Актуальна задача сучасних ІПС - по- будова бази знань щодо ресурсів на основі онтологічних моделей предметних облас- тей [1]. Переважний напрямок таких до- сліджень - застосування онтологій як за- собу керування при впровадженні різних послуг в ІПС [2]. Онтологія, або понятійна база, визначає не тільки узгоджену, уніфі- ковану термінологію, якою повинні корис- туватися різні носії інтересів та користу- вачі ІПС, але і відносини між поняттями, фіксує їх інтерпретацію. У нашому випа- дку під інтерпретацією понять або відно- шень будемо розуміти їх неформальні ви- значення або коментарі. Відмінна риса онтологій аспектів - їх використання не тільки для навігації у просторі загальних знань щодо домену предметної області, скільки для форму- вання знань щодо конкретної програмної компоненти в різних аспектах. Репозиторії у складі онтологічної системи [3] націлені на зберігання образів готових програмних компонент та подальше їх використання у нових розробках. У даній роботі пропонується метод використання предметних онтологій для автоматизованного керування стратегіями зміни релевантності за допомогою апарату критеріїв релевантності при пошуку в ре- позиторії. У даній онтологічній системі аспекти представлення знань щодо програмних компонент будуються у відповідності з ме- тодологією, яка набуває статусу стандарту для представлення артефактів програмної інженерії, а саме методологією UML [4]. Такі онтологічні аспекти містять відомості про всі сценарії (роботи), притаманні до- мену, про класи об`єктів, що діють у сце- наріях, визначені для об`єктів функції (ме- тоди), стани та атрибути тощо. Таким чи- ном усі концепти предметних знань, що використовуються, підпорядковуються концептам UML за допомогою передбаче- них для них в UML відношень та стерео- типів. Інформаційні системи 62 У проекті, що розглядається в даній роботі, запропоновано інтегрований про- грамний комплекс, який дозволяє накопи- чити онтології аспектів для опису різних програмних компонент в різних предмет- них галузях. Цей програмний комплекс містить: • графічний редактор онтологій, призначений для первинної побудови та подальшої модифікації онтологій аспектів в рамках окремого домену; • конструктор запитів та образів, призначений для формування ПоЗ та ПоБ компоненти на базі відповідним онто- логічним аспектам; • репозиторій образів компонент; • машина пошуку образу ком- поненти в репозиторії образів згідно по- даному ПоЗ; • сервісні функції, які дозволяють варіювати змінами стратегії релевантності при пошуку за допомогою наперед визна- ченого набору критеріїв релевантності між ПоЗ та ПоБ; • система звітності про резуль- тати пошуку в репозиторії. Зупинимось на особливостях пред- ставлення ПоБ на базі багатьох онтологіч- них аспектах та на апараті критерію реле- вантності, який дозволяє впровадити ефек- тивний пошук у багато аспектній онтоло- гічній системі. 1. Моделювання ПоБ програмної ком- поненти та запиту на її пошук в багатоаспектній онтологічній системі Складність сучасних компонент програмної інженерії вимагає спеціальних підходів для формального опису їх можли- вості та певних прийомів для їх інтеграції у нову розробку. Одним з таких прийомів, на наш погляд досить ефективним, є деко- мпозиція розгляду суцільної проблеми на окремі аспекти, тобто з позицій окремих точок зору або окремих носіїв інтересів. Прикладами різних аспектів, широко за- стосовуваних при розгляді компонент, є їх функціональні властивості, виконавчі по- казники, паспортні дані, показники якості, захищеності, візуальні чи аудіо засоби представлення даних. Аспектне представ- лення дозволяє побудувати для кожного аспекту свою систему навігації при інфор- маційному пошуку. Аспектний підхід представлення знань в галузі програмної інженерії набув широкого вживання як розвиток фасетного підходу. При фасет- ному підході опису ресурсів кожному ви- діленому аспекту буде відповідати своя фасета як частина бази знань домену. У залежності від предметних облас- тей, окремі з названих аспектів можуть, в свою чергу, поділятися на під-аспекти. Аспектний склад онтологічної сис- теми для представлення знань щодо про- грамних компонент наперед визначений для стандартизованого опису кожної ПК в домені. Онтологічна модель аспектів до- зволяє проводити нормалізацію лексики щодо представлених знань, атестацію та пошук компонент в системі. В даній ро- боті представляється модель онтологій аспектів, які побудовані за допомогою концептуальних графів. Такий аспектний опис компонент дозволяє побудувати ша- блон, за допомогою якого атестуються компоненти та зберігаються образи про- грамних компонент. Графічний образ компоненти за допомогою спеціального алгоритму транспонується у векторне тек- стове представлення. У подальшому текс- товий онтологічний багатоаспектний об- раз програмної компоненти транспону- ється в опис на HTML подібній мові та зберігається в спеціальному репозиторії. Такий опис компоненти фіксується за до- помогою спеціальних тегів, кожний з яких відповідає аспектному розділу опису компоненти в онтологічній системі. Вміст окремого тегу- текстовий образ компоне- нти, який побудований за допомогою від- повідного онтологічного аспекту. Склад аспектів домену опису ПК поділяється на ті, що представляють тех- нічні властивості та семантичні властиво- сті. Вбудовані стандартні аспекти дозво- ляють атестувати ПК з точки зору техно- логії інтеграції її в нову розробку (або технології її ревикористання [5]), а саме: Інформаційні системи 63 аспект інтерфейсу, аспект розгортання, аспект реалізації. Ці аспекти є базисом для аспект- ного опису будь-якої ПК. Вони складають інваріант для різних галузей, в яких мо- жуть бути описані різні ПК. Кожна з таких онтологій - аспектів має певну наперед ви- значену структуру. До її особливостей мо- жна віднести таку, що родова частина ко- жного з цих аспектів (ярус метакласифіка- торів) є незмінною при підключені такого аспекту до нового домену. Але змінною частиною є проміжний рівень концептів та нижній рівень концептів – значень, які складають нижні яруси онтологічної ієра- рхії. Окрім вбудованих стандартних ас- пектів до атестації компоненти можуть бу- ти підключені аспекти, які мають різне представлення в різних доменах та які до- зволяють представити семантику та інди- відуальні особливості кожної компоненти. Це такі: аспект типізації, семантичний ас- пект, аспект паспортних даних, аспект ро- лей. Особливістю цих аспектів (особ- ливо семантичного аспекту) є те, що вони змінюються при підключенні до нового домену повністю ( разом зі своєю родовою (скелетною) частиною ). У процесі інженерії домену для ате- стації програмних компонент для кожного з наведених аспектів були наперед визна- чені базові родові концепти (які породжу- ють скелетні гілки), основний склад кон- цептів проміжного рівня, типи відношень, які характерні для кожного з цих аспектів та типи варіантності в кожному аспекті. Для прикладу наведемо особливості онто- логії аспекту ролей. Джерела. Джерелами для атестації компоненти в цьому аспекті можуть бути специфікатори діаграм сценаріїв UML або ER-діаграми. Родові концепти для скелетних гілок: - ролі; - сценарії; - процеси; - стани; - вимоги. Правила побудови онтології ас- пекту ролей. При побудові такого аспекту виходимо з наступних положень: - кожний стан об’єкта визначається за допомогою значень його атрибутів; - кожний стан може визначатися своїм зв’язком з класом та з атрибутами цьо- го класу, (або з атрибутами, які на- слідуються від іншого класу); - кожний об’єкт може виконувати роль; - кожний об’єкт може мати операції; - стани можуть мати переходи, причому перехід для стану змінює його атри- бути; - стани можуть бути складними та скла- датися з інших прости станів та пере- ходів зі стану в стан; - перехід зі стану в стану асоціюється з викликом операції; - стан може мати суперстан та підстан (причому вони наслідують атрибути). Аспект ролей має базові відно- шення: - <виконує> “роль”; - <є> “процесом”; - <є> “сценарієм”; - <має> “ціль”; - “процес” <має> “підпроцес”; - <відповідає> “вимогам”; - <виконує> “дію”; - “процес” <підтримує> “дію”; - “дія” <має> “вхід”; - “дія” <має> “задачу”; - “дія” <має> “вихід”; - <виконується на> “класі”; - <виконується на> “підкласі”; - “стан” <має> “атрибут стану”; - “атрибут стану” <має> “значення”; - “стан” <асоціюється з> “класом”; - <має> “опрацію”; - “стан” <має> “перехід”. Варіантність аспекту ролей. Варіа- нтність компонент у кожному аспекті представляється за допомогою галуження онтологічної ієрархії. Типи галуження он- тології для відображення варіантності в різних аспектах можуть бути обов’язкові, необов’язкові або альтернативні. Для кож- ного типу аспекту встановлюється свій тип варіантності [6]. До варіантності аспекту ролей можна віднести наступні: Інформаційні системи 64 • процес може змінюватися за- вдяки різним цілям (варіюється набір цілей); • кожна з цiлей компоненти дося- гається різними сценаріями (ва- ріюється набір сценаріїв); • сценарії можуть працювати з рі- зними об’єктами та класами (ва- ріюється набір класів). Аспект вважається знаним у репо- зитарії, якщо у його базу знань входить відповідна аспекту онтологія. Вищеперелі- чені аспекти вважаються обов`язковими для роботи репозитарію. Це означає, що ПОБ, як і ПОЗ складається з фрагментів, кожен з яких може бути атестаційним або пошуковим виразом відносно одного із знаних аспектів, а між наявними фрагмен- тами вважається встановленим відношення диз`юнкції. У процесі багатоаспектної атестації (анотування) кожний компонент представ- ляється в домені предметної галузі за до- помогою наступних знань: • сукупності аспектів, за якими він атестується в домені; • родових концептів, які визначають гілки в аспекті, значущі для атестації компонента; • концептів проміжного рівня, які атестують його за кожним аспектом; • значень для атестаційних концеп- тів проміжного рівня; • відношень, між атестаційними кон- цептами; • тлумачень атестаційних концептів; • груп синонімів для атестаційних концептів; • атрибутів приналежності до аспе- кту в домені; • коментарів; • графічній візуалізації образу ком- понента в окремому аспекті; • текстового образу компонента; • HTML документа, який відповідає багатоаспектному текстовому та графіч- ному образу компонента; • URL посилань до документів, які можуть розширити інформаційне пред- ставлення компонента в системі. Для представлення власне онтоло- гій аспектів обрано форму концептуальних графів. Для концептуальних графів про- блема встановлення контекстної відповід- ності зводиться до процесу керованого он- тологією пошуку на графових даних. Кон- цепти та відношення вважаються порів- нянні, якщо онтологія демонструє, що між ними встановлено зв’язок. Разом з цим ви- користовується словникова підтримка он- тології, тобто вузли концептуального гра- фа прив’язуються до відповідних лек- сичних одиниць домену. При цьому під- тримуються відповідні семантичні обме- ження. Окрім суто онтологічних атрибутів (назва концепту, назва відношення, тлума- чення концепту) вершині графа відповідає набір графічних атрибутів як розмір, фо- рма, місце та ін. Кожній дузі графа відпо- відають наступні атрибути – стиль дуги, які визначають стандартні відношення в онтології та мітка дуги, яка відповідає на- зві нестандартного відношення в онтології домену. Ці графічні атрибути можуть оби- ратися для створення дружнього інтер- фейсу згідно персональним смакам корис- тувача або встановлюватися системою і є засобами візуалізації онтології. Підсумовуючи вищеописане, мо- жемо вважати наступне: • багатоаспектна база знань про про- грамні компоненти представляється “лі- сом” дерев – онтологій. Такий ліс дерев онтологій будемо вважати онтологічною моделлю домену “можливі компоненти певної предметної області” при чому ко- жна із онтологій розглядається як концеп- туальна модель відповідного аспекту ; • кожне з дерев “лісу” відповідає од- ному з аспектів представлення знань щодо компонента; • кожній вершині обов’язково відпо- відає дескриптор, який має своє тлу- мачення в словнику домену; • існує виділена вершина, яка є вхо- дом до представленого графом аспекту. Причому кожна вершина графа повинна бути досяжною із цієї вхідної вершини (кореня аспекту). Інформаційні системи 65 На фазі анотування – побудови ПОБ ресурсу вершини та дуги онтології обра- ного аспекту зазначаються (або “активу- ються”) користувачем за допомогою гра- фічного інтерфейсу, і в подальшому трансформуються в атестаційний розділ ПОБ щодо відповідного ресурсу, представ- лений у HTML-подібній мові. Подальшими етапом методики стає алгоритм трансформування багатоаспект- ного ПоБ компоненти в текстовий опис компоненти на HTML подібній мові опису компоненти. В такому HTML представ- ленні за допомогою HTML маркерів виді- ляються розділи, які відповідають назвам аспектів. При цьому ім`я розділу є ім`ям аспекту. Підрозділам аспекту відповідають спеціальні теги [7]. Треба зазначити, що HTML структура дозволяє ввести ієрархію включених один в одного тегів, тим самим підтримати ієрархію онтологічних мета- класифікаторів. Вміст тегів – ПОБ компо- ненти в поточному підрозділі аспекту, яке будується за правилами мови онтологіч- ного опису та складається з концептів се- реднього та нижнього рівнів онтологічної ієрархії та їх значень. Таким чином активована частина графа онтології трансформується в граф ПоБ, причому для кожного поняття збері- гається семантична відповідність концепту онтології у рамках домену. Саме така фун- кція використовується і при формуванні пошукового образу компонента. Перед трансформуванням здійснюється семанти- чна валідація графа ПоБ компонента на ба- зі словника онтології. Надалі ПоБ компо- ненти запам’ятовується на спеціальній мо- ві опису пошукового образу програмної компоненти МОК, яка детально описана в [2]. Тобто стверджуємо, що інформа- ційна модель компонента в домені – це йо- го багатоаспектний пошуковий образ, який має семантичну підтримку в онтологічній системі. Багатоаспектний образ компонен- та відповідно представляється конкатена- цією атестаційних розділів по кожному, щонайменше одному, аспекту в онтологіч- ній моделі домену предметної області. Запити на пошук адекватного вимо- гам користувача компонента будується на базі трьох елементів. Перший елемент – онтологічні образи, що співставляються (ПоБ та ПоЗ), другий – локалізація (місце співставлення, тобто всатновлення поточ- ного аспекту для проведення співстав- лення), третій – умови співставлення (пре- дикати співставлення). У нашому випадку в ролі першого елемента виступає запит (ПОЗ компоне- нти) – це граф, вершини якого пов’язані функцією з концептами онтології. Побудо- ваний за цим графом кортеж співставля- ється з аналогічно побудованими корте- жами в репозиторії ПК. Найдені відповідні кортежі називають образами компонент (ПОБ компоненти). Місце, де проводиться співставлення в онтології, визначається набором аспектів, які фігурують в ПОЗ. За кожним аспектом в ПОЗ здійс- нюється операція трансформування графа запиту в пошуковий кортеж. Співстав- лення з кортежами в репозиторії прово- диться поаспектно (тобто співставляється частина кортежу, яка відповідає поточному аспекту, з відповідною частиною кортежу в ПОБ, який у даний момент співставля- ється) Позначимо операцію трансформу- вання графа запиту GПОЗ ⊆ GA = (VА,DA) (граф аспекту онтології домену) у пошуко- вий кортеж XПОЗ як FПОЗ: GПОЗ�XПОЗ, де GПОЗ=(VПОЗ ⊆ VА, DПОЗ ⊆ DA, α) - поміче- ний граф (граф запиту), VПОЗ, DПОЗ - мно- жина активованих вершин та дуг в за- питі, а XПОЗ - кортежу запиту на мові МОК (або пошуковий кортеж), який представляє опис компоненти. FПОЗ – функція, яка по- будована на базі функції α з обмеженою областю дії. α – це функція відповідності вершини графа концепту онтології . Оскільки підхід до побудови ПоЗ та ПоБ аналогічні наведемо тільки правила побудови багатоаспектного ПоБ на мові МОК. Побудова кортежу багатоапсектного образу компоненти на мові МОК: 1. Опис компоненти на МОК пред- ставляє комбінацію ПоБ компоненти за декількома аспектами. Інформаційні системи 66 2. Текст опису на МОК починається з назви компоненти та домену, в якому ця компонента атестується. 3. Опис компоненти на МОК має декілька розділів, кожний з яких відпові- дає аспекту. Опис за кожним аспектом по- чинається з назви аспекту та після двокра- пки векторний опис відповідного онтоло- гічного фрагменту. 4. Назвам тегів на МОК відповідає назва концептів онтології верхнього рівня ( в графі родові вершини породжують гі- лки аспекту, тобто це вершини другого рі- вня ієрархії графа). 5. Вкладені теги можуть фігурувати в опису та представляти також верхній рівень родових концептів. 6. В опис ПоБ, відповідний компо- ненті в поточному аспекту, вноситься век- тор концептів, які відповідають активова- ним вершинам графа ПоБ. Послідовність включення концептів до тегу опису аспе- кту зумовлено алгоритмів обходу графа в ширину. 7. Означення. Відношення, яке від- повідає дузі графа, яка поєднує дві активо- вані вершини графа назвемо активованим відношенням ПоБ. Також до вектору кон- цептів можуть бути вбудовані відповідні назви відношень між концептами (також у послідовності обходу графа в ширину), якщо відношення поєднує активовані для ПоБ відношення. 8. Сформований таким чином опис компоненти на мові МОК зберігається у відповідному розділі репозиторія системи. 9. Зазначимо, що при виконанні обов’язкових процедур, які на протязі ево- люціонування домену будуть підтримувати коректність та цілісність напрацьованих знань в репозиторії системи, в будь- який момент часу образ компоненти, який збе- рігається в репозиторії, може бути візуалі- зовано. Під процесом візуалізації ПоБ компоненти будемо розуміти процес акти- вації у модифікованому (за вимогами ево- люціонування домену в часі) графі ПОБ відповідних вершин. 10. Засіб візуалізації ПоБ значно розширює можливості візуального співс- тавлення графічних образів компонент та підтримує прийняття рішення про доціль- ність використання тієї чи іншої компоне- нти в цільовій розробці. 2. Розширений апарат критеріїв релевантності в онтологічній системі Задача співставлення [8] може ста- витися як співставлення пошукового за- питу і пошукового образу ПК з метою ви- бору останніх або як співставлення пошу- кових образів двох ПК з метою порівняння їх властивостей. Одна із таких методик за- пропонована у [9 - 11] для обмежених ти- пів ПК ( функції, які співставляються за типами вхідних та вихідних параметрів). Нагадаємо, що для співставлення використовуються наведені далі структури. До них відносимо: 1. пошуковий образ ПК (ПоБ), який представлено як конкатенацію фрагментів, кожен з яких визначає певний аспект та перелік відповідних йому дескрипторів. Впорядкованість переліку концептів у фра- гменті аспекту та послідовність фрагментів аспектів не визначається. Для атестації рі- зних ПК використовується довільний склад аспектів; 2. пошуковий запит (ПоЗ), структура якого ідентична структурі пошукового об- разу, склад відображених у ньому аспектів також довільний; 3. набір онтологій О(Аi), відповідних тим аспектам Аі, які підтримує ПК. Процес співставлення відбувається як поаспектне порівняння відповідних розді- лів ПоЗ та ПоБ, а саме: 1. Перевіряється наявність аспектів, за- значених у ПоЗ, у складі аспектів ПоБ (відповідних аспектів). 2. Для знайдених відповідних аспектів перевіряється наявність концептів ПоЗ (та значущих відношень) у складі ПоБ. Позначимо пошуковий образ компо- ненти як Dпк =∩D(Ai), де 1<=i<=N, Ai⊆O(D). Тут Dпк – пошуковий образ однієї ПК, Ai – аспект, по якому атестується ПК, D(Ai) - множина концептів, відповід- них Ai, Інформаційні системи 67 O(D) – множина всіх онтологій аспе- ктів в домені. Відповідно пошуковий запит подамо так: Q=∩Q(Aj), де 1<=j<=k, Aj⊆O(Ai), а Q(Aj) – множина концептів відповідних Аj. Тоді будемо позначати співставлен- ням Q R CПК пошукового образу ресурсу СПК з пошуковим запитом Q : де R – предикат співставлення (кри- терій релевантності). R:Q,СПК→bool, R = ∩Rj, де 1<=j<=k, де k – кількість ас- пектів, за якими був побудований пошуко- вий запит Q, а Rj - предикат співставлення за аспектом Aj. Тобто при створенні пошукового об- разу шукач повинен починати атестацію з того аспекту, який він вважає найзначні- шим для пошуку. І потім поступово пере- ходити к менш значним за його розумін- ням. Пошук точно релевантних запиту ре- сурсів може не дати результатів. Тоді за- стосовуються стратегії послаблення крите- рію релевантності. Підхід багатоаспектної атестації ПК при побудові ПоЗ та ПоБ дозволяє розши- рити коло співставлень з метою виявлення адекватних ПК в репозиторії. Для прове- дення найбільш результативного пошуку адекватної вимогам ПК вводяться різні за типом предикати ослаблення точного спі- вставлення. Кожний з таких предикатів прислуговує для проведення послабленого співставлення між побудованим користу- вачем пошуковими образами та пошуко- вим запитом. У роботі оговорюються під- ходи до побудови пошукового запиту в си- стемі з використанням комбінації різних за типом предикатів з метою підвищення ефективності пошуку в репозиторії. Типові прийоми послаблення або по- силення критеріїв пошуку в сучасних ІПС – це скорочення або розширення пошуко- вих умов , що, як правило, виконується вручну користувачем. Онтологічний прин- цип керування роботою репозиторію надає можливості обирати стратегії зміни крите- ріїв релевантності, керуючись базою знань репозиторію, зокрема тими відношеннями, які підтримуються онтологіями аспектів. При цьому для ряду стратегій змін пошу- кові вирази можуть корегуватися автома- тично. Серед таких визначено стратегії по- слаблення критеріїв релевантності, до яких може бути віднесено зміна аспектів, за якими ведеться пошук, зміна набору концептів, зміна синонімів на канонічні терміни в словнику онтології, або навпаки, зміна стратегії побудови ПоЗ (вказування тільки родові вершини або значення для встановлення релевантності). До критеріїв, які дозволяють посилити співставлення віднесемо наступні введення до предикату співставлення за специфічним відношен- ням, введення конкретизації (тобто пошук тільки серед нащадків вказаних у запиті родових концептів), додавання до атеста- ції нових аспектів, додавання до атестації нових концептів. Означення. Будемо називати співста- влення за одним аспектом простим співс- тавленням. Означення. Відповідно, співстав- лення за декількома аспектами назвемо складним. Зрозуміло, що декілька простих співставлень складають одне складне спі- вставлення. Наведемо в таблиці перелік основ- них послаблених та підсилюючих преди- катів співставлення. Для кожного визна- чимо предикатні символи і зміст. Зазначимо, що на практиці послаб- лення може здійснюватися вибірково за аспектами. Тобто складний предикат може включати декілька різних простих послаб- лених предикатів. Крім вище зазначених типів предика- тів послаблення точного співставлення можуть бути введені предикати, що є спе- цифічними для окремих аспектів і не мо- жуть використовуватися для інших. Різні варіанти трансформацій наведе- них предикатів відповідають ряду обме- жень пошукового запиту, реалізація яких надасть більш релевантні ПК. Будемо на- зивати таке ітераційне співставлення трансформаційним. Такий трансформаційний апарат мо- же використовуватися з метою виявлення груп компонентів, придатних для повтор- Інформаційні системи 68 ного їх використання, аналізу, про- глядання, а також з метою фільтрації бази знань домену та репозиторія образів ком- понент. Також бачиться перспективним використання різних типів предикатів спі- вставлення для структуризації бібліотеки з метою створення навігаторів прискореного пошуку. Зазначимо, що апарат предикатів спі- вставлення потребує використання метрик виконаного співставлення. Запропонуємо метрику дії критеріїв співставлення, яка базується на встанов- ленні звішених шляхів між концептами онтології, вага яких залежить від типу від- ношень між концептами на шляху. Специ- фіка цієї метрики в тому, що вона дозво- ляє встановити не тільки оцінку співстав- лення за відповідностю заданому крите- рію, а за бажанням користувача оцінку “сили” зв’язку між концептами ПоБ та концептами ПоЗ. Ця “сила” визначається числом, яке є “вагою” зв’язку між концеп- тами онтології. Для кожного типа базового відношення в онтології воно постійне. За бажанням експерта для специфічних від- ношень може бути також вибране числове значення (або не встановлювати його зо- всім для відношень, які за думкою експе- рта є не типовими та рідко використовува- ними в аспекті). Таблиця. Предикатні символи та зміст предикатів співставлення образів ресурсів в багатоаспектній системі № п\п Назва Зміст Предикатний сим- вол 1 Ігнорування найменш знач- ного за думкою експерта аспекту в запиті Складний ПоЗ, який складається з декількох простих (атестації по одному аспекту), по- слабляється шляхом відкидання незначного за думкою експерта аспекту з ПоЗ Rмінус асп 2 Відкидання найбільш не релевантного за підказкою системи Таке послаблення має сенс після підказки системи, який з представлених в ПоЗ аспектів є найбільш не релевантним критерію Rрелев асп 3 Ігнорування в одному аспе- кті певної кількості дескри- пторів, які відмічені в ПоЗ Це ослаблення проводиться в одному аспекті в простому запиті . При цьому видаляються менш значні за думкою експерта індексатора ПК концепти Rдескр 4 Ігнорування декількох де- скрипторів в складному запиті Це відкидання дескрипторів декількох прос- тих запитах одночасно. Тобто корегування всього складного запиту R2 дескр 5 Узагальнене співставлення Під узагальненим співставленням будемо розуміти співставлення, коли замість означе- ного в ПоЗ дескриптора для пошуку викорис- товуються його батьки в ієрархії онтології аспекту Rузагальнене 6 Звужене співставлення Відповідно, при звуженому співставленні допускається, коли замість визначеного в ПоЗ дескриптора можна використати дескриптори, що конкретизують вказаний у ієрархії онтологій аспект Rзвужене 7 Співставлення з радіусом пошуку При цьому типі співставлення задається ра- діус пошуку, який можна ігнорувати при спі- вставленні вершин ПоЗ з ПоБ компоненти Rрадіус 8 Співставлення по відно- шенню При цьому типі співставлення вважаються релевантними ті вершини, які безпосередньо зв’язані вказаним відношенням з поміченими в ПоЗ вершинами Rвідн 9 Співставлення по групі від- ношень При цьому типі співставлення вважаються релевантними ті вершини, які безпосередньо зв’язані відношеннями із групи вказаних при виборі предикату з поміченими в ПоЗ верши- нами R2відн Інформаційні системи 69 Означення. Відношення, яке має від- повідну числову мітку, будемо називати звішеним зв’язком. Два однакових за типом послідовних звішених зв’язка дають новий звішений зв’язок. Таким чином встановлюється нова вага шляху, яка для шляху визначається по-різному для різних типів відношень. Визначимо правила встановлення ваги для шляху, який породжується двома послідо- вними звішеними зв’язками в залежності від типу зв’язку. Встановимо ці правила для набору базових відношень: 1) для зв’язку “асоціації” сила (ва- га) нового зв’язку, який породжується двома послідовними зваженими зв’язками, дорівнює максимальній силі з цих двох; 2) для зв’язку, який породжений послідовністю двох зв’язків “спеціаліза- ція”, сила результуючого зв’язку дорівнює максимальній силі з цих двох; 3) для зв’язку “агрегація”, сила ре- зультуючого зв’язку дорівнює мінімальній силі з цих двох; 4) для зв’язка “вид” сила (вага) но- вого зв’язка, який породжується двома по- слідовними зваженими зв’язками, дорів- нює мінімальній з сил обох зв’язків. Якщо слід встановити силу шляху, який складається з різних типів відношень, то вона дорівнюватиме сумі ваг різних від- ношень. Якщо зважений зв’язок перерива- ється, то результуючої ваги шляху не існує. Якщо всі зв’язки в шляху є зв’язками одного типу, причому це відно- шення охарактеризоване як транзитивне, будемо вважати, що кінцеві концепти шляху знаходяться у цьому відношенні (наприклад, віс відношення шляху “спеці- алізація”, тоді результуюче відношення шляху буде “спеціалізація”). Означення. Позитивним зв’язком між концептами назвемо зв’язок, при яко- му результуюче відношення між кон- цептами в онтологічній ієрархії існує та не перевищує поріг, встановлений експертом домену. Якщо в шляху існує хоча б один зв’язок, який не має “ваги”, то результую- чого відношення шляху не існує та конце- пти не поєднані позитивним зв’язком. Для того, щоб підрахувати силу шляху, який включає асоціації різних ти- пів, необхідно в першу чергу знайти сили його підшляхів. Задача алгоритму – знайти всі шляхи та всі ваги шляхів між концеп- том ПоЗ та концептами, які складають ПоБ компоненти. Якщо знайдені “ваги” шляхів не перевищують порогового значення, то такі концепти вважаюьться адекватними запиту. Якщо не знайдено жодного конце- пту, який є адекватний запиту, то таке ПоБ не входить до результату запиту. Наведемо операції онтологічної си- стеми по проведенню співставлення при впровадженні пошуку та співставлення ПоБ з ПоЗ. У випадку, коли користувач бажає задіяти наведений апарат зміни критерію співставлення за допомогою вагової оці- нки, він повинен: 1) встановити поточний аспект; 2) включити режим побудови ПоЗ; 3) в діалоговому режимі встано- вити (або залишити ті, які встановленні по замовченню) числа для ваг відношень, які він вважає за потрібне використати при поточному співставленні; 4) у випадку, якщо відношення іг- норується при використанні вагової мет- рики він не має ваги та таким чином пре- риває звішаний шлях; 5) у випадку, коли користувачем встановлюється вага рівна 0, вона не впли- ває на оцінку шляху, але і не руйнує його позитивності; 6) користувач має встановити по- ріг, який дозволить у подальшому розши- рити побудоване первинне ПоЗ до визна- ченої межі. Такий параметр вибирається експериментально та може бути змінений в подальшому у випадку отримання ре- зультату, який не задовольняє запитувача ПК; 7) побудувати первинний ПоЗ; 8) обрати один з типів предикатів співставлення (наприклад, співставлення за одним типом відношення); Інформаційні системи 70 9) виконати активізацію пошуку; 10) проглянути отримані резуль- тати, тобто назви та ПоБ релевантних ПоЗ компонент; 11) у випадку нерелевантності ре- зультатів вимогам користувача можливе ітераційне повторення дій (починаючи з пункту 3 або 6) з подальшим корегуванням порогу розширення (або звуження) адеква- тної області по відношенню до ПоЗ до мо- менту отримання задовольняючого резуль- тату. На базі знайдених у процесі роботи подібного алгоритму звішених зв’язків для різних відношень між концептами в онто- логічній системі може бути побудована узагальнена числова метрика “звішеної” відстані між ПоБ та ПоЗ програмної ком- поненти. Така метрика дозволить встановлю- вати ефективність того чи іншого преди- кату співставлення при порівнянні ПоБ та ПоЗ компонент на базі відношення слаб- кого чи сильного зв’язку між концептами ПоБ та ПоЗ компонент. Назвемо відношення між двома кон- цептами Сi та Сj Rзвішене. Будемо вважати, що концепт Ci, який приймає участь в ПоБ компоненти релева- нтний за вагою шляху (тобто находиться у звішеному відношенні) концепту Cj, який приймає участь в ПоЗ, якщо Ci має резуль- туючий зв’язок з Cj (positive(Ci,Cj)). Rзвішене(Ci,Cj)⇔(∃Iij: Iij = positive(Ci,Cj)). В цьому означені Iij – числове значення, яке не більше встановленого порогового зна- чення для даного типу відношення. Будемо вважати, що концепт Cj, який приймає участь в ПоБ компоненти релевантний за вагою шляху (тобто нахо- диться у звішеному відношенні) ПоЗ в ас- пекті онтології А, якщо в ПоЗ існує Ci, яке має позитивний зв’язок з Cj (Iij = positive(Ci,Cj)). Будемо вважати, що ПоБ компоне- нти релевантний за вагою шляху (тобто находиться у звішеному відношенні) до ПоЗ в аспекті онтології А, якщо для будь – якого концепту з Сi з ПоБ існує Cj з ПоЗ, такий що є позитивний зв’язок Сi з Cj (Iij = positive(Ci,Cj)). Методики комбінування різних за типом предикатів співставлення та мето- дики встановлення звішеного концептуа- льного зв’язку дозволяють виявляти ті компоненти, які відповідають запиту за встановленим предикатом (тобто крите- рієм релевантності) та одночасно ті ПоБ компонент в репозиторії, які пов’язані з поточним ПоЗ “сильним” позитивним зв’язком. Нехай запит ПоЗ складається з кортежу концептів онтології (С1,С2, ...,Сi, …., Cn). Нехай R – один з предикатів, які наведені в таблиці вище. Тоді запит Q (ПоЗ, P, R, A) = {ПоБi  ПоБi ⊆ А, positive (ПоЗ,ПоБi)<=P, ПОЗRПОБ = true} , де Positiv(ПоЗ,P) – сила позитив- ного зв’язку за встановленим пороговим значенням P релевантності шляху між за- значеним у запиті ПоЗ та поточно розгля- дуваним ПоБі, який міститься в репозито- рії, A – аспект онтологічної ієрархії до- мену. Саме потужність множини Q(ПоЗ, P, R, A,) є визначальною для шукача ПК для прийняття рішення про продовженя сесії пошукових запитів, або її зупиненні. Також важливим є те, що результат запиту формується як комбінація результатів за кожним з аспектів. Значимість результату за кожним з аспектів та те, наскільки ваго- мим є результат за окремими аспектом до- зволяє прийняти рішення про доцільність використання ПК у новій розробці. Нага- даємо, що ті з предикатів, які не є важли- вими на даний момент пошукової сесії, шукач має змогу відкинути вже на етапі підбору відповідного предикату співстав- лення. Висновки На базi побудованої у рамках обра- ного домену онтології пропонується метод аналітичного поаспектного співставлення різних за типом програмних компонент. Він полягає у використанні предикатів спі- вставлення з метою проведення поаспект- ного аналізу інформаційних моделей ПК. Інформаційні системи 71 Базис цього підходу становлять предикати співставлення, які пропонується викорис- товувати при проведенні транзакцій співс- тавлень з метою виявлення адекватної ви- могам користувача ПК. Введені предикати співставлення дозволяють оцінити подібність між двома образами ПК. Для проведення найбільш результативного пошуку адекватної вимо- гам ПК вводяться різні за типом предикати співставлення. Кожний з предикатів при- слуговує проведенню точного або послаб- леного співставлення між побудованим користувачем пошуковими образами та пошуковим запитом, які будуються відпо- відно індексатором та шукачем ПК в онто- логічній системі. Можливість варіювання типом ви- користовуваних у запиті предикатів співс- тавлення є перевагою даного методу. Рі- шення про використання в запиті того чи іншого предикату приймається шукачем базі після проведення аналізу ефективності результатів попередніх пошукових запитів. Шукач має можливість уточнити чи посла- бити запити в залежності від кількості та якості тих ПК, які пропонуються йому для повторного використання в результаті проведеного попереднього пошукового запиту. Таким чином поетапно будується гнучкий пошуковий запит для пошуку аде- кватних вимогам шукача компонент. Комбінації різних за типом преди- катів та одночасно використання метрики “сильного” позитивного зв’язку між ПоЗ та ПоБ дозволить отримати більш точний результат при впровадженні пошукової се- сії у багатоаспектній онтологічній системі. У подальшому планується розши- рити коло використовуваних при побудові запиту предикатів співставлень, а також провести аналіз ефективності викорис- тання конкретних предикатів у запитах. Також планується робота по проведенню співставлення ефективності різних комбі- націй предикатів при побудові запитів. Ці- каво виявити залежність ефективності того чи іншого запиту від структури онтології, на базі якої він будується. 1. Бабенко Л.П., Поляничко С.Л. Онтологічні моделі опису готових ресурсів у розробці програм. Пр. міжнар. конф. УКРПРОГ. - 2004. - № 2-3. - С.173-179. 2. Gomes-Perez A., Fernandez-Lopez M., Corcho O. Ontological Engineering // Springer –Ver- lag London Limited. - 2004. – 403 c. 3. Бабенко Л.П. Проблемы повторного ис- пользования в программной инженерии. Кибернетика и системный анализ.-1999. - №2. - С. 155-166. 4. Robert B. France, Sudipto Ghosh. A UML- Based Pattern Specification Technique// IEEE Transactions on Software Engineering. - 2004. - v.3. - №3. - P. 193-206. 5. Грищенко В.М. Методи еволюції програм- них компонентів для їх повторного застосу- вання. Труди міжн. конф. По програму- ванню УКРПРОГ. - 2004. - № 2-3. - С. 215-222. 6. Бабенко Л.П., Поляничко С.Л. Подходы к аттестации адаптивных возможностей про- граммных компонент// Там же. – 2001. – N 1-2. – С. 35-41. 7. Как программировать на XML. – М.: “Би- ном”, 2001. – 933 с. 8. Поляничко С.Л. Предикати співставлення для порівняння та аналізу компонент// Про- блеми програмування. – 2002. – N 1-2. – С. 117-120. 9. Zaremsky A.M., Wing J.M. Specification Matching of Software Components//ACM Software Eng. Notes. - 1995. - August. - P. 6-16. 10. Zaremsky A.M., Wing J.M. Signature Matching; A Tool for Using Software Libraries// ACM Transaction on Software Engineering and Methodology. - 1995. - 4, N2. - P. 146-170. 11. Zaremsky A.M., Wing J.M. Specification Matching; A Tool for Using Software Libraries// ACM Transaction on Software Engineering and Methodology. - 1997. - 6, N4. - P. 333-369. Отримано 27.11.2006 Інформаційні системи 72 Про автора: Поляничко Софія Леонідівна м.н.с. відділу №14 “Програмна інженерія” Місце роботи автора: Інститут програмних систем НАН України. 04053, Київ, вул. Артема, д.59/65, кв. 63, тел. 486-71-50, e-mail: sonypol@rambler.ru, sonypol@voliacable.com
id nasplib_isofts_kiev_ua-123456789-280
institution Digital Library of Periodicals of National Academy of Sciences of Ukraine
isbn 1727-4907
language Ukrainian
last_indexed 2025-12-07T17:19:55Z
publishDate 2007
publisher Інститут програмних систем НАН України
record_format dspace
spelling Поляничко, С.Л.
2008-02-22T17:30:35Z
2008-02-22T17:30:35Z
2007
Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи / С.Л. Поляничко // Пробл. програмув. — 2007. — N 1. — — Бібліогр.: 11 назв. — укp.
1727-4907
https://nasplib.isofts.kiev.ua/handle/123456789/280
681.3
Тема дослідження роботи - багатоаспектна атестація та пошук програмних компонент в онтологічній системі (ОС). Запропоновано метод використання онтологій аспектів для автоматизованого керування зміною стратегії встановлення релевантності під час пошуку програмних компонент в ОС.
uk
Інститут програмних систем НАН України
Інформаційні системи
Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи
Article
published earlier
spellingShingle Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи
Поляничко, С.Л.
Інформаційні системи
title Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи
title_full Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи
title_fullStr Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи
title_full_unstemmed Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи
title_short Керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи
title_sort керування стратегіями зміни релевантності при пошуку програмних компонент в репозиторії онтологічної системи
topic Інформаційні системи
topic_facet Інформаційні системи
url https://nasplib.isofts.kiev.ua/handle/123456789/280
work_keys_str_mv AT polâničkosl keruvannâstrategíâmizmínirelevantnostípripošukuprogramnihkomponentvrepozitorííontologíčnoísistemi