3. Архитектура средств поддержки композиционного метода

В целом, композиционное проектирование ИС включает этапы планирования требований, анализа, конструирования и реализации:

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

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

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

• Целью этапа реализации является отображения логической структуры системы в физическую реализацию. На этапе реализации происходит конструирование реализации части системы, которая поддерживается обнаруженными компонентами, в среде CORBA как интероперабельной совокупности адаптеров (wrappers) над такими компонентами в Интернет (Интранет). Реализация части системы, которая не поддерживается существующими компонентами, осуществляется с использованием существующих средств проектирования.

Рис. 1 Архитектура прототипа

Композиционный метод является расширением стандартных методов ОАП. Расширение заключается в использовании на этапах планирования требований и анализа онтологических спецификаций компонент и полных спецификаций типов, включая спецификации функций и инвариантов. Этапы конструирования и реализации являются новыми и служат для композиционного проектирования. Их реализации и посвящен прототип на основе языка Java 2 в среде Windows NT 4.0. Для хранения информации используется база метаданных, реализованная в PSE ObjectStore. Спецификации, полученные на этапах планирования требований и анализа при помощи некоторого метода ОАП, загружаются в базу метаданных при посредстве формата CDIF [15]. Для поддержки этапов планирования требований и анализа используется Paradigm Plus [16].

На рисунке 1 показана общая структура прототипа поддерживающего метод композиционного проектирования СИНТЕЗ.

4. Особенности этапа конструирования

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

4.1 Онтологическая интеграция

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

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

{<concept_name>; in: concept; def: {<verbal description>}; positive: {set_of; {struct; concept, real}} super: {set_of; {struct; concept, real}}

}

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

Пусть 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. Таким образом, чем больше одинаковых слов в определениях понятий, тем выше коэффициент 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).

Связи между понятиями могут задаваться не только непосредственно, но и транзитивно. Два понятия являются связанными, если существует путь от одного понятия к другому. Композиции ассоциаций вычисляются используя нечеткие логики на основе подхода, предложенного в [18].

4.1.2 Онтологические модули

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

• Онтологический Модуль Применения (Application Ontology Module - AOM) содержит онтологическую спецификацию разрабатываемого применения.

• Онтологический Модуль Компонента (Resource Ontology Module - ROM) содержит онтологическую спецификацию существующего ресурса.

• Общий Онтологический Модуль (Common Ontology Module - COM)

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

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

4.1.3 GUI для подтверждения отображения понятий компонентов в понятия общего лексикона

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

Рис. 2 GUI для подтверждения отображения понятий компонентов в понятия общего лексикона

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

4.1.4 GUI для подтверждения онтологической релевантности между элементами приложения и компонентов

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

Рис. 3 GUI для подтверждения онтологической релевантности между элементами приложения и компонентов

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

4.2 Разрешение структурных конфликтов

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

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

{<reduct identifier>; in: reduct; metaslot of: <reduced type name>; taking: {<list of attributes of the reduced type>}; c_reduct: <reduct name> end;

}

Спецификация конкретезирующего редукта

{<concretizing reduct identifier>; in: c_reduct; metaslot of: <reduced type name>; taking: {<list of attributes of the reduced type>}; reduct: <reduct name> end; simulating: {}

}

Разрешение конфликтов в методе СИНТЕЗ основано на комбинации двух известных подходов - использовании предопределенных правил структурных преобразований [19], или языка высокого уровня для описания преобразований [20]. Установление соответствия между элементами спецификаций (типами, атрибутами, функциями) происходит в результате интеграции онтологических спецификаций. Затем применяются правила разрешения структурных конфликтов и по ним строятся спецификации функций структурных преобразований между компонентами и применением. Применяемый при этом язык объектного исчисления позволяет задавать функции для разрешения разнообразных конфликтов.

Пример правила разрешения структурных конфликтов:

Правило. Путь в применении Ts₁...Ts₂ релевантен пути в компоненте Tr₁...Tr₂ , если

• типы Ts₁ и Tr₁ являются релевантными;

• путь в приложении имеет вид: Ts₁-a_i->Ts₂;

• путь в компоненте имеет вид: Tr₁ ...Tr₀ -b_i->Tr₂;

• атрибут a₁ релевантен атрибуту b₁;

• если типы Ts₂ и Tr₂ являются пользовательскими, то они должны быть релевантными;

• путь содержит только атрибутные ассоциации и ассоциации тип-супертип.

где Ts₁-a_i->Ts₂ – ассоциация между типами Ts₁-и Ts₂ посредством атрибута a_I, Ts₁...Ts₂ – путь произвольной длины между типами Ts₁ и Ts₂.

Примером функции разрешения конфликтов согласно данному правилу для релевантных путей Organization -in_city-> String ~ Company -address-> Address -city> String и атрибута in_city является:

get_in_city: {in: function;

params: {+r/Company, -returns/Organization.in_city} {{ returns’ = r.address.city }}}

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

Основной целью процесса поиска релевантных путей является разрешение структурных конфликтов между спецификациями применеия и компонентов. Для произвольной пары типов – типа применения Ts₁ и типа компонента Tr₁ из списка онтологически релевантных типов:

• находится тип применения Ts₂ и тип компонента Tr₂ из списка релевантных типов, такие, что пути Ts₁..Ts₂ и Tr₁..Tr₂ удовлетворяют одному из правил релевантности путей;

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

4.2.2 GUI для подтверждения релевантности путей приложения и компонентов

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

Рис. 4 GUI для подтверждения релевантности путей приложения и компонентов

Эксперт также имеет средства для поиска и установления релевантности путей, не вошедших в список.

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

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

4.3.1 Процесс нахождения наиболее общего редукта

Атрибут a_T1 типа T₁ включается в общий редукт, если существует релевантный ему атрибут a_T2 типа T_2, и тип атрибута a_T1 является супертипом типа атрибута a_T2. Операция o_T1 типа T₁ включается в общий редукт, если существует релевантная ему операция o_T2 типа T₂ с эквивалентной сигнатурой с точностью до отношения на типах параметров (контравариантность для входных параметров и ковариантность для выходных параметров).

Для определения наиболее общих редуктов для каждой пары онтологически релевантных типов T_s и T_r требуется найти максимальный набор A пар атрибутов (a_Tsi, a_Trj), которые являются онтологически релевантными и имеют типы такие, что атрибут a_Tri можно спользовать вместо a_Tsi. В общих чертах процедура формирования такой коллекции атрибутов A для пары типов Ts и Tr - следующая:

• все онтологически релевантные пары атрибутов-состояния (a_Tsi, a_Trj) включаются в A, если тип атрибута a_Tri является подтипом типа атрибута a_Tsi;

• все онтологически релевантные пары функциональных атрибутов (f_Tsi, f_Trj) включаются в A, если на их сигнатурах выполняются следующие требования:

• они имеют одинаковое количество попарно релевантных входных и выходных параметров

• для пары входных параметров, тип параметра функционального атрибута f_Tsi является подтипом типа параметра функционального атрибута f_Trj

(контравариантность входных параметров);

• для пары выходных параметров, тип параметра функционального атрибута f_Tsi является супертипом типа параметра функционального атрибута f_Trj

(ковариантность выходных параметров);

• пары атрибутов (a_Tsi, f_Trj), если f_Trj является функцией разрешения конфликтов для атрибута a_Tsi.

4.3.2 GUI для конструирования наиболее общих редуктов

На рисунке 5 показан интерфейс для просмотра и редактирования наиболее общих редуктов. Генерация наиболее общего редукта осуществляется на основе алгоритма,

описанного выше.

Рис. 5 GUI для конструирования наиболее общих редуктов

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

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

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

Пример задания типа IProposal посредством операции join над типами Proposal и Submission:

IProposal = Proposal[name, budget, status] |

Submission[name, req_money/budget, agency_name]

Композиция классов осуществляется посредством конструирования взглядов. Взгляды определяются посредством функций, имеющих единственный возвращаемый параметр: returns/<имя класса> as_class. В теле функции описывается правило формирования взгляда. Правило формирования взгляда определяет композицию классов посредством операций над классами, такими как объединение, пересечение, соединение. Спецификация взгляда задается следующим образом:

{<view name>; in: class; metaslot view_gen:{ in: function; params: {-returns/<view name> as_class}; enforcement: on_access; {{ <правило формирования взгляда> }} } end;

}

4.4.1 Процесс композиции

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

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

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

Классам как объектам также соответствуют спецификации типов. Наряду с определением операций над классами, эти типы содержат инварианты, определяющие объекты, которые могут принадлежать классу. К этим инвариантам относятся также определения ключевых атрибутов классов. Метод позволяет определить спецификацию типа класса-результата для различных операций над классами. Предполагается, что общие редукты, образуемые при реализации операций meet и join над типами экземпляров, включают ключевые атрибуты типа результирующего класса.

4.4.2 GUI для конструирования композиций фрагментов спецификаций

На рисунке 6 показан интерфейс для конструирования композиций фрагментов спецификаций.

Рис. 6 GUI для конструирования композиций фрагментов спецификаций

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