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

В настоящее время сложность разработки и поддержки программных систем ( ПС ) достигла уровня, при котором необходимо применять принципы и процедуры процесса архи-тектуризации [ 1]. Под архитектуризацией понимается представление ПС в форме описания архитектуры, состоящей из множества артефактов проектирования. Свойства ПС определяют поведение системы, её состав и подходы к развитию, влияющие на выполнимость, полезность и жизнеспособность системы [ 2-4 ]. Описание архитектуры ПС, полученное в процессе архитектурного проектирования, используется для координации действий сторон, вовлечённых в процессы разработки, внедрения, поддержки и использования системы. В процессе архитектурного проектирования ПС формируются требования к системе на всех стадиях жизненного цикла, выделяются особенности процессов разработки, внедрения, эксплуатации и сопровождения ПС.

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

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

• ■    определение основных компонентов и элементов ПС;

• ■    подходы к организации и взаимодействию элементов ПС;

• ■   принципы организации ПС;

• ■   принципы организации проекта ПС;

• ■    принципы развития ПС в рамках её жизненного цикла.

Качество описания архитектуры ПС влияет на качество процесса разработки и качество системы [ 6, 7 ]. Чем на более позднем этапе разработки ПС обнаружены ошибки проектирования, тем больше ресурсов требуется для их исправления.

Описание архитектуры ПС также может быть получено в процессе переработки описания архитектуры предыдущих проектов [ 1, 4 ]. Удачные проектные решения, полученные при работе над предыдущими проектами, должны быть использованы в процессе работы над новыми проектами.

1    Постановка задачи

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

ЕПО зафиксированы в различных артефактах проектирования:

• ■    проектная документация, представленная в виде слабоструктурированного текста на естественном языке;

• ■    проектные диаграммы, обычно представленные в нотации UML ;

• ■    исходные коды ;

• ■    модели данных объектов ПрО, представленные в виде сущностей и связей реляционных баз данных;

• ■    различные структурированные информационные ресурсы, описывающие особенности разработки, развёртывания и настройки окружения проекта, обычно представленные в виде вики - ресурсов.

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

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

Разработка ПС состоит из нескольких этапов, качество выполнения которых влияет на качество системы [ 6, 7 ]. Основным этапом разработки новой ПС является проектирование, в рамках которого формируется описание архитектуры и модель разрабатываемой системы. На данном этапе должны быть решены следующие задачи: ■ поиск критических участков проекта;

• ■    формирование окончательного описания архитектуры ПС;

• ■    объектное моделирование и проектирование основных элементов ПС.

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

• ■    накопления множества проектных решений, используемых в проектной организации;

• ■   извлечения часто используемых ЕПО;

• ■   анализа качества полученных ЕПО;

• ■    определения предпочтений в выборе ЕПО разработчиками;

• ■    определения показателя изменения динамики интереса к различным ЕПО во времени;

• ■    прототипирования проекта на основе анализа технического задания или спецификации и множества ЕПО, содержащихся в БЗ.

• 2.1    Онтология ПрО

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

2    База знаний проектной организации

Исследователи в области инженерии знаний отмечают актуальность исследований, основанных на онтологическом подходе [10- 13], а в работах [14-18] - важность онтологического инжиниринга в процессах проектирования и разработки ПС. Так, в [14, 17] предлагается использовать вместо традиционных языков моделирования ПС ( например UML ) онтологии, которые позволяют контролировать логическую целостность и непротиворечивость полученной модели. Однако существующие методы формирования БЗ в виде набора онтологий для поддержки и автоматизации процесса архитектуризации ПС предполагают привлечение экспертов ПрО и специалистов в области инженерии знаний, что требует существенных временных затрат на формирование такой БЗ.

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

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

Онтология ПрО представляется в виде множества:

Оdот = { ₀dот, ., _Odот, ., _Qd° ^т},    ( i = 1, _ ,n ),

где n - количество ПрО, в рамках которых проводилась работа над предыдущими проектами; Оf^от - i - я онтология ПрО, содержащая описание особенностей i - й ПрО. Формальное представление любой О^йот запишется в виде кортежа:

0 dom = ( с° от, Т° от, R°om, F° оту где С°от - множество понятий ПрО;

jdom - множество терминов ПрО, описывающих понятия ПрО ;

pdom - множество функций интерпретации, определяющих множество отношений R^аот; pdот - множество отношений вида:

pdom _ (pdom pdom\ = ^{R С С ,^RСТ },

где R^^т - множество отношений обобщения, определяющих иерархию понятий ПрО («понятие - понятие»);

Rст^т — множество отношений ассоциации, формирующих связи между понятиями и терминами, описывающими данные понятия («понятие - термин»).

• 2.2    Онтология артефактов проектирования

Онтология артефактов проектирования содержит формализованные описания артефактов проектирования в виде фрагментов БЗ проектной организации. Базовыми элементами данной онтологии являются:

• ■    сущность - объект некоторой ПрО, смоделированный с помощью артефакта проектирования, например, класс, таблица и т.д.;

• ■    атрибут сущности - свойство сущности, например , поле класса, столбец таблицы и т.п .;

• ■    ограничение атрибута сущности - свойства атрибута сущности, например, тип поля класса, размер поля класса с типом «строка» и т.д.;

• ■   бизнес - процесс - процесс в некоторой ПрО, в который вовлечена некоторая сущность,

например, метод класса, вариант использования и т.д.

Онтология артефактов проектирования представляется следующим кортежем:

,Р ^{е рр}) ,                         (3)

0 ехр = ^рехр, дехр, Сехр ,pexp,Rexp где Ехрр - множество сущностей;

А^хрр - множество атрибутов сущностей;

Сехр - множество ограничений атрибутов сущностей;

Р^ехр - множество бизнес - процессов, в которые вовлечены сущности;

Е^хрр - множество функций интерпретации, определяющее множество отношений К^хрр;

R^exp - множество отношений вида:

рехр _ (рехр _Dexp _Dexp _пехрл = ^{R E Е ’^REA ’^RA с ,^REР }, где RE^ - множество отношений обобщения, определяющие иерархию сущностей («сущность - сущность»);

^rea - множество отношений ассоциации, определяющие связь между сущностью и её атрибутом («сущность - атрибут»);

^ас^Р - множество отношений ассоциации, определяющие связь между атрибутом сущности и его ограничением («атрибут - ограничение»);

R Ер ^р - множество отношений ассоциации, определяющие связь между сущностью и бизнес - процессом, в который она вовлечена («сущность - бизнес - процесс»).

• 2.3    Модель базы знаний проектной организации

Рассмотренные в подразделах 2.1 и 2.2 онтологии формируют компоненты БЗ проектной организации. Модель БЗ проектной организации можно представить в виде кортежа:

= ( О ^{d тт} , О ^ехр, R , Г),                                             (4)

в котором O^dmm - онтология для учёта сведений о различных ПрО, в рамках которых производилась работа над предыдущими проектами (1);

О ^ехР - онтология для представления артефактов проектирования, формируемая в процессе анализа артефактов проектирования (3);

R - множество отношений ассоциации между понятиями онтологии ПрО и артефактами проектирования;

F - множество функций интерпретации, определяющих множество отношений R .

3    Формирование фрагментов базы знанийв процессе анализа артефактов проектирования

Формирование фрагментов БЗ в процессе анализа структуры прикладного решения разработано с применением платформы 1С: Предприятие 8 [ 19]. Платформа 1С широко используется для автоматизации различных типов учёта: управленческий, оперативный, бухгалтерский и т.д. Для каждого типа учёта разрабатываются типовые прикладные решения, выполняемые в рамках платформы 1С. Прикладное решение платформы 1С представляет собой комплексный артефакт проектирования, содержащий опыт и знания большого числа высококвалифицированных специалистов. Прикладное решение платформы 1С можно представить в виде следующего выражения:

Сonf = {S f ^onf,... Sf^nf, ^,5^ ^onf}, i = 1,..., n, где S^{c on}— - i - я подсистема прикладного решения. Подсистема используется для группировки объектов прикладного решения в рамках некоторого контекста, например : «Закупки», «Кадры», «Склад» и т. д. Подсистему можно представить в виде следующего выражения:

S^^onf = (N ате ,E^Cof ,P^Cof ),                          (5)

где N ате - уникальное имя подсистемы;

_Econf = <  _с^о onf n⁰ onf^ - множество сущностей прикладного решения ; для представления сущностей ПрО в рамках прикладного решения 1С используется множество справочников C^Conf и множество перечислений N^Conf ;

pc onf = ф с onf , _R^o о ^nf) - множество бизнес - процессов прикладного решения, в которые вовлечены сущности прикладного решения. Множество бизнес - процессов p^Conf содержит множество документов D^{Co nf} и множество регистров R^Conf. Документы используются для изменения состояния сущностей прикладного решения. Регистры прикладного решения используются для хранения истории состояний сущностей. Записи регистров формируются на основе данных документов.

Каждый элемент из множеств CConf и DConf можно представить в виде следующего выражения:

C f ^onf ,D0^onf = Conf ,T ^cOff\ где V^Conf = {V^conf, ... v^Conf, ..., m_m^{o onf}} - множество атрибутов сущности;

y.conf = ^у а т e ,Typ e ,C ons t г а int) - каждый атрибут элемента характеризуется именем N ате , типом данных Т yp е и ограничениями С о ss Гг ai nt. При этом тип данных Т yp е может представлять собой не только простой тип данных, но и ссылку на другой объект прикладного решения (элемент справочника, документ и т. д.);

_Tconf = { ^con,.... _Tconf , ..., _T^c on/ } — множество таблиц, связанных с сущностью. Таблицы в рамках платформы 1С используются для формирования связей вида «один ко многим» для группировки данных рамках одной сущности, например, элемент справочника «Сотрудник» может содержать таблицу со списком его детей;

• - pConf = ^ _ame,yco^ff^ — каждая таблица сущности содержит уникальное имя и множество атрибутов.

Элемент множества можно записать как Ri^Conf = (V ame , V^{е onf}), а элемент множества N^ConU имеет вид y^Conf = ^Name)

Таблица 1 содержит соответствие объектов – i - й подсистемы прикладного решения и аксиом онтологии артефактов проектирования.

Алгоритм формирования фрагментов БЗ представлен на примере анализа прикладного решения платформы 1С следующей структуры :

Таблица 1 – Соответствие объектов подсистемы прикладного решения и аксиом онтологии

Прикладное решение	Онтология
SXo nf . Naree	gexp
CXo nf . у ame	gexp ^exp
Nx 0 nf . V ame	gexp ^exp
jC о nf . у ame	Ef рр ,R E ^i
Dx 0 nf . V ame	Dexp Dexp Ы , R EEi
r conf . Vame	Dexp Dexp Pt , R E Ei
у co nf . у ame	лехр Dexp AI >R E Ai
V Conf .Ty p e ,, V Conf ECCnf	rrexp DexpA (C i   , R AC i )
V Conf .Typ e ,, V Conf EDCof	Dexp KEPt
yConf . e otls traint	ГexP r,exp C i ,RA Ct

• ■   подсистемы : «Торговля».

• ■   справочники : «Товары», «ЕдиницыИзмерения», «Склады», «Поставщики».

• ■    документы : «ПоставкаТовара».

• ■   атрибуты  справочника  «Товары»:  «Код» (строка),  «Наименование» (строка),

«ЕдиницаИзмерения» (элемент справочника «ЕдиницыИзмерения»).

• ■   атрибуты  справочника  «ЕдиницыИзмерения»: «Код»  (строка), «Наименование»

(строка).

• ■    атрибуты справочника «Склады»: «Код» (строка), «Наименование» (строка).

• ■    атрибуты справочника «Поставщики»: «Код» (строка), «Наименование» (строка).

• ■   атрибуты документа «ПоставкаТовара»: «Склад» (элемент справочника «Склады»),

«Поставщик» (элемент справочника «Поставщики»), «Товары» (таблица).

• ■   атрибуты таблицы «Товары»: «Товар» (элемент справочника «Товары»), «Цена»

(число), «Количество» (число), «Сумма» (число).

Алгоритм формирования фрагментов БЗ в процессе анализа прикладного решения плат формы 1С можно записать в виде следующей последовательности шагов.

• 1)    для каждой подсистемы прикладного решения сформировать сущность онтологии артефактов проектирования:

^Conf рехр →     , например, Торговля ЕЕерр.

• 2)    для каждой сущности текущей подсистемы прикладного решения создать сущность онтологии артефактов проектирования с учётом связи с подсистемой:

  _Cconf ^ 5^ехр Е Е ехр , ^ ехр _{£ R}eрр , _NConf ^ g^exp е Е^хрр , R^e_E^xp Е Е_е ^рР ,

  
  

например, Товары Е Е^ерр , ЕдиницыИзмерения Е Е^ерр. Склады Е Е^{е рр}, Поставщики Е Е^{е рр} , Товары R EE ^PТорговля, „., Поставщики R |^ ^pТорговля.

• 3)    если текущая сущность прикладного решения является справочником, создать множество атрибутов, ограничений атрибутов и отношений для данной сущности онтологии артефактов проектирования:

уСоnf е Ссоnf ^ АерР е Аеpp , ^epp е Rexp, yconf е Ccoff ^ cexp е cepp, НдСр е ЕХpP , например, Код е Аepp, Наименование е Аepp, ЕдиницаИзмерения е Аеpp, Товары R^ Код, Товары R^ Наименование, Товары R^ ЕдиницаИзмерения,

…,

Поставщики R |^ ^p Код, Поставщики R^ Наименование, СтрокаТип е С^epp, ЧислоТип е С^epp, СсылкаТип е С^еСР , Код R ^xpp СтрокаТип, Наименование R ^xpp СтрокаТип , ЕдиницаИзмерения ^едр^р СсылкаТип.

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

∈       →̂    ∈     , ̂   ∈,

∈       ,       ∈        → ̂    ∈      , ̂    ∈,

∈       ,       ∈        → ̂    ∈      , ̂

J J          IЕС ЕС

• 5)    для каждого бизнес - процесса текущей подсистемы прикладного решения создать бизнес - процесс онтологии артефактов проектирования с учётом связи с подсистемой:

→̂    ∈     , ̂    ∈,

RConf ^ рерр е Еррр, ReExp е RеЕр, например, ПоставкаТовара е    , ПоставкаТовара     Торговля.

• 6)    создать множество отношений для связи текущего бизнес - процесса и сущностей онтологии артефактов проектирования на основе анализа атрибутов текущего бизнес - процесса прикладного решения:

∈       → ̂    ∈     ,

∈       → ̂   ∈     , например, Поставщики     ПоставкаТовара, Склады     ПоставкаТовара.

• 7)    если текущий бизнес - процесс прикладного решения имеет таблицы (документ), то для каждой таблицы сформировать множество отношений для связи текущего бизнес - процесса и сущностей онтологии артефактов проектирования:

_vcon_f е _Tj ^cnfСт_}^соnf е D^^ ^ R^e_E^x_p^p е R^Epp, например, Товары     ПоставкаТовара.

Для представленного прикладного решения платформы 1С формируется онтология ПрО .

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

Товар е     , Склад е     , Поставщик е,

ЕдиницаИзмерения е     , ПоставкаТовара е,

Товар е     , Склад е     , Поставщик е,

Единица измерения е Т ^оот , . „, Поставка товара е Т ^оот, Товар R ст^т. .., ПоставкаТовара R ст ^т Поставка товара .

Полученный в результате анализа прикладного решения платформы 1С фрагмент БЗ в виде онтологии представлен на рисунке 1.

Рисунок 1 - Пример сформированной онтологии

4    Генерация диаграмм вариантов использования на основе базы знаний

Диаграмму вариантов использования можно записать в виде следующего выражения:

U CD = (A ^{и CD} , Р ^UCD , U^CCD),                              (6)

где A^{CD D} - множество акторов диаграммы вариантов использования;

Р^иCD - множество прецедентов (вариантов использования);

rucd - множество отношений диаграммы вариантов использования:

RUCD = {R CKD R CD R CD }, в котором R ^UCD - множество отношений обобщения; rucd - множество отношений включения;

Re^CD - множество отношений расширения.

Тогда постановка задачи генерации диаграммы вариантов использования заключается в преобразовании онтологии О^ерр (3) в элементы модели диаграммы (6).

Таблица 2 содержит описание сопоставления структурных компонентов диаграммы вариантов использования с сущностями онтологии О^ехр . В настоящий момент при формировании диаграммы вариантов использования на основе содержимого БЗ формируется

Таблица 2 - Соответствие компонентов онтологии артефактов проектирования и диаграммы вариантов использования

Онтология	Диаграмма вариантов использования
рехр	Прецедент PpcD
рехр рехр И  ' р	Отношение включения R uCD

только отношение включения. Для формирования отношений расширения и обобщения требуется дополнительная проработка метода .

Алгоритм генерации диаграммы вариантов использования на основе содержимого БЗ состоит из следующих шагов:

• 1)    выбор бизнес - процессов онтологии в качестве основы диаграммы вариантов использования, например, ПоставкаТовара £ Р^ехр ;

• 2)    формирование списка сущностей онтологии, с которыми связаны выбранные бизнес - процессы, например : Товары £ Е^ерр , ЕдиницыИзмерения £ Е^ерр , Склады £ Е^ерр , Поставщики £ Е ^{р рр} ;

• 3)    формирование иерархии сущностей онтологии для генерации диаграммы вариантов использования на основе анализа отношений вида R_ЕЕ онтологии, например : Товары R_{Е Е} Торговля, „., Поставщики R_Е^Р_Е^р Торговля;

• 4)    замена сущностей полученной иерархии на связанные с ней бизнес - процессы (если такого бизнес - процесса ещё нет в диаграмме) ;

• 5)    обход иерархии с корневого узла. Формирование прецедента для каждого узла, организация отношений включения между прецедентами, например : Торговля R ^ ^ML Поставка товара и т.д .

После выполнения данного алгоритма формируется набор команд для системы PlantUML [20] , например:

@startuml

:user: - (Торговля)

(Торговля)..>(Поставка товара):include

(Поставка товара)..>(Внести данные Поставщик):include

(Поставка товара)..>(Внести данные Склад):inclu de

(Поставка товара)..>(Внести данные Товар):include

(Поставка товара)..>(Оформить Поставка товара):include

@enduml

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

Рисунок 2 - Пример сгенерированной диаграммы вариантов использования

5    Эксперименты

Для оценки адекватности предложенных методов и моделей проведён ряд экспериментов, план которых включает:

• ■    формирование содержимого БЗ проектной организации в виде OWL онтологии в процессе анализа прикладного решения для платформы 1С;

• ■    проверка полученной OWL онтологии на корректность с применением механизма логического вывода редактора онтологий Protege [21];

• ■    генерация набора команд системы PlantUML для формирования диаграмм вариантов использования ;

• ■    оценка качества полученных диаграмм вариантов использования путём их сравнения с аналогичными диаграммами, построенными экспертом.

Для оценки качества полученных диаграмм вариантов использования применялись сле- дующие метрики. Точность:

|         ∩|

Рте CIS I on = ---:----:,

|| где |G еп О Ерр - - количество совпадающих элементов в сгенерированной диаграмме и диаграмме, построенной экспертом;

-Ехр- - количество элементов в диаграмме, построенной экспертом.

Полнота:

Reсац = ^ - ^1, |                                    | где |G еп — X рр- - количество элементов в сгенерированной диаграмме, которые отсутствуют в диаграмме, построенной экспертом;

|G е п| - количество элементов в сгенерированной диаграмме .

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

6    Оценка качества сгенерированных диаграмм вариантов использования

В качестве входных данных для формирования содержимого БЗ использовалось типовое прикладное решение для платформы 1С - «Управление торговлей».

Формирование OWL онтологии проводилось при анализе объектов прикладного решения, входящих в подсистему «Расхождения»:

• ■    подсистемы «Закупки» (родительская подсистема) и «Расхождения»;

• ■   регистр накопления «ГрафикиОтгрузки»;

• ■   справочники «Организации», «Валюты», «Партнеры», «Контрагенты», «Пользователи»,

«Номенклатура», «Назначения», «Склады»;

• ■    документы «АктОРасхожденияхПослеПеремещенияТоваров», «АктОРасхожденияхПо-слеПриемкиТоваров» и «АктОРасхожденияхПослеОтгрузкиТоваров».

Проверка полученной OWL онтологии в редакторе Protege закончилась успешно.

Для проведения данного эксперимента в редакторе Protege была составлена онтология ПрО О^а0m (2), содержащая названия прецедентов для объектов прикладного решения платформы 1С. Например, для понятия «Закупки» установлено описание «Закупка товаров», для понятия «Склады» установлено описание «Данные о складах», а для понятия «АктОРасхож-денияхПослеПеремещенияТоваров» описание - «Акт о расхождениях после перемещения».

В сгенерированной на основе содержимого OWL онтологии диаграмме вариантов использования (рисунок 3) содержится 14 прецедентов, из которых 9 не содержится в диаграмме, построенной экспертом (рисунок 4). Количество прецедентов диаграммы вариантов использования, построенной экспертом - 5. Таким образом, получены следующие значения метрик качества: Precision = 5/5=1, Recall = 9 / 14 = 0.643.

Рисунок 3 – Сгенерированная диаграмма вариантов использования для прикладного решения на платформе 1С «Управление торговлей»

Рисунок 4 – Диаграмма вариантов использования для прикладного решения на платформе 1С «Управление торговлей», построенная экспертом

Время, затраченное на автоматическую генерацию диаграммы вариантов использования, составило 3 минуты (без учёта времени формирования онтологии ПрО Qdom ). Экспертом на решение аналогичной задачи было потрачено 17 минут.

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

Таблица 3 – Результаты проведённых экспериментов

Конфигурация	Подсистема	Кол-во элементов			Точность	Полнота
		Метод	Эксперт	Совпадающие
Управление торговлей	Расхождения (закупки со сверкой товаров)	14	5	9	1	0.643
Зарплата и управление персоналом	Кадры (регистрация переработок)	8	4	4	1	0.5
Комплексная автоматизация	Склад (излишки, недостачи, порча продукции)	12	6	4	0.667	0.667
Управление торговлей	Банк и касса (работа с кассой)	13	6	5	0.833	0.615

Полученные оценки значений точности в среднем составляет 0.875, а полноты – 0.6. Как видно из результатов экспериментов, сгенерированные артефакты проектирования имеют высокий показатель точности, но при этом такие артефакты проектирования содержат большее количество структурных элементов, что повышает показатель полноты. Высокий показатель полноты связан с учётом связей между объектами анализируемого прикладного решения для платформы 1С, которые получены в процессе их жизненного цикла и не были спроектированы изначально .

Заключение

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

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

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

Исследование выполнено в рамках государственного задания № 075 -00233-20- 05 по проекту «Исследование интеллектуального предиктивного мультимодального анализа больших данных и извлечения знаний из разных источников», а также при финансовой поддержке РФФИ и Правительства Ульяновской области в рамках научных проектов № 19-47-730006, 19-47-730005.