«Конструирование информационных систем на основе интероперабельных сред информационных ресурсов ...»

Российская Академия Наук

Институт Проблем Информатики

на правах рукописи

БРЮХОВ Дмитрий Олегович

Конструирование информационных систем на основе

интероперабельных сред информационных ресурсов

05.13.11. - математическое и программное обеспечение

вычислительных машин, комплексов, систем и сетей

ДИССЕРТАЦИЯ

на соискание ученой степени кандидата технических наук

Научный руководитель доктор физико-математических наук, профессор Калиниченко Л.А.

МОСКВА

2003 Введение

Глава 1 Основные составляющие этапа конструирования информационных систем, требующие алгоритмизации

Промежуточный слой

1. Методы создания ИС

1. Методы объектного анализа и проектирования ИС

1.2. Методы создания ИС из компонентов

1.2. Композиционный подход к проектированию ИС на основе 1. интероперабельных сред информационных компонентов

Общее описание подхода

1.3. Этап конструирования

1.3. Особенности композиционного подхода к проектированию ИС 1.3. Пример композиционного проектирования ИС

1. Выводы по главе

1. Глава 2 Поиск релевантных спецификаций

Основные понятия

2. Спецификация онтологий на языке СИНТЕЗ

2. Функции корреляции

2. Композиция ассоциаций

2. Процесс поиска релевантных элементов спецификаций

2. Пример поиска релевантных спецификаций

2. Спецификации онтологических понятий

2.6. Отображение понятий спецификаций компонентов/требований в 2.6. понятия общей онтологии

Установление ассоциаций между понятиями спецификации 2.6. требований и компонентов

Список релевантных элементов спецификаций

2.6. Выводы по главе

2. Глава 3 Разрешение конфликтов между спецификациями требований и компонентов

Виды конфликтов

3. Описание преобразований на языке СИНТЕЗ

3. Подход к разрешению структурных конфликтов

3. Основные понятия

Правила структурных преобразований

Дерево типа

Алгоритм поиска релевантных путей

Пример релевантных путей

Выводы по главе

спецификации требований

Основные понятия

Понятие уточнения

Редукт типа

Композиция типов

Спецификация редуктов

Спецификация композиционных типов и взглядов

Поиск повторно используемых фрагментов

Композиция фрагментов спецификаций

уточняющих класс спецификации требований

Выводы по главе

конструирования ИС из компонентов

Общая архитектура

Сценарий работы эксперта-конструктора ИС

Программные средства поиска релевантных спецификаций........... Программные средства разрешения структурных конфликтов между спецификациями требований и компонентов

Программные средства выявления фрагментов компонентов и их композиция в спецификации, уточняющие спецификации требований... Программные средства поддержки репозитория метаинформации Программные средства реализации ИС

Выводы по главе

Заключение

Литература

Приложение А Основные особенности языка СИНТЕЗ

Приложение Б Представление понятий языка СИНТЕЗ в UML................. Введение Идея конструирования информационных систем (ИС) из компонентов развивается на протяжении многих лет. По существу, речь идет о мегапрограммировании (Дж.Видерхольд) – крупноблочном конструировании систем. Согласно этой идее, целесообразнее осуществлять капиталовложения в создание компонентов, которые можно было бы многократно использовать, чем всякий раз осуществлять разработку ИС сверху – вниз: от спецификаций привлекательность идеи и многочисленные исследования и разработки в этой области, достигнутые результаты не соответствуют существенно возросшим в последнее время технологическим возможностям.

Сеть Интернет наводнена компонентами. Развивающиеся технологии промежуточного слоя (такие, как, например, CORBA, Java RMI, DCOM,.NET, или в последнее время Web Services) обеспечивают техническую возможность конструирования распределенных, интероперабельных ИС, как из программных, так и из информационных компонентов. Эти технологии, также, позволяют накапливать репозитории компонентов для их дальнейшего использования при создании новых ИС. Развитие Интернет уже в ближайшем будущем позволит рассматривать его как базу данных с моделью данных, информационные компоненты, пригодные для использования в составе ИС.

Технологии промежуточного слоя и Интернет интегрированы и могут использоваться совместно при создании ИС.

Что же достигнуто в области конструирования ИС из компонентов.

Главным образом развиваются методы и средства компонентнобазированного проектирования ИС. При этом традиционно рассматриваются программные компоненты. Примерами таких технологий являются Microsoft’s.NET и SunSoft’s JavaBeans. Существующие средства создания программ, такие как Microsoft’s Visual Studio, Inprise's Delphi и Protosoft's Power Builder Отличительной чертой этих средств является их ориентированность на неполные спецификации компонентов и предварительное, детальное знание программистом возможностей этих компонентов. Эти средства хороши для работы с “локальными” библиотеками, когда предполагается их хорошее знание разработчиком. Такой подход является также небезопасным, поскольку из-за неполноты спецификаций невозможно убедиться в адекватности компонентов спецификации требований.

Наряду с такими технологиями, методы Объектного Анализа и Проектирования (ОАП) предлагают графические нотации и методологии для проектирования ИС. Основной используемой нотацией методов ОАП в последнее время является унифицированный язык UML. По сути, эти методы реализуют традиционное проектирование сверху – вниз. Средства, которые предоставляются методами ОАП (такими, например, как Rational Rose от Rational Software и Paradigm Plus от Platinum) для повторного использования, требуют глубокого знания разработчиком используемых компонентов, что находит применение для использования библиотек программ (например, использование графических библиотек в средствах визуального проектирования). Часто названные средства используются комбинированно анализ и проектирование ИС осуществляется на основе методов ОАП, а реализация системы осуществляется с использованием средств визуального программирования (например, Delphi, Power Builder).

использовать потенциальные возможности компонентов, накапливаемых в компонентов, не позволяют конструировать системы из компонентов небезопасными.

Данная работа является исследованием, выполненным в соответствии с композиционным подходом к конструированию ИС, развиваемым в рамках проекта СИНТЕЗ в Лаборатории композиционных методов проектирования информационных систем Института проблем информатики РАН. Этот подход ориентирован на преодоление указанных основных ограничений существующих технологий. Он предназначен для корректной композиции существующих компонентов, семантически интероперабельных в контексте интероперабельности (обеспечиваемой инфраструктурами промежуточного слоя), подход рассматривает интероперабельность в более широком, семантическом аспекте. Семантическая интероперабельность означает комбинацию нескольких способностей: способности решения вопроса о релевантности имеющихся компонентов разрабатываемому применению, о соответствии их прикладных контекстов контексту применения, а также о том, что интероперабельная композиция ресурсов будет непротиворечивой в контексте разрабатываемого применения.

Анализ текущего состояния технологических приемов проектирования систем из компонентов и исследований в этой области показывает, что в настоящее время не известны результаты, которые позволяли бы интероперабельных в контексте спецификации требований, и уточняющую спецификацию требований.

В диссертационной работе осуществляется исследование и разработка методов и средств композиционного подхода, ориентированных на создание ИС из компонентов, технически интероперабельных в рамках некоторого промежуточного слоя.

Цель и задачи работы Целью диссертационной работы является исследование и разработка интероперабельных в рамках некоторого промежуточного слоя.

Достижение цели предполагает решение следующих задач:

1. разработка алгоритмов поиска компонентов, онтологически релевантных спецификации требований;

спецификациями требований и компонентов;

3. разработка алгоритмов выявления фрагментов спецификации соответствующих фрагментов спецификации требований;

4. разработка алгоритмов построения композиции таких фрагментов в спецификацию, уточняющую спецификацию требований;

5. создание инструментария эксперта-конструктора ИС на основе перечисленных алгоритмов.

Методы исследования При решении поставленных в работе задач использовались методы объектного проектирования, методы теории множеств, теории графов, теории уточнения спецификаций.

Научная новизна В диссертационной работе получены следующие новые научные результаты:

интероперабельных в рамках некоторого промежуточного слоя;

предложена онтологическая модель и на ее основе разработаны связанных с ними понятий на естественном языке;

разработан метод разрешения различных рассогласований между спецификациями требований и компонентов, объединяющий в себе два известных подхода в области интеграции схем баз данных – преобразований, и применение языка высокого уровня для описания функций разрешения конфликтов;

разработан оригинальный метод конструирования композиции фрагментов спецификации компонентов с использованием операций над типами. Этот метод основан на понятии уточнения - уточняющие спецификации, образуемые при конструировании таких композиций, могут использоваться всюду вместо уточняемых спецификаций требований, так что пользователи не замечают этой замены.

Практическая ценность Предлагаемый в диссертационной работе композиционный подход к информационных систем как в рамках одного предприятия, так и в рамках Интернет. Использование данного подхода позволяет ускорить процесс создания новых ИС. Это также повышает надежность систем за счет использования уже проверенных, протестированных компонентов и уменьшает время на отладку и тестирование систем. Все вместе это ведет к снижению стоимости разработки ИС. Благодаря используемым методам спецификации и поиска компонентов, композиционный подход является масштабируемым по числу накопленных компонентов.

Разработанные алгоритмы могут использоваться и в других задачах. В частности, они использовались при создании предметного посредника для электронных библиотек (в методе регистрации неоднородных коллекций и в методе проектирования персонализированных виртуальных электронных библиотек, создаваемых для конкретных пользователей).

Разработанный на базе этих алгоритмов инструментарий может быть применен также для создания ИС в различных прикладных областях, например, в ИС для научных исследований, электронных библиотеках для образования, интеллектуальных системах управления и принятия решений, и других.

Результаты диссертационной работы использованы в проектах, выполняемых по планам ИПИ РАН, в проектах РФФИ 97-07-90369 и 00-07в проекте ИНТАС INTAS-94-1817, а также в совместном проекте с Siemens Corporate Research and Development.

Апробация работы Основные результаты диссертации докладывались на Международных конференциях ADBIS (Москва 1995, Москва 1996, Познань 1998, Марибор 1999, Вильнюс 2001, Дрезден 2003), на Международном симпозиуме по персонализации и рекомендационным системам в электронных библиотеках (Дублин 2001), на Российских конференциях по электронным библиотекам RCDL (Протвино 2000, Петрозаводск 2001, Дубна 2002), на семинаре Московской секции ACM SIGMOD (Москва 1998), на научных семинарах по проекту СИНТЕЗ лаборатории Композиционных методов проектирования информационных систем Института проблем информатики РАН.

На защиту выносятся следующие, полученные автором результаты:

композиционный подход к конструированию ИС из информационных компонентов, технически интероперабельных в рамках некоторого промежуточного слоя;

метод и реализующие его алгоритмы поиска элементов спецификаций компонентов, релевантных элементам спецификации требований, на основе онтологической модели;

метод и реализующие его алгоритмы разрешения структурных конфликтов между спецификациями требований и компонентов;

спецификаций компонентов, которые могли бы служить уточнением соответствующих фрагментов спецификации требований;

метод и реализующие его алгоритмы построения композиции таких фрагментов в спецификацию, уточняющую спецификацию требований;

разработанный на основе перечисленных алгоритмов инструментарий эксперта-конструктора ИС.

Публикации по теме диссертации По теме диссертации автором опубликовано 8 работ.

Структура работы Текст диссертации включает введение, пять глав, заключение, список литературы и два приложения.

информационных систем на основе композиции существующих компонентов.

Во второй главе описывается подход к поиску элементов (классов, типов, атрибутов, функций) компонентов, подходящих для их использования в разрабатываемой ИС, основанный на онтологической интеграции.

В третьей главе описывается подход к разрешению конфликтов между фрагментами спецификаций требования и компонентов.

В четвертой главе описываются особенности процесса выявления повторно используемых фрагментов компонентов и их композицию в спецификацию, конкретизирующую спецификацию требований.

В пятой главе представлены созданные программные средства, реализующие разработанные алгоритмы композиционного подхода к проектированию ИС, их архитектура, интерфейсы и описание компонентов.

В заключении приводятся основные результаты, полученные в рамках данной работы.

В приложении А содержится описание особенностей языка СИНТЕЗ.

В приложении Б описано представление основных понятий языка СИНТЕЗ в нотации UML.

Глава 1 Основные составляющие этапа конструирования информационных систем, требующие алгоритмизации 1.1 Промежуточный слой В последнее время интенсивно развиваются технологии, позволяющие конструировать распределенные ИС, в которых дистанционные, неоднородные компоненты могут совместно работать для решения задач. В принципе, такую совместную работу можно организовать, используя примитивы, предоставляемые операционными системами. Однако на практике использование такого подхода является достаточно сложной задачей. Обычно, архитектура распределенных ИС базируется на концепции промежуточного слоя (middleware) [7, 50]. Этот слой расположен между операционной системой и прикладными системами, специфическими для конкретных областей применения.

К технологиям промежуточного слоя относятся CORBA, Java RMI, COM. OMG CORBA обеспечивает совместную работу компонентов, использующих разные аппаратные платформы, операционные системы, сетевые технологии и языки программирования. Взаимодействие между компонентами осуществляется с помощью Брокеров Объектных Заявок (ORB). Разработанная Microsoft Компонентная Объектная Модель (COM), позволяет взаимодействовать приложениям, написанным на разных языках программирования. Первоначально, обеспечивал интеграцию неоднородных компонентов на одном и том же компьютере. Но с появлением технологии Распределенной Компонентной Объектной Модели (DCOM), COM стал поддерживать распределенный доступ с помощью OSF/RPC. В языке Java содержатся примитивы для удаленного вызова методов (Remote Method Invocation, RMI), что позволяет Java-объектам на одной компьютере вызывать методы Java-объектов, расположенных на удаленном компьютере.

Данные технологии промежуточного слоя обеспечивают поддержку системного, технического уровня интероперабельности. Под технической интероперабельностью понимается способность совместной работы компонентов, разработанных с использованием различных языков программирования, в различных операционных системах, и расположенных на разных компьютерах.

Промежуточный слой позволяет скрыть распределенность ИС от пользователя. Другими словами, пользователь воспринимает систему как единое целое. Промежуточный слой также позволяет скрыть сложность распределения ИС от разработчиков. Такое сокрытие называется прозрачностью (transparency). Наличие прозрачности в распределенных системах позволяет компонентам-клиентам пользоваться услугами компонентов-серверов, не зная физического местонахождения компонентов на серверах.

Промежуточный слой обеспечивает как динамическое образование композиций компонентов, организуемых для решения задачи, так и мегапрограммирования – программирования в среде готовых компонентов, позволяющее крупномасштабно применять технологию повторного использования информационных компонентов.

С ростом числа компонентов в Интернет/Интранет встает вопрос местонахождения распределенных компонентов используются две основных технологии — именование и трейдинг.

именования. С объектами-серверами связывается логическое имя. Это имя определяет путь вдоль связываний имен от контекста именования до объекта.

Объекты-клиенты могут разрешать связывание имени для определения местонахождения объекта.

Такой подход предполагает, что идентификация компонентов-серверов осуществляется по имени. Но знание имен компонентов-серверов не всегда возможно при создании компонентов-клиентов. Трейдинг [50] позволяет решить эту проблему. Основная идея состоит во введении компонентатрейдера, который делает выбор от имени клиента. Компоненты-клиенты (импортеры) и компоненты-серверы (экспортеры) выступают в качестве клиентов трейдеров.

Экспортеры регистрируют предложения сервиса в трейдере. Трейдер заносит эти сервисы в свою базу данных. При экспорте указываются значения для всех обязательных свойств сервиса; тем самым экспортеры гарантируют определенное качество обслуживания.

В запросах к трейдеру импортеры указывают типы сервисов, ограничения, стратегии и предпочтения. В ответ на запросы трейдер возвращает последовательности тех предложений сервисов из базы данных, которые имеют нужный тип сервиса и удовлетворяют требованиям ограничений и стратегий. Последовательности сортируются в соответствии с предпочтениями.

После того, как импортер нашел подходящего экспортера, он осуществляет вызов выбранного сервиса непосредственно у найденного экспортера без участия трейдера.

Трейдеры могут быть объединены в федерацию с образованием графа трейдинга. Трейдер, являющийся узлом графа, может перенаправлять запросы другим трейдерам. Каждому из трейдеров, входящих в федерацию, становятся доступны базы данных всех остальных трейдеров федерации.

Спецификация сервиса осуществляется в виде типа. Функциональные возможности сервиса определяются операциями типа. Характеристики сервиса (например, качество) определяются типом свойства сервиса, включающим имя свойства, тип свойства и вид свойства.

Из технологий промежуточного слоя трейдинг реализован только в CORBA [36].

Основным ограничением трейдинга является отсутствие семантики в спецификации сервисов экспортеров. Описание сервисов осуществляется в виде комментариев на естественном языке. Такая спецификация сервисов экспортеров в виде типа не гарантирует их корректное использование импортером.

1.2 Методы создания ИС Технологии промежуточного слоя обеспечивают техническую возможность конструирования распределенных, интероперабельных ИС.

Созданию таких распределенных систем способствует ряд подходов, среди которых в рамках диссертационной работы заслуживают внимания, прежде всего методы Объектного Анализа и Проектирования (ОАП) систем и способы повторного использования неоднородных информационных компонент.

1.2.1 Методы объектного анализа и проектирования ИС Методы Объектного Анализа и Проектирования (ОАП) предоставляют методологию создания информационных систем на протяжении всех этапов жизненного цикла при использовании объектного подхода. По сравнению с традиционными методами (такими как структурный анализ), методы ОАП обладают целым рядом преимуществ:

конструирования систем из повторно используемых модулей;

использование существующих, уже протестированных классов ведут к созданию более стабильных, более качественных систем;

использование механизма наследования позволяет определять и использовать модули, которые функционально неполны, и затем, позволяя расширять (специализировать) их для нужд конкретного приложения;

использование механизма инкапсуляции дает возможность разработки систем в терминах поведения объектов, не прибегая к их внутренним деталям;

большая близость объектной модели непрограммистам по сравнению со структурной моделью;

уменьшение времени проектирования систем;

более простая поддержка системы во время всего жизненного цикла за счет использования единой объектной модели.

Методы ОАП состоят из графической нотации и процесса создания информационных систем. Существовали десятки различных методов ОАП, таких как OOD [5], OMT [39], Objectory [21] и др. И, хотя, все они были основаны на объектной модели, они зачастую использовали различные понятия и терминологию, различные графические представления понятий, разные этапы процесса проектирования.

Для унификации методов ОАП в 1992 г. в рамках OMG была создана группа по ОАП (Object Analysis and Design Special Interest Group). В 1993 г.

группой был опубликован обзор существующих на тот момент методов ОАП [34, 35]. Для сравнения различных методов ОАП обычно используется абстрактная модель. В рамках этой модели разработка ИС включает в себя этапы стратегического планирования, анализа, проектирования и реализации.

Они могут трактоваться как этапы традиционной “водопадной” модели жизненного цикла.

этап стратегического планирования. Целью этапа является определение основных функций системы, методов взаимодействия системы с внешним миром (человеком, другими системами), стратегии разработки системы с учетом организационных, финансовых и технических ограничений;

этап анализа. Целью этапа является получение полного и детального описания проблемной области, не зависящего от среды реализации;

этап проектирования. Целью этапа является уточнение модели системы, полученной на этапе анализа, для адаптации к реальной среде реализации и определение возможности использования существующих этап реализации. Целью этапа является конкретная реализация системы.

Следующим шагом OMG в области методов ОАП была создание единой метамодели для методов ОАП. В 1995 г. был подготовлен RFP (Request For Proposals) на стандартизацию интерфейса и семантики метамодели. В 1997 г. OMG утвердила язык UML (Unified Modelling Language) [48] в качестве промышленного стандарта. UML разработан тремя авторами наиболее популярных методов ОАП: Гради Бучем (Grady Booch), Джеймсом Румба (James Rumbaugh) и Иваром Якобсоном (Ivar Jacobson).

Фактически, UML установил стандарт не только на метамодель, но и на графическое представление понятий ОАП.

Язык UML не является собственно методом ОАП, он представляет только набор понятий и их графическое представление и не затрагивает собственно процесс проектирования информационных систем. Компания Rational предлагает унифицированный процесс (Rational Unified Process RUP) создания ИС на основе UML. RUP представляет из себя набор программных средств и подходов к коллективному созданию ИС в среде WWW.

Не смотря на все различия, по сути, все методы ОАП реализуют традиционное проектирование сверху – вниз. Все те средства, которые используемых компонентов, что может быть хорошо применимо для использования библиотек (например, использование графических библиотек в средствах визуального проектирования).

1.2.2 Методы создания ИС из компонентов В настоящее время все больше и больше компонентов появляется на рынке электронной коммерции. Текущая тенденция состоит в разработке вместо систем как готовых монолитных систем, содержащих все мыслимые возможности, легковесного ядра к которому могут добавляться новые возможности в форме компонентов. Примерами такого подхода являются IBM's SanFrancisco и RogueWave. Развитие WWW уже в ближайшем будущем позволит рассматривать WWW как базу данных с моделью данных, информационные компоненты, пригодные для использования в составе ИС.

Повторное использование таких компонентов позволяет ускорить процесс создания новых ИС. Оно также повышает надежность систем за счет использования уже проверенных, протестированных компонентов. Это также уменьшает время на отладку и тестирование систем. Все вместе это ведет к снижению стоимости разработки новых информационных систем.

появляться все больше программных продуктов и технологий, основанных на описанном подходе. Примерами таких технологий являются Microsoft’s ActiveX и SunSoft’s JavaBeans. Существующие средства создания программ, такие как Microsoft’s Visual Basic, Inprise's Delphi и Protosoft's Power Builder позволяют конструировать программы из готовых графических компонентов, включая компоненты ActiveX и JavaBeans.

предварительное, детальное знание программистом возможностей этих библиотеками предполагая их хорошее знание разработчиком. Такой подход является также не безопасным, поскольку из-за не полноты спецификаций невозможно доказать адекватность компонентов спецификации требования.

интероперабельных сред информационных компонентов 1.3.1 Общее описание подхода В диссертационной работе рассматривается, разработанный в рамках композиционным [9, 10]. Этот подход ориентирован на преодоление указанных основных ограничений существующих методов ОАП и методов компонентного проектирования. Он предназначен для проектирования ИС на основе корректной композиции существующих компонентов, технически интероперабельных в рамках некоторого промежуточного слоя. В отличие от технологиями промежуточного слоя, в проекте СИНТЕЗ рассматривается Семантическая интероперабельность означает комбинацию нескольких способностей: способности решения вопроса о релевантности имеющихся контексте разрабатываемой ИС.

Рис. 1.1 Схема композиционного подхода к проектированию ИС На Рис. 1.1 представлена общая схема предлагаемого в данной работе композиционного подхода к проектированию ИС. Этот подход включает в себя прямую и обратную фазы. При прямой фазе (левая часть рисунка) происходит описание спецификаций требований1 к проектируемой ИС. ИС разрабатывается в рамках определенной прикладной области, которая задает 1 В диссертации под спецификацией требований понимается множество спецификаций классов и типов, и множество спецификаций онтологических понятий разрабатываемой ИС.

прикладную семантику для спецификации требований. Этапы планирования требований и анализа реализуются с помощью применения произвольного метода ОАП, использующего нотацию UML. Выбранный метод ОАП расширяется онтологическими спецификациями, спецификациями функций и инвариантов, и другими понятиями канонической модели. Полученные спецификации в виде UML диаграмм отображаются в спецификации в канонической модели.

При обратной фазе (правая часть рисунка) происходит описание спецификаций компонентов. Для получения спецификаций компонентов 2 (в случае их отсутствия), этап обратной инженерии (reverse engineering) может быть реализован с помощью применения метода ОАП, использующего нотацию UML. Выбранный метод ОАП расширяется онтологическими спецификациями. Полученные спецификации в виде UML диаграмм формальную интерпретацию3.

В качестве канонической модели используется язык СИНТЕЗ, ориентированный на семантическую интероперабельность и композиционное существующих неоднородных информационных компонентов. Описание основных понятий языка СИНТЕЗ приведено в Приложении А. Для придания канонической модели в модель формальных спецификаций. В качестве такой формальной модели выбрана нотация абстрактных машин B-технологии [2, 3]. Представление основных понятий языка СИНТЕЗ в нотации UML [8] описано в Приложении Б.

2 В диссертации под спецификацией компонента понимается множество спецификаций классов и типов, и множество спецификаций онтологических понятий компонента.

3 Вопросы формальной интерпретации канонической модели разрабатываются в рамках проекта СИНТЕЗ и выходят за рамки данной работы Полученные спецификации требований и компонентов используются на этапе конструирования. Этап проектирования абстрактной модели методов ОАП является более широким, по сравнению с тем, что рассматривается в диссертационной работе. Та часть этапа проектирования, в рамках которой предполагается определение возможности использования существующих компонентов в разрабатываемой ИС, называется в работе этапом конструирования. Этот этап определяет процесс уточнения спецификаций требований ИС композицией информационных компонентов.

1.3.2 Этап конструирования Этап конструирования является основой композиционного подхода к проектированию ИС из интероперабельных информационных компонентов.

Диссертационная работа сфокусирована на данном этапе. Целью этапа является конструирование композиции фрагментов спецификаций компонентов для получения спецификаций, уточняющих спецификации требований. Этап конструирования состоит из следующих шагов:

поиск релевантных спецификаций;

разрешение конфликтов между спецификациями требований и компонентов;

выявление фрагментов компонентов и их композиция в спецификации уточняющие спецификации требований.

Поиск релевантных спецификаций Задача поиска компонентов подходящих для использования их в разрабатываемой системе является одной из важных задач композиционного проектирования. В текущих методах и средствах разработчик должен явно задавать, какие компоненты он собирается использовать. При этом необходимо знание разработчиком подходящих компонентов. Такой подход хорошо работает при работе с библиотеками, когда разработчик хорошо знает доступные компоненты. Но такой подход плох для использования его в среде Интернет, когда разработчик пытается использовать различные компоненты доступные через Интернет, о которых он может заранее и не знать. В этом случае без соответствующих методов и средств поиска не обойтись.

Данная задача близка задаче поиска релевантных элементов при интеграции схем баз данных. Методологии интеграции схем определяют возможно релевантные классы на основе анализа их атрибутов. Такие подходы используют методы, которые определяют степень близости классов на основе процента общих атрибутов ([20, 33, 43]), и более точные методы, использующие классификацию для выбора возможных отношений между классами из {subsume, equivalence, overlap, disjoint} [42].

Для установления релевантности атрибутов могут вводиться более аппроксимировать смысл (значение) атрибутов в терминах их области определения, кардинальности, других ограничений целостности (таких как уникальность, статические и динамические семантические ограничения, ограничения безопасности) и в доступных операциях. Наподобие релевантности классов, близость между атрибутами устанавливается при сравнении их характеристик.

Но любое множество таких характеристик недостаточно описывает реальный смысл (значение) атрибутов, таким образом, их сравнение может приводить к установлению неправильных соответствий или к невозможности нахождения правильных соответствий. Sheth и Gala [44] предложили пересекающихся семантических кластеров, уменьшая работу при попарном сравнении атрибутов. Они предлагают полностью классифицировать атрибуты (интеллектуально) в кластеры, и автоматически классифицировать классы.

В работе [51] авторы предложили комбинацию этих двух подходов.

Вместо использования синтаксических характеристик атрибутов (как в [28]), они связывают атрибуты с семантическими понятиями. Было предложено около 100 таких понятий, организованных в 14 иерархий. Они требуют полной (семантической) непротиворечивости посредством интерактивно нисходящих иерархий понятий. Близость двух атрибутов определяется как нормализованная степень пересечения их характеристик. В работе [52] предлагается извлекать такие аннотации понятий из описаний на естественном языке, исключая stop слова и используя обратную связь с пользователем для обработки неполноты и многозначности.

В проекте Carnot [14] предлагается использовать нормативную глобальную схему, в которую отображаются локальные схемы. В качестве такой глобальной схемы используется база знаний Cyc [29]. После синтаксической трансформации локальной схемы в модель, используемую Cyc, каждое локальное понятие интерактивно отображается семантически в понятия Cyc, используя ограниченную форму структурной унификации в виде строки, т.е. семантическая неопределенность преодолевается удовлетворительно описать локальное понятие, Cyc расширяется этим понятием и/или недостающим аспектом. Из-за выразительной мощности Cyc, которая значительно уменьшает неясность модели, существует несколько возможных представлений понятий локальной схемы в глобальной схеме.

Эти различия моделей, однако, по-видимому, не берутся в расчет при сравнении понятий. Более того, для отображения локальных понятий в конструирования выражений отображения (articulation axioms). Таким образом, глобальная схема получается слишком большой, что затрудняет ее использование. К тому же, при увеличении глобальной схемы, семантическое отображение будет увеличивать неясность в виде множества возможных релевантных понятий.

Задаче поиска релевантных спецификаций также близка задача поиска релевантных сервисов при трейдинге [50]. Поскольку спецификация сервиса представляется в виде типа, в котором операции задают функциональные возможности сервиса, а атрибуты задают характеристики сервиса (например, качество). Вся семантика сервиса определяется только в виде комментариев.

Для обращения к необходимому ему сервису, импортер должен самостоятельно (вручную) найти подходящий сервис в базе трейдера. При этом он также должен убедиться в корректности использовании найденного сервиса.

В диссертационной работе основой для поиска спецификаций информационных компонентов и их фрагментов релевантных спецификации требований служит онтологическая модель [6, 19]. С каждым элементом (тип, класс, атрибут, функция) спецификации требований и спецификаций компонентов связывается онтологическое понятие. Установление связей между спецификациями требований и компонентов осуществляется посредством установления связей на соответствующих онтологических понятиях.

Спецификация онтологического понятия включает в себя вербальное описание и онтологические связи между понятиями: понятие-подпонятие (hypernym/hyponym), синонимы (synonym) и позитивные (positive) связи.

Онтологические понятия одного компонента (спецификации требований) объединяются в один онтологический модуль. Установление связей между понятиями онтологического модуля спецификации требований и понятиями онтологического модуля компонента осуществляется через общий онтологический модуль. Общий онтологический модуль содержит понятия определенной предметной области. Предполагается, что существует множество общих онтологических модулей для различных предметных областей. Выбирается тот модуль, в рамках которого разрабатывается конкретное приложение.

Установление связей между онтологическими понятиями модуля компонента и понятиями общего модуля (и между понятиями модуля спецификации требований и понятиями общего модуля) осуществляется на основе сравнения их вербальных спецификаций с использованием методов из области систем информационного поиска. В данной работе используется подход описанный Сэлтоном (G. Salton) [40].

Установление связей между понятиями спецификации требований и компонента осуществляется на основе композиции связей между понятиями.

Понятия спецификации требований и компонента связаны, если между ними существует путь.

Подробное описание процесса поиска релевантных спецификаций описано в Главе 2.

Разрешение конфликтов между спецификациями требований и компонентов При попытке повторного использования существующих компонентов неизбежно возникают конфликты между спецификациями этих компонентов и спецификацией требований разрабатываемой ИС. Они вызваны тем, что одни и те же объекты реального мира разными разработчиками могут быть специфицированы различными способами. Существуют различные виды конфликтов: конфликты значений (например, одинаковые атрибуты могут иметь разные типы или разные начальные значения), структурные конфликты (например, часть атрибутов типа в одном компоненте выделена в отдельный тип в другом компоненте).

Проблема разрешения структурных конфликтов при компонентном проектировании близка проблеме разрешения конфликтов при интеграции схем баз данных. Рассмотрим два подхода к разрешению структурных конфликтов: использование предопределенных правил преобразования или языка высокого уровня для описания преобразований.

При использовании предопределенных правил преобразования [25, 45] целью является автоматическое разрешение структурных конфликтов и генерация интеграционной схемы. Разработчик задает соответствие между элементами (классами, атрибутами) схем и соответствие между путями в схемах. Затем на основе предопределенных правил генерируется интеграционная схема (классы и функции преобразования значений между классами локальных и интеграционной схем). Основными преимуществами такого подхода являются простота аргументации и доказательность корректности применения данных правил. В частности, можно доказать, что каждое правило сохраняет информацию, и что комбинация таких правил также сохраняет информацию. Основным недостатком этого подхода является фиксация используемых правил, что вызывает ограниченность его выразительных возможностей.

При использовании языка высокого уровня [26] разработчику предоставляется богатый язык для описания правил преобразования. Однако каждая функция разрешения конфликта должна быть запрограммирована и ее правильность доказана отдельно. Как и в предыдущем подходе, разработчик сам задает соответствие между элементами схем. Данный подход предоставляет пользователю более гибкие средства формирования интегрированной схемы, позволяющие разрешать любые конфликты.

В работе [18] предложена объектно-ориентированная модель - Dual Model, которая разделяет семантику и структуру объектных баз данных. Это происходит за счет разделения классов – описывающих семантику, и объектных типов – описывающих структуру. Интеграция схем баз данных основывается на обобщении: если два класса должны быть интегрированы, создается общий суперкласс для этих двух классов. Однако если эти классы имеют различную семантику, то невозможно найти их общий суперкласс.

Dual Model позволяет интегрировать два семантически разных класса, потому что один объектный тип может соответствовать нескольким семантически разным классам. Структурная интеграция в диссертационной работе осуществляется посредством определения общего объектного типа для двух соответствующих классов и отображения атрибутов объектного типа в атрибуты каждого из соответствующих классов.

методологию, сфокусированную на разрешении структурных конфликтов, включая конфликт, когда класс соответствует атрибуту, в ER-модели (EntityRelationship Model). Подход может быть применен также к объектноориентированной и реляционной моделям. Он основан на установлении соответствий между путями. Если из двух соответствующих путей хотя бы один имеет длину 1, то в интеграционную схему включается только один путь, имеющий большую длину. В случае, когда оба пути имеют длину больше 1, они оба включаются в интеграционную схему. При этом соответствие путей выражается только посредством ограничений в интеграционной схеме, вместо того, что бы вывести соответствующую интеграционную схему вместе с правилами отображения. Более того, семантика таких ограничений на соответствия между различными путями остается неопределенной.

В работах [17, 25] предлагается методология интеграции схем, основанная на понятии унификации схем. Для разрешения конфликтов между пересекающимися частями схем вводится набор операций приращения (augmentation), которые преобразуют схемы без потери информации. Интеграция схем осуществляется последовательным применением данной операции. Операция приращения основана на применении заданного набора правил соответствия, как между одиночными путями, так и между деревьями (множества путей).

преобразований представлен в [1]. В данном подходе используются rewrite rules осуществляется посредством определения набора rewrite rules. Каждое такое правило имеет вид rew(pattern expression). Когда такое правило применяется к множеству значений подходящего типа, происходит попытка связывания паттерна для каждого значения в этом множестве. Результатом правила является множество значений выражения соответствующих удачному связыванию паттерна.

В диссертационной работе предлагается разрешение конфликтов основано на комбинации этих двух подходов. Функции разрешения конфликтов задаются на языке предикативных спецификаций (язык логики предикатов первого порядка). Данный язык позволяет задавать функции для разрешения любых конфликтов.

Для разрешения структурных конфликтов применяется подход, основанный на применения набора правил структурных преобразований.

Этот подход позволяет автоматизировать процесс поиска и разрешения данного вида конфликтов между схемами спецификаций требований и конкретных компонентов.

спецификациями представлено в Главе 3.

Выявление фрагментов компонентов и их композиция в спецификации уточняющие спецификации требований конструирования основан на выявлении фрагментов спецификаций существующих компонентов и их дальнейшая композиция, уточняющая спецификацию требований. Для этого используются операции над типами, ведущими к трансформации их спецификаций – операции декомпозиции и композиции.

Исследования в области решеток типов и соответствующих алгебр имеет весьма продолжительную историю. Как правило, всегда имеется стремление к достижению компромисса между разумной выразительностью спецификаций и разрешимостью. В композиционном методе разрешимость приносится в жертву ради достижения полноты спецификаций. Благодаря полноте спецификаций, достигается хорошо обоснованный способ идентификации общих фрагментов спецификаций типов, обеспечивающей возможность их адекватной композиции и повторного использования.

Mili, Mili, Mittermeir спецификаций компонентов как информационно-поисковой системы.

Проблема поиска компонентов рассматривается узко - для компонентовфункций, представляемых отношениями, содержащими все допустимые пары входных/выходных значений функций. Порядок на основе отношения уточнения, заданный на множестве функций, имеет свойства решетки.

Решетка формируется посредством операций join и meet на отношениях, информацию (общую информацию), содержащуюся в таких отношениях.

Zaremski, Wing [53] предложили способ сопоставления сигнатур операций как механизм поиска спецификаций программных компонентов в их репозитории. Эту работу планируется расширить на случай представления спецификаций функций их пред- и пост- условиями. Отношение подтипа в предлагаемом проекте трактуется аналогично Liskov, Wing [30].

В работах Thalheim [46, 47] предлагает подход к созданию схем больших баз данных на основе композиции более мелких компонентов. Для такой композиции компонентов используются 6 основных операций:

композиция посредством типов-мостов; композиция посредством вложенных типов; композиция посредством добавления типов, поддерживающих этапы жизни объектов; композиция посредством добавления ортогональных измерений, таких как время, информация о качестве, и мета-характеристики;

композиция посредством добавления записей об использовании объектов;

композиция посредством добавления средств поддержки многоверсионности.

Известные методы компонентно-базированного проектирования (например, JavaBeans) конструируют агрегаты компонентов иначе, соединяя порты компонентов друг с другом, или рассматривая их взаимодействие на основе контрактов [31].

Используемый в диссертационной работе подход основан на исчислении спецификаций [24], разработанном в рамках проекта Синтез.

Согласно этому исчислению, основной операцией декомпозиции является операция взятия редукта типа. Редукты являются базисом для дальнейшей композиции с целью получения спецификации уточняющую спецификацию требований.

Композиция выявленных фрагментов (редуктов) в спецификации, уточняющие спецификации требований, осуществляется посредством применения операций композиции спецификаций типов (операции meet и join) и посредством конструирования взглядов над классами.

Подробное описание процесса выявление фрагментов компонентов и их композиция в спецификации уточняющие спецификации требований представлено в Главе 4.

1.3.3 Особенности композиционного подхода к проектированию ИС Основными отличительными особенностями [23] предлагаемого в диссертационной работе композиционного подхода к проектированию ИС на основе интероперабельных сред информационных компонентов по сравнению с известными методами ОАП и методами компонентнобазированного проектирования являются:

использование полных спецификаций, обеспечивающих корректность применения существующих компонентов в разрабатываемых системах;

наличие репозитория (возможно распределенного) полных спецификаций существующих компонентов;

поиск в репозитории компонентов, релевантных спецификации требований;

выявление фрагментов компонентов, которые могли бы служить уточнением соответствующих фрагментов спецификации требований;

различных конфликтов между спецификациями компонентов и требований;

обеспечение композиции повторно используемых фрагментов в спецификацию, уточняющую спецификацию требований;

поддержка доказательства правильности построенных уточняющих спецификаций с использованием формальных методов;

конструирование реализации информационной системы в среде существующими компонентами в Интернет (Интранет);

возможность использования разработанного подхода для других платформ, например Web Services [13].

1.4 Пример композиционного проектирования ИС В дальнейшем, основные результаты диссертационной работы будут демонстрироваться на примере проектирования ИС Исследовательского (Индустриальной Лаборатории и Университетских Грантов).

Спецификация требований ИС Исследовательского Фонда В проектируемой ИС основной упор делается на управление финансами для научных исследований. Разрабатываемый исследовательский фонд управляет финансами, направленными на исследовательские проекты.

подготавливает заявку и регистрирует ее в фонде для получения гранта.

Данная группа составляет консорциум. Фонд назначает экспертов для оценки заявок и принимает решение о поддержке заявок.

Рис. 1.2 UML спецификация классов ИС исследовательского фонда На Рис. 1.2 показан фрагмент спецификации требований ИС исследовательского фонда в нотации UML.

Спецификация компонента Индустриальная Лаборатория Компонент Индустриальная Лаборатория ориентирован на оценку и выбор индустриальных проектов из предлагаемых заявок. Предварительный выбор делается специализированным советом на основе оценок, полученных от экспертов. Окончательное решение о принятии проектов осуществляется техническими секретарями, ответственными за предварительную проверку поступающих заявок, выбор экспертов, сбор экспертных оценок, подготовку совета, уведомление руководителя проекта.

-agency_name : string -starting_date : time -rejection_date : time -project_starting_date : time -termination_date : time Рис. 1.3 UML спецификация классов компонента Индустриальная Индустриальная Лаборатория в нотации UML.

Спецификация компонента Университетские Гранты Данный компонент содержит информацию обо всех исследовательских проектах в университете, как уже поддержанных грантами, так и новых, еще не принятых, проектах. Оценка новых проектов осуществляется экспертами в принимается советом в соответствующей научной области.

Рис. 1.4 UML спецификация классов компонента Университетские гранты Университетские Гранты в нотации UML.

Спецификация требований к ИС Исследовательского Фонда и спецификации компонентов будут разворачиваться постепенно по мере введения необходимых понятий в главах 2, 3 и 4.

1.5 Выводы по главе Анализ текущего состояния технологических приемов проектирования систем из компонентов и исследований в этой области показывает, что в интероперабельных в контексте спецификации требований, и уточняющую спецификацию требований. Показано, что для обеспечения возможности конструирования ИС из компонентов необходимо:

1. в целях достижения семантической интероперабельности компонентов создать алгоритмы онтологической интеграции контекстов спецификации требований и компонентов и поиска компонентов, онтологически релевантных спецификации требований в таком интегрированном контексте;

2. в целях сокращения различий в спецификации требований и спецификациях релевантных им компонентов, создать алгоритмы разрешения конфликтов между спецификациями компонентов и спецификациями требований;

3. в целях конструирования композиции фрагментов спецификаций компонентов, уточняющей спецификацию требований, создать алгоритмы выявления фрагментов компонентов, которые могли бы служить уточнением соответствующих фрагментов спецификации спецификацию, уточняющую спецификацию требований.

рассматриваются в Главах 2,3,4, соответственно, а их программная реализация – в Главе 5.

Глава 2 Поиск релевантных спецификаций При проектировании ИС из готовых компонентов возникает проблема поиска элементов (классов, типов, атрибутов, функций) компонентов, информационных компонентов и их фрагментов, семантически релевантных спецификации требований, служит онтологическая модель [9, 10].

2.1 Основные понятия Одной из основных проблем проектирования ИС из компонентов разрабатываться для разных предметных областей со специфичными для разрабатываться в своем понятийном контексте. Для описания контекстов в диссертационной работе используется онтологический подход.

По определению Томаса Грубера “под термином онтология понимается совокупности понятий и отношений, определяющих контекст для агента или группы агентов” [19]. Агентом может выступать как человек, так и компьютер. В диссертационной работе в качестве агентов выступают программные или информационные компоненты и спецификация требований Онтологическое понятие отражает существенные свойства, связи и отношения класса объектов реального мира, воспринимаемых агентами в данной предметной области.

используются онтологические спецификации, задающие определения понятий предметной области и связей между ними.

заключается в их определении в виде словаря понятий предметной области, отношений между ними и накладываемых на них ограничений.

В диссертационной работе спецификация понятия ограничивается его словарным описанием на естественном языке. При этом рассматриваются следующие ассоциации между понятиями: обобщения/специализации и позитивные ассоциации.

Онтологический контекст определяет онтологическое связывание для компонентов. Элементы спецификации компонентов связываются с соответствующими им онтологическими понятиями. Использование близких по смыслу онтологических спецификаций в разных компонентах является необходимой предпосылкой корректной взаимной интерпретации элементов семантической интероперабельности компонентов.

В работе онтологические спецификации используются для поиска релевантных элементов спецификаций требований и компонентов. Элемент спецификации требований того же вида (класс, тип, атрибут, функция, параметр), если между соответствующими им онтологическими понятиями обобщения/специализации.

Поскольку спецификация требований и каждый компонент могли разрабатываться с использованием разных онтологических спецификаций, возникает задача интеграции онтологий компонентов и онтологии спецификации требований. Для этого необходимо установить ассоциации между онтологическими понятиями спецификации требований и компонентов.

Для решения этой задачи вводится общая онтология. Общая онтология содержит онтологические понятия, характерные для конкретной предметной области. Эксплуатация такой онтологии предполагает согласованное понимание ее понятий и отношений. В этом случае отображение онтологических понятий спецификации требований и компонентов в понятия общей онтологии позволит находить соответствия между ними.

Предполагается, что существует множество общих онтологических модулей для различных предметных областей. При создании онтологии спецификации требований разрабатываемой ИС эксперт может использовать 2 варианта.

При первом варианте эксперт использует существующую общую онтологию предметной области, близкую к той, в рамках которой разрабатывается ИС. При этом эксперт может добавлять новые понятия, характерные для разрабатываемой ИС.

При втором варианте эксперт разрабатывает онтологию спецификации требований независимо от общей онтологии. Общая онтология выбирается по-возможности близкой к предметной области ИС.

Диссертационная работа ориентирована на второй вариант, как более общий. Использование первого варианта упрощает процесс установления связей между понятиями онтологии спецификации требований и общей онтологии.

Онтологии компонентов могли разрабатываться с использованием одного из перечисленных вариантов. При первом варианте онтология компонента могла разрабатываться как в терминах той же общей онтологии, что и спецификация требований, так и в терминах совершенно другой онтологии.

В диссертационной работе рассматривается второй вариант, как более общий.

При использовании общей онтологии алгоритмы поиска онтологически релевантных элементов спецификации требований и компонентов включают:

алгоритмы отображения понятий спецификации требований (и компонентов) в понятия общей онтологии.

При этом устанавливаются связи между понятиями на основе функций алгоритмы установления ассоциаций между понятиями спецификации требований и компонентов на основе композиции ассоциаций между Понятия связываются, если существует путь из понятия спецификации требований в понятие компонента;

алгоритмы установления ассоциаций между элементами схем спецификации требований и компонентов.

Элементы спецификаций компонентов онтологически релевантны элементам спецификации требований, если между соответствующими им онтологическими понятиями установлена позитивная ассоциация, или ассоциация обобщения/специализации.

2.2 Спецификация онтологий на языке СИНТЕЗ Онтологическая спецификация информационного компонента хранится в отдельном онтологическом модуле. Онтологический модуль представляет собой набор спецификаций онтологических понятий компонента.

Спецификация онтологического модуля на языке СИНТЕЗ выглядит следующим образом:

in: module;

class_specification: { ассоциативного графа, вершины которого соответствуют понятиям, а ребра – бинарным ассоциациям между понятиями. В диссертационной работе используются следующие два вида ассоциаций [6]:

(подпонятие) с более общим понятием (суперпонятием). Другими словами, множество объектов характеризуемых подпонятием, является подмножеством множества объектов характеризуемых суперпонятием.

Ассоциация специализации является обратным ассоциации обобщения;

позитивная ассоциация: Позитивная ассоциация связывает понятия, которые могут рассматриваться как синонимы в некотором контексте.

Как и в реальной жизни, где семантика понятий может варьироваться даже в пределах конкретной области, ассоциации между понятиями являются характеризующий “силу” ассоциации и варьирующийся от 0 до 1.

Спецификация онтологических понятий на языке СИНТЕЗ выглядит следующим образом:

in: concept;

positive:{set; type_of_element:{struct; concept, real}} super: {set; type_of_element:{struct; concept, real}} Выделяются три вида онтологических модулей:

содержит спецификации онтологических понятий разрабатываемой спецификации онтологических понятий существующего компонента.

Общий Онтологический Модуль (ООМ) содержит спецификации онтологических понятий общей онтологии для конкретной предметной области. ООМ служит для связывания понятий спецификации требований и компонентов.

Пример спецификации онтологий Ниже приведены примеры спецификаций фрагментов общего онтологического модуля, онтологических модулей спецификации требований Исследовательского Фонда и компонента Индустриальной Лаборатории.

Пример спецификации Общего Онтологического Модуля на языке СИНТЕЗ выглядит следующим образом:

{common_ontology_module;

in: module;

{proposal;

positive: {{project, 0.4}};

def: {“a research project proposal or submission organizations for evaluation”} {project;

positive: {{proposal, 0.4}, {research, 0.6}};

def: {“a scientific or study research accepted to be {research;

positive: {{project, 0.6}};

def: {“scientific research activity”} {budget;

def: {“money, funds, grant, budget limiting the {organization;

def: {“a group of people joint to work together”}...

Данную спецификацию можно представить в виде графа, в котором понятия являются вершинами, а ассоциации между понятиями – ребрами.

Пример такого графа показан на Рис. 2.1.

Рис. 2.1 Пример спецификации общего онтологического модуля Спецификация фрагмента онтологического модуля спецификации требований Исследовательского Фонда на языке СИНТЕЗ выглядит следующим образом:

{funding_agency_ontology_module;

in: module;

{proposal;

def: {“a research and development activity of an {budget;

def: {“a quantity of money limiting the spending”} {organization;

def: {“a group of people working together”}...

Спецификация фрагмента онтологического модуля компонента Индустриальная Лаборатория на языке СИНТЕЗ выглядит следующим образом:

{industrial_labs_ontology_module;

in: module;

{submission;

def: {“a specification of a scientific study or {req_money;

def: {“required money or requested grants”} {project;

def: {“an accepted scientific study or research”} {company;

def: {“a group of employees joint for special work”}...

2.3 Функции корреляции Функции корреляции используются для установления ассоциаций между понятиями разных модулей. Предлагаемый подход основан на определении онтологических понятий на естественном языке и вычислении коэффициентов корреляции между понятиями, базируясь на этих определениях. Идея такого подхода принадлежит Г. Сэлтону ([40, 41]).

Пусть X и Y два онтологических понятия. Vx и Vy – векторы, состоящие из слов описывающих понятия X и Y, соответственно. Эти векторы соответствующего понятия на естественном языке. V – вектор, состоящий из объединения слов из векторов Vx и Vy. Вектор Cx строится следующим образом: Cxi = 1 если вектор Cx содержит слово Vxi и Cxi = 0 в противном случае. Функция позитивной корреляции определяется следующим образом:

sim(X,Y) = (Cx,Cy) / |Cx|*|Cy| где (Cx,Cy) – скалярное произведение векторов Cx и Cy, |Cx| и |Cy| длины векторов.

Эта функция определяет косинус угла между векторами. Для двух эквивалентных векторов угол равен 0 и косинус равен 1; для двух векторов, не имеющих общих слов, угол равен 90 и косинус равен 0. Таким образом, чем больше одинаковых слов в определениях понятий, тем выше коэффициент sim(X,Y).

коэффициент (т.е. с большой вероятностью понятия не являются конформными) вводится пороговое значение. Если значение sim(X,Y) больше некоторого заданного порогового значения K, то понятия X и Y связываются позитивной ассоциацией с коэффициентом корреляции равным этому значению, в противном случае понятия считаются не связанными.

Но описанная функция применима только для вычисления позитивных обобщения/специализации. К тому же она плохо работает в случаях, когда количество слов в одном из векторов намного превышает количество слов в другом. Для выявления таких случаев используются следующие функции:

r(X,Y) = i(min(Cxi,Cyi)) / |Cx| r(Y,X) = i(min(Cxi,Cyi)) / |Cy| Если r(X,Y) и r(Y,X) меньше некоторого заданного порогового значения K, то понятия X и Y не связаны друг с другом. Если r(X,Y) и r(Y,X) больше K, то они связаны позитивной ассоциацией с коэффициентом корреляции равным минимальному из этих значений. Если r(X,Y) больше K, а r(Y,X) меньше K, тогда понятие X является суперпонятием понятия Y, другими словами между понятиями X и Y устанавливается ассоциация обобщения.

Коэффициент корреляции при этом равен значению r(X,Y). И наоборот, если r(X,Y) меньше K, а r(Y,X) больше K, тогда понятие X является подпонятием понятия Y, другими словами между понятиями X и Y устанавливается ассоциация специализации. Коэффициент корреляции при этом равен значению r(Y,X).

2.4 Композиция ассоциаций Связи между понятиями могут задаваться не только явно посредством ассоциаций, но и неявно посредством композиции ассоциаций. Два понятия являются связанными, если существует путь (состоящий из ассоциаций) от одного понятия в другое. Вид и коэффициент этой связи определяется с помощью следующих таблиц:

Вид пути, состоящий из двух ассоциаций, определяется с помощью специализации являются транзитивными, таким образом, их композиции дают те же самые виды ассоциаций. Композиция позитивной ассоциации с ассоциацией обобщения (специализации) образуют позитивную связь.

Композиция ассоциаций обобщения и специализации образуют (менее специфичную) позитивную связь.

участвующих в нем. Для пути, состоящем из двух ассоциаций, коэффициент вычисляется согласно таблице 2.2. Для вычисления коэффициентов используются различные t-нормы (triangular norms) [16, 27] для пересечения нечетких множеств.

Определение 2.1 t-нормы для пересечения нечетких множеств 1(a,b) = max(0, a+b-1) 3(a,b) = min(a, b) Надо заметить, что 1 < 2 < 3.

ассоциацией обобщения берется наиболее пессимистическую t-норму 1. Это связано с задачей поиска компонентов, уточняющих спецификацию требований и, следовательно, для понятия спецификации требований (первое понятие в пути) ищется более общее понятие компонента (последнее понятие в пути). Нейтральная t-норма 2 используется для композиции позитивных ассоциаций между собой и с ассоциациями обобщения. И, наконец, наиболее оптимистическую t-норму 3 используется для композиций транзитивных ассоциаций обобщения и специализации, соответственно, друг с другом.

Разные t-нормы не являются взаимно ассоциативными, т.е. (ab)c (что соответствует 12) не всегда равно a(bc) (21). Другими словами, коэффициент корреляции пути зависит от порядка вычисления. Для преодоления асимметрии вводится порядок вычисления, как показано в таблице 1.3. Тем самым, в первую очередь вычисляются композиции всех непосредственно связанных позитивных ассоциаций, композиции, когда за ассоциацией обобщения следует ассоциация специализации, или наоборот.

Затем вычисляются композиции непосредственно связанных ассоциаций обобщения (аналогично для ассоциаций специализации). И в последнюю очередь, вычисляются композиции ассоциаций обобщения и специализации с позитивными ассоциациями.

2.5 Процесс поиска релевантных элементов спецификаций Процесс поиска релевантных элементов спецификаций требований и компонентов состоит из трех этапов:

отображения понятий спецификации требований (и компонентов) в понятия общей онтологии;

установление ассоциаций между понятиями спецификации требований и компонентов;

установление ассоциаций между элементами схем спецификации требований и компонентов.

Отображения понятий спецификации требований (компонентов) в понятия общей онтологии Алгоритм Отображение понятий спецификации требований (и компонентов) в понятия общей онтологии Данные: онтологический модуль понятий спецификации требований (компонентов), общий онтологический модуль.

Результат: множество понятий онтологического модуля спецификации требований (компонентов) с установленными связями с понятиями общего онтологического модуля.

Процесс:

1. задается пороговое значение K 2. для каждого онтологического понятия создается вектор дескрипторов.

Он получается из описания понятия на естественном языке после исключения служебных частей речи (stop words) и приведения остальных слов к нормальной форме4;

онтологического модуля:

{proposal;

in: concept;

positive: {{project, 0.4}};

def: {“a research project proposal or submission descriptors: {“research”, “project”, “proposal”, “submission”, “present”, “organization”, {project;

in: concept;

positive: {{proposal, 0.4}, {research, 0.6}};

def: {“a scientific or study research accepted to be descriptors: {“scientific”, “study”, “research”, 4 В диссертационной работе рассматриваются описания на английском языке. Для использования описаний на русском языке возникают проблемы морфологического анализа. Эти проблемы решаются рядом известных программ морфологического анализа и в работе не рассматриваются.

“accept”, “realize”} 3. для каждого онтологического понятия спецификации требований (компонентов) CS и для каждого понятия общего онтологического модуля CC выполняется следующее:

4. вычисляется функция позитивной корреляции sim между понятиями CS 4.1 Если sim(СS, СC) > K, тогда устанавливается позитивная ассоциация между выбранными понятиями с вычисленным коэффициентом;

Пример установления позитивной связи на основе функции для спецификации требований (первое понятие – понятие спецификации требований, второе – понятие общего онтологического модуля):

sim(proposal, proposal) = 0.2981 (0.4 0.2222) sim(budget, budget) = 0.6123 (0.75 0.5) sim(organization, organization) = 0.8944 (1 0.8) для компоненты Индустриальная Лаборатория:

sim(submission, proposal) = 0.2108 (0.2 0.2222) sim(project, proposal) = 0.1666 (0.25 0.1111) sim(project, project) = 0.8944 (1 0.8) sim(req_money, budget) = 0.4082 (0.5 0.3333) sim(company, organization) = 0.6 (0.6 0.6) 5. вычисляются функции корреляции r между понятиями CS и CC.

5.1 Если r(CS, CC) > K и r(CC, CS) > K, тогда устанавливается позитивная ассоциация между понятиями с коэффициентом равным минимальному из этих значений;

5.2 Если r(CS, CC) > K и r(CC, CS) < K, тогда устанавливается ассоциация обобщения между понятиями CS и CC (понятие CS является суперпонятием понятия CC) с коэффициентом равным 5.3 Если r(CS, CC) < K и r(CC, CS) > K, тогда устанавливается ассоциация специализации между понятиями CS и CC (понятие CS является подпонятием понятия CC) с коэффициентом равным r(CC, 5.4 Если r(CS, CC) < K и r(CC, CS) < K, тогда выбранные понятия являются не связанными.

Пример установления связей на основе функции корреляции r для компоненты Индустриальная Лаборатория:

r(submission, proposal) = 0. r(proposal, submission) = 0. установлена позитивная связь с коэффициентом 0. r(project, proposal) = 0. r(proposal, project) = 0. установлена связь обобщения с коэффициентом 0. 6. конец циклов;

7. подтверждение экспертом найденных ассоциаций.

Установление ассоциаций между понятиями спецификации требований и компонентов Вычисления основаны на алгоритме поиска кратчайшего пути в графе.

Отличие состоит в том, что нам необходимо найти пути с максимальным коэффициентом (максимальные пути), вычисляемыми по таблицам 1 и 2.

Пути между понятиями представляются в виде матрицы W[n,n]. w[i,j] – вес пути между понятиями i и j. Матрица K[n,n] – содержит виды путей между понятиями.

Поскольку общий онтологический модуль не изменяется, матрица коэффициентов пути (расстояний) COMW и матрица видов пути между понятиями общего онтологического модуля COMT строятся заранее и один раз. Это позволяет существенно оптимизировать процесс вычисления коэффициентов и видов путей между понятиями спецификации требований и компонентов.

Алгоритм 2.2 Конструирование матриц коэффициентов и видов путей между понятиями общего онтологического модуля.

Данные: W[n,n] – матрица коэффициентов связей между понятиями, K[n,n] матрица видов связей между понятиями, n – количество понятий. Эти матрицы задаются следующим образом:

если между понятиями i и j есть позитивная связь с коэффициентом k, то W[i,j] = k, W[j,i] = k, K[i,j] = ‘p’, K[j,i] = ‘p’;

если понятие i является подпонятием j, т.е. между понятиями есть связь понятие-подпонятие с коэффициентом k, то W[i,j] = k, W[j,i] = k, K[i,j] иначе W[i,j] = 0, W[j,i] = 0, K[i,j] = ‘-’, K[j,i] = ‘-’.

На Рис. 2.2 показаны данные матрицы для используемого примера.

Результат: COMW[n,n] – матрица коэффициентов максимальных путей между понятиями общего онтологического модуля, COMK[n,n] – матрица видов максимальных путей между понятиями общего онтологического модуля.

Рис. 2.2 Пример матриц (а) коэффициентов и (б) видов связей между Процесс:

COMW[n,n] – матрица коэффициентов максимальных путей между понятиями, COMK[n,n] – матрица видов максимальных путей между 2. для m=1..n выполняется следующее:

3. для i=1..n выполняется следующее:

4. для j=1..n выполняется следующее:

5. COMW[i,j] = max(COMW[i,j], w(COMW[i,m], COMW[m,j])), функция w определяется из таблицы 6. COMK[i,j] = k(COMK[i,m], COMK[m,j]), функция k определяется из 7. конец циклов Примеры полученных матриц показаны на Рис. 2.3.

Рис. 2.3 Пример матриц (а) коэффициентов и (б) видов путей между Алгоритм 2.3 Установление ассоциаций между понятиями спецификации требований и компоненты состоит в следующем Данные: COMW[n,n] и COMK[n,n] – матрицы коэффициентов и видов максимальных путей между понятиями общего онтологического модуля.

онтологического модуля APPW[m,n] и APPK[m,n] (RESW[n,l] и RESK[n,l]), m (l) – количество понятий спецификации требований (компонента). Они строятся на основе вычисления функций корреляции на предыдущем этапе.

Результат: WEIGHT[m,l] и KIND[m,l] – матрицы коэффициентов и видов спецификации требований и понятиями онтологического модуля компонента.

Процесс:

1. WEIGHT = 0, KIND= 2. для i=1..k выполняется следующее:

3. для j=1..l выполняется следующее:

4. для p=1..n выполняется следующее:

5. для q=1..n выполняется следующее:

6. WEIGHT[i,j] = max(WEIGHT[i,j], w(APPW[i,p], w(COMW[p,q], RESW[q,j]))), функции w определяется из таблицы 7. KIND[i,j] = k(APPK[i,p], k(COMK[p,q], RESK[q,j])), функция k определяется из таблицы 8. конец циклов 9. подтверждение экспертом найденных ассоциаций Пример установления позитивной связи между понятиями спецификации требований и компонента Индустриальная Лаборатория:

WEIGHT(proposal, submission) = APPW(proposal, proposal) COMW(proposal, proposal) 2 RESW(proposal, submission) на основе композиции ассоциаций WEIGHT(proposal, project) = max((APPW(proposal, proposal) 2 COMW(proposal, project) 2 RESW(project, project)), (APPW(proposal, proposal) 2 COMW(proposal, proposal) 2 RESW(proposal, project))) = max((0.3 2 0.4 2 0.89), (0.3 2 1.0 2 0.25)) = max(0.11, 0.08) = 0. Установление ассоциаций между элементами схем спецификации требований и компонентов Алгоритм Установление ассоциаций между элементами схем спецификации требований и компонентов.

Данные: WEIGHT[m,l] – матрица коэффициентов связей между понятиями спецификации требований и понятиями компонента, ElementsS – множество элементов спецификации требований, ElementsR – множество элементов спецификации компонента Результат: RelevantElementsList - список возможно релевантных элементов.

Процесс:

1. для каждого элемента схемы спецификации требований ES из ElementsS;

2. для каждого элемента схемы компонента ER из ElementsR;

3. берем онтологическое понятие CS соответствующее элементу ES, и онтологическое понятие CR соответствующее элементу ER;

4. если WEIGHT[CS, CR]>0, то пара элементов (CS ~ CR) включается в список релевантных элементов RelevantElementsList;

5. конец циклов;

6. подтверждение экспертом релевантности между элементами.

Пример: на основе позитивной связи между понятиями спецификации требований (proposal) и компонента Индустриальная Лаборатория (project) устанавливается ассоциация между типами Proposal и Project.

2.6 Пример поиска релевантных спецификаций В данном разделе будет продемонстрирована работа представленных алгоритмов на примере проектирования ИС Исследовательского Фонда, описанного в Главе 1.

2.6.1 Спецификации онтологических понятий Онтологическая спецификация ИС Исследовательского Фонда Исследовательского Фонда, представленной в Главе 1, в каноническом языке выглядит следующим образом:

{o_proposal;

in: concept;

def: {"offered research that may be accepted or rejected"};

{o_proposal_name;

in: concept;

def: {"a name, title of the proposal"};

{o_proposal_budget;

in: concept;

def: {"a amount of money limiting the spending"};

{o_organization;

in: concept;

def: {"a group of persons working together; company"};

Онтологическая спецификация компонента Индустриальная Лаборатория Фрагмент спецификации онтологических понятий компонента Индустриальная Лаборатория, представленного в Главе 1, в каноническом языке выглядит следующим образом:

{o_submission;

in: concept;

def: {"a specification of a scientific study or research passed by a group of employees for a review for getting grant"};

{o_submission_name;

in: concept;

def: {"a title of study or research"};

{o_submission_req_money;

in: concept;

def: {"required money or requested grants"};

{o_company;

in: concept;

def: {"a group of employees joint for special work"};

{o_project;

in: concept;

def: {"an accepted scientific study or research"};

Онтологическая спецификация компонента Университетские Гранты Фрагмент спецификации онтологических понятий компонента Университетские Гранты, представленного в Главе 1, в каноническом языке выглядит следующим образом:

{o_university_research;

in: concept;

def: {"scientific research proposed by an association of organizations to be reviewed for getting a grant"};

{o_university_research_name;

in: concept;

def: {"a name of the proposal"};

{o_university_research_req_funding;

in: concept;

def: {"necessary money for spending for the research"};

{o_organization;

in: concept;

def: {"a group of people working together"};

{o_university;

in: concept;

def: {"an organization specialized on science and education"};

Спецификация Общего Онтологического Модуля Для согласования онтологии спецификации требований и онтологий компонентов используется общая онтология конкретной предметной области. В рассматриваемом примере в качестве общей онтологии используется онтология области поддержки исследовательских грантов.

Фрагмент спецификации онтологических понятий Общего Онтологического Модуля в каноническом языке выглядит следующим образом:

{university;

in: concept;

def: {"an institution of highest learning"};

hypernym: {{organization, 0.5}};

{organization;

in: concept;

def: {"a group of persons organized for some work; company"};

hypernym: {{actor, 0.6}, {university, 0.5}, {agency, 0.5}, {school, 0.5}};

positive: {{consortium, 0.5}, {association, 0.5}, {branch, 0.4}, {employee, 0.3}};

{agency;

in: concept;

def: {"an organization that provides some service for another"};

hypernym: {{organization, 0.5}};

{association;

in: concept;

def: {"an organization or a group of people with a common purpose"};

positive: {{quantity, 0.3}, {organization, 0.5}, {consortium, 0.9}};

{name;

in: concept;

def: {"words by which smth. is designated or known"};

positive: {{entity, 0.9}};

{budget;

in: concept;

def: {"total sum of money for some purpose"};

positive: {{fund, 0.6}, {grant, 0.7}, {submission, 0.3}};

{currency;

in: concept;

def: {"that which is a medium of exchange; money"};

positive: {{money, 0.8}};

{fund;

in: concept;

def: {"a stock of money for some purpose"};

positive: {{money, 0.8}, {budget, 0.6}};

{grant;

in: concept;

def: {"that which is granted, as a privilege, or right, or money"};

positive: {{budget, 0.7}, {money, 0.6}, {proposal, 0.4}};

{money;

in: concept;

def: {"coins, paper money, or demand deposits"};

positive: {{currency, 0.8}, {grant, 0.6}, {fund, 0.8}};

{proposal;

in: concept;

def: {"offering smth. for acceptance, or performance"};

hypernym: {{plan, 0.7}};

positive: {{grant, 0.4}, {submission, 0.8}};

{project;

in: concept;

def: {"a schema or plan that will be done"};

hypernym: {{plan, 0.8}};

positive: {{object, 0.5}};

{submission;

in: concept;

def: {"something that is submitted"};

positive: {{proposal, 0.8}, {budget, 0.3}, {object, 0.5}, {field, 0.5}, {submit, 0.9}};

2.6.2 Отображение понятий спецификаций компонентов/требований в понятия общей онтологии Список релевантных понятий спецификации требований и общей онтологии Список релевантных понятий спецификации разрабатываемой ИС и общей онтологии, полученный на основе алгоритма 2.1, выглядит следующим образом:

o_proposal ~ research, sim=1.0, o_proposal ~ proposal, sim=1.0, o_proposal_name ~ name, sim=1.0, o_proposal_name ~ proposal, sim=0.3272039, o_proposal_budget ~ budget, sim=1.0, o_proposal_budget ~ grant, sim=1.0, o_proposal_budget ~ money, sim=0.14395054, o_organization ~ organization, sim=1.0, Список релевантных понятий спецификации компонента Университетских Грантов и общей онтологии Список релевантных понятий спецификации компонента Университетских Грантов и общей онтологии, полученный на основе алгоритма 2.1, выглядит следующим образом:

o_university_research ~ research, sim=1.0, o_university_research_name ~ name, sim=1.0, o_university_research_req_funding ~ fund, sim=1.0, o_university_research_req_funding ~ money, sim=0.18622862, o_organization ~ organization, sim=1.0, o_university ~ university, sim=1.0, Список релевантных понятий спецификации компонента Индустриальной Лаборатории и общей онтологии Список релевантных понятий спецификации компонента Индустриальной Лаборатории и общей онтологии, полученный на основе алгоритма 2.1, выглядит следующим образом:

o_submission ~ submission, sim=1.0, o_submission_name ~ research, sim=0.198379, o_submission_name ~ name, sim=1.0, o_submission_req_money ~ grant, sim=0.51475745, o_submission_req_money ~ money, sim=1.0, o_company ~ organization, sim=1.0, o_project ~ project, sim=1.0, o_project.grant ~ grant, sim=1.0, 2.6.3 Установление ассоциаций между понятиями спецификации требований и компонентов Список ассоциаций между онтологическими понятиями спецификации требований и компонента Университетские Гранты Список ассоциаций между онтологическими понятиями спецификации требований и компонента Университетские Гранты, полученный на основе алгоритма 2.3, выглядит следующим образом:

o_proposal ~ o_university_research, o_proposal_name ~ o_university_research.name, o_proposal_budget ~ o_university_research_req_funding, o_organization ~ o_organization, o_organization ~ o_university, Список ассоциаций между онтологическими понятиями спецификации требований и компонента Индустриальная Лаборатория Список ассоциаций между онтологическими понятиями спецификации требований и компонента Индустриальная Лаборатория, полученный на основе алгоритма 2.3, выглядит следующим образом:

o_proposal ~ o_submission, o_proposal.name ~ o_submission_name, o_proposal.budget ~ o_submission_req_money, o_proposal ~ o_project, o_proposal_budget ~ o_project_grant, o_organization ~ o_company, 2.6.4 Список релевантных элементов спецификаций Список релевантных элементов спецификации требований и компонента Университетские Гранты Список релевантных элементов спецификации требований и компонента Университетские Гранты, полученный на основе алгоритма 2. выглядит следующим образом:

Proposal ~ University_research, Proposal.name ~ University_research.name, Proposal.budget ~ University_research.req_funding, Organization ~ Organization, Organization ~ University, Список релевантных элементов спецификации требований и компонента Индустриальная Лаборатория Список релевантных элементов спецификации требований и компонента Индустриальная Лаборатория, полученный на основе алгоритма 2.4 выглядит следующим образом:

Proposal ~ Submission, Proposal.name ~ Submission.name, Proposal.budget ~ Submission.req_money, Proposal ~ Project, Proposal.budget ~ Project.grant, Organization ~ Company, 2.7 Выводы по главе В Главе 2 разработан подход, ориентированный на достижение семантической интероперабельности компонентов при конструировании ИС.

Разработанный подход основан на интеграции онтологических контекстов компонентов и спецификации требований, используя понятие общей онтологии предметной области. Определены алгоритмы, обеспечивающие указанную интеграцию, и поиск в таком интегрированном контексте спецификаций компонентов и их фрагментов, онтологически релевантных спецификации требований.

Представленные алгоритмы обеспечивают поиск семантически релевантных компонентов для использования на последующих шагах конструирования разрабатываемой ИС.

Программная реализация приведенных алгоритмов рассмотрена в Главе требований и компонентов возникают различные конфликты между спецификациями требований и компонентов [9, 10]. Конфликты могут возникать как из-за разных областей применения, так и из-за разного видения разработчиками представления спецификаций одной и той же ИС. Как было показано в Главе 1, подход к диссертационной работе, основан на комбинации двух известных подходов в предопределенных правил структурных преобразований, и применение языка высокого уровня для описания функций разрешения конфликтов. Функции разрешения конфликтов задаются с помощью формул языка СИНТЕЗ. Язык формул является вариантом типизированного языка логики первого порядка.

предопределенные правила. Они устанавливают релевантность путей спецификаций требований и компонентов, и задают правила построения функций разрешения конфликтов.

3.1 Виды конфликтов конфликтов могут быть разбиты на: конфликты значений, структурные конфликты и конфликты поведения.

Структурные конфликты Существуют разнообразные виды структурных конфликтов, в том числе:

конфликт имен;

- использование разных имен для эквивалентных элементов (классов, типов, атрибутов, функций);

Пример: типы Proposal и Submission имеют одинаковый смысл - использование одинаковых имен для различных элементов;

Пример: атрибут name для типов Proposal и Organization имеет абсолютно разный смысл использование различного набора атрибутов;

- отсутствие атрибута типа компонента релевантного атрибуту типа спецификации требований;

Пример: для атрибута contest_type типа Proposal нет релевантного атрибута в типе Submission - наличие вычислимых атрибутов (атрибутов типа спецификации требований, которым нет релевантных атрибутов типа компонента, но которые могут быть вычислены из атрибутов типа компонента);

релевантного атрибута в типе Submission, но он может быть вычислен из атрибутов starting_date и duration использование различного набора параметров функций;

использование различных типов атрибутов (параметров функций);

Примеры: типом атрибута budget является тип integer, а типом релевантного ему атрибута req_money - тип real.

использование различного формата представления атрибутов (параметров функций);

Пример: атрибут starting_date может задаваться в одном случае в виде "день/месяц/год", а в другом в виде "месяц/день/год".

использование разных уровней абстракции представления информации;

Пример: в одном случае адрес задается прямо в типе Organization посредством атрибутов city и street, а в другом случае используется дополнительный тип Address, содержащий эти атрибуты.

использование типов и атрибутов для представления одинаковых понятий.

Пример: адрес организации может задаваться в виде отдельного типа Address с атрибутами city и street, а может в виде строкового атрибута address в самом типе Organization.

Конфликты значений Существуют разнообразные виды конфликтов значений, в том числе:

использование разных отношений на экстенсионалах классов (эквивалентность, включение, пересечение);

множество объектов класса person.

представление атрибутов в различных единицах измерения;

Пример: атрибут budget может задаваться в одном случае в рублях, а в другом в долларах.

использование в релевантных атрибутах разных значений по умолчанию;

использование поддержки null значений с различной семантикой.

Конфликты поведения Существуют разнообразные виды конфликтов поведения, например:

использование различных ключей для релевантных классов;

использование различных утверждений и ограничений целостности, связанных с релевантными атрибутами или типами;

использование различных реализаций методов функций;

3.2 Описание преобразований на языке СИНТЕЗ Разрешение конфликтов на языке СИНТЕЗ задается с помощью функций. Определение функций выглядит следующим образом:

{in: function;

params: {};

raises: {};

входные, '-' – выходные, – входные/выходные параметры. Функции, возвращающие результат в выражениях, должны включать выходной параметр, задаваемый типизированной переменной:

-returns/. Спецификации функций в языке СИНТЕЗ задаются с помощью логических формул. Для задания формул используется вариант типизированного языка логики первого порядка. Каждый предикат, функция, константа и переменная в формулах – типизированы.

В качестве примера рассмотрим конфликт различного набора атрибутов. Имеем 2 релевантных типа Proposal и Submission с разным набором атрибутов:

{Proposal;

in: type;

starting_date: time;

termination_date: time;

{Submission;

in: type;

starting_date: time;

duration: time;

Между атрибутами starting_date типа Proposal и типа Submission конфликтов нет. Атрибуту termination_date типа Proposal нет эквивалентного атрибута в типе Submission, но он может быть вычислен из атрибутов starting_date duration.

следующим образом:

get_termination_date: {in: function;

params: {+s/Submission, -returns/time};

{{ returns = s.starting_date + s.duration }} 3.3 Подход к разрешению структурных конфликтов В этом разделе предлагается подход к разрешению структурных конфликтов на основе поиска релевантных путей спецификаций требования и компонентов. Релевантность путей основывается на правилах структурных преобразований. Предлагаемый подход позволяет автоматизировать процесс поиска и разрешения структурных конфликтов между спецификациями требований и конкретных компонентов.

3.3.1 Основные понятия Для разрешения структурных конфликтов используются понятия связи и пути. Под связью понимается любое прямое соединение между элементами спецификаций. Различаются атрибутная связь (attribute link) между типом и его атрибутом, ссылочная связь (reference link) между двумя типами посредством атрибута-ссылки, связь тип/подтип между подтипом и супертипом. Два элемента могут быть также соединены посредством композиции связей, называемых путем. Понятия связи и пути определяются следующим образом:

Определение 3.1 XY есть связь (простой путь), если имеет место один из ниже перечисленных случаев:

Y является простым атрибутом (типом которого является встроенный тип данных) типа X.

Обозначение: XY (и XY для случая множественного атрибута).

Пример: Proposalname;

тип X содержит атрибут-ссылку a, указывающий на тип Y.

Обозначение: X–aY (и X–aY для случая множественного атрибута).

Пример: Proposal–leaderResearcher;

тип X является подтипом (супертипом) типа Y.

Обозначение: XY (XY).

Пример: ResearcherPerson.

В дальнейшем будем использовать обозначение XY, если не рассматриваем конкретный случай.

Определение 3.2 X1X2...Xn есть путь, если каждая XiXi+1 является связью.

Обозначение: X...Y - любой путь.

Пример: Company–addressAddresscity.

Спецификации компонентов могут быть представлены в виде графа, вершинами которого являются типы и простые атрибуты, а ребрами – связи.

Пример графа, представляющего фрагмент спецификации требований, приведен на Рис. 3.1.

Рис. 3.1 Пример графа фрагмента спецификации требований Определение 3.3 Путь X1...X2 является релевантным пути Y1...Y2, если они удовлетворяют одному из восьми правил структурных преобразований 3.1При установлении релевантности путей рассматриваются только пути, удовлетворяющие следующим условиям.

Определение 3.4 Условия потенциальной релевантности путей полнота Путь X1...X2 может быть релевантным пути Y1...Y2, только если X является релевантным Y1, а X2 – релевантным Y2.

ацикличность Путь X1...X2 может быть релевантным пути Y1...Y2, только если и путь X1...X2, и путь Y1...Y2 не содержат циклы.

минимальность Путь X1...X2 может быть релевантным пути Y1...Y2, если не существует подпуть X3...X4 (Y3...Y4) пути X1...X2 (Y1...Y2) такой, что X3...X4 (Y3...Y4) релевантен произвольному пути Y5...Y6 (X5...X6).

3.3.2 Правила структурных преобразований Правила структурных преобразований устанавливают релевантность путей спецификации требований и компонентов, и задают правила построения функций разрешения конфликтов. Представленные правила структурных преобразований основаны на правилах, описанных в [17, 25, 45].

Правила структурных преобразований в случае деревьев (нескольких путей с одним корнем) Для установления релевантности путей используются следующие правила структурных преобразований.

Обозначение: Несколько путей с одним корнем X0 обозначаются в виде:

X0(X1|X2).

Правило 3.1 Релевантность путей при использовании агрегатного типа Путь X0...X1 релевантен пути Y0...Y1 и путь X0...X2 релевантен пути Y0...Y2, если они удовлетворяют условиям релевантности, заданным в Определении 3.4, и имеют следующий вид:

а) X0(–a1X1|–a2X2) ~ Y0–b3Y3(–b1Y1|–b2Y2) б) X0(X1|X2) ~ Y0–b3Y3(Y1|Y2) При этом функции разрешения конфликтов имеют следующий вид:

get_a1: {in: function;

params: {+y/Y0, -returns/X1};

{{ returns = y.b3.b1 }} get_a2: {in: function;

params: {+y/Y0, -returns/X2};

{{ returns = y.b3.b2 }} get_X1: {in: function;

params: {+y/Y0, -returns/X0.X1};

{{ returns = y.b3.Y1 }} get_X2: {in: function;

params: {+y/Y0, -returns/X0.X2};

{{ returns = y.b3.Y2 }} get_in_city: {in: function;

params: {+y/Company, -returns/Organization.in_city};

{{ returns = y.address.city }} get_in_street: {in: function;

params: {+y/Company, -returns/Organization.in_street};

{{ returns = y.address.street }} Правило 3.2 Релевантность путей с множественными атрибутами и путей с отношениями обобщения Путь X0...X1 релевантен пути Y0...Y1 и путь X0...X2 релевантен пути Y0...Y2, если они удовлетворяют условиям релевантности, заданным в Определении 3.4, и имеют следующий вид:

а) X0(–a1X1|–a2X2) ~ Y0–b3Y3(Y1|Y2) При этом функции разрешения конфликтов имеют следующий вид:

get_a1: {in: function;

params: {+y/Y0, -returns/{set; type_of_elements:X1}};

{{ returns = {s/Y1 | y.b3.contains(s)} }} get_a2: {in: function;

params: {+y/Y0, -returns/{set; type_of_elements:X2}};

{{ returns = {s/Y2 | y.b3.contains(s)} }} staff technical_staff get_staff: {in: function;

params: {+y/Submission, -returns/{set; type_of_elements:Researcher}};

{{ returns = {s/Specialist | y.team.contains(s)} }} get_technical_staff: {in: function;

params: {+y/Submission, -returns/{set; type_of_elements:Technician}};

{{ returns = {s/Tech_specialist | y.team.contains(s)}}} Правило 3.3 Релевантность путей для атрибутов подтипов Путь X0...X1 релевантен пути Y0...Y1 и путь X0...X2 релевантен пути Y0...Y2, если они удовлетворяют условиям релевантности, заданным в Определении 3.4, и имеют следующий вид:

a) X0–a3X3(X1|X2) ~ Y0(Y3–b1Y1|Y4–b2Y2) При этом функции разрешения конфликтов имеют следующий вид:

get_a3: {in: function;

params: {+y/Y0, -returns/{set; type_of_elements:X1}};

{{ returns = {s1/Y1 | Ex s3/Y3 (s3.b1 = s1)} & get_submitted_by: {in: function;

params: {+y/Proposal, -returns/{set; type_of_elements:Organization}};