ФОРМИРОВАНИЕ БАЗЫ ЗНАНИЙ ДЛЯ ПОДДЕРЖКИ ПРОЦЕССА АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СИСТЕМ Текст научной статьи по специальности «Компьютерные и информационные науки»

ПРИКЛАДНЫЕ ОНТОЛОГИИ ПРОЕКТИРОВАНИЯ

УДК 004.89 DOI: 10.18287/2223-9537-2021-11-2-154-169

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

Г.Ю. Гуськов, А.М. Наместников, А.А. Романов, А.А. Филиппов

Ульяновский государственный технический университет, Ульяновск, Россия

Аннотация

Рассмотрен подход к формированию базы знаний для автоматизации процесса архитектурного проектирования программных систем на основе опыта предыдущих проектов. Под архитектуриза-цией понимается представление программных систем в форме описания архитектуры, состоящей из множества артефактов проектирования. При разработке новой программной системы возможно повысить её качество за счёт привлечения опыта предыдущих проектов - удачных проектных и архитектурных решений, содержащихся в базе знаний проектной организации. Такая база знаний должна формироваться в процессе анализа артефактов проектирования, полученных в процессе работы над предыдущими проектами: исходный код проекта, диаграммы проектирования, модели данных, структурированные информационные ресурсы и т. д. В статье рассмотрена модель базы знаний проектной организации, позволяющая учитывать опыт предыдущих проектов. Представлена модель прикладного решения платформы 1С: Предприятие в качестве примера артефакта проектирования. Представлен метод для формирования фрагментов базы знаний в процессе анализа прикладного решения для платформы 1С и метод генерации диаграмм вариантов использования на основе содержимого базы знаний. Приведены результаты экспериментов оценки качества по точности (наличие в сгенерированной диаграмме элементов экспертной диаграммы) и полноте (наличие в сгенерированной диаграмме элементов, отсутствующих в экспертной диаграмме). Полученные оценки значений точности в среднем составляет 0.875, а полноты - 0.6.

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

Цитирование: Гуськов, Г.Ю. Формирование базы знаний для поддержки процесса архитектурного проектирования программных систем / Г.Ю. Гуськов, А.М. Наместников, А.А. Романов, А.А. Филиппов // Онтология проектирования. - 2021. - Т. 11, №2(40). - С.154-169. - DOI: 10.18287/2223-9537-2021-11-2-154-169.

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■ поиск критических участков проекта;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Qdorn — {Odom, .. .,0dom, . . .,0dom}, (i = 1,...,n), (1)

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

Qdom _ ^Qdom pdom pdom pdom^ (2)

где Cdom - множество понятий ПрО;

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

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

pdom _ Гpdom pdom\ R — {RCC 'RCT }'

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

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

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

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

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

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

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

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

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

Овхр — ^ßexp дехр сехР рехр Rexp рехр^ (3)

где Еехр - множество сущностей;

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

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

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

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

Rexp - множество отношений вида:

рехр _ Гр«Ф оехР рехР рехР\ — ' ЕА ' АС ' ЕР }'

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

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

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

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

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

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

0 = (Ойот, Оех? , И, Б), (4)

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

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

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

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

3 Формирование фрагментов базы знаний

в процессе анализа артефактов проектирования

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

С о п f = { SCo nf SCo nf SC o nf } i = 1 n

\J I LJ ~~ { 1 ; ■■■ í ' "" " , П J ' -Íj...j/íj

где sConf - i-я подсистема прикладного решения. Подсистема используется для группировки объектов прикладного решения в рамках некоторого контекста, например: «Закупки», «Кадры», «Склад» и т. д. Подсистему можно представить в виде следующего выражения:

sConf = (N ат е, EConf,PConf), (5)

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

EConf = (cConf,NConf ) - множество сущностей прикладного решения; для представления сущностей ПрО в рамках прикладного решения 1С используется множество справочников

и множество перечислений ;

pConf = фConf,gC°nf) - множество бизнес-процессов прикладного решения, в которые вовлечены сущности прикладного решения. Множество бизнес-процессов pConf содержит множество документов и множество регистров . Документы используются для

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

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

cConf, D Conf = (N ат е ,VConf ,TConf), где VConf = {V1Conf, ■ ■ ■ ViConf, ■ ■ ■, VmConf } - множество атрибутов сущности;

( ) - каждый атрибут элемента характеризуется именем

, типом данных и ограничениями . При этом тип данных может

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

Прикладное решение Онтология

5_Con/_ Name

C.Con/_ Name ^exp ^exp l ' EEi

N^onf. Name gexp ^exp l ' EEi

TLConf.Name р.ехр г>е хр-ci 'nEEtl

D[onf.Name Dexp DexP Fi ■ EEi

Rfonf.Name Dexp DexP Fi ■ EEi

vfmf.Name .exp Dexp Ai ' KEAi

VConf . Type, VConf £ cConf СГ exp D ехр л ( C i 'RA Ci)

VConf . Type, VConf £ DConf Dexp EPi

у Conf ^ £onslrainl rexp DexP Li • ACi

pConf _ { Y^Conf ^ ^^ pConf^ ^^Щ 1ТтConf} _ множе- Таблица 1 - Соответствие объектов подсистемы

rr г прикладного решения и аксиом онтологии 0ехр

ство таблиц, связанных с сущностью. Таблицы в ^ ^

рамках платформы 1С используются для формирования связей вида «один ко многим» для группировки данных рамках одной сущности, например, элемент справочника «Сотрудник» может содержать таблицу со списком его детей; T c°nf _ ^атeVConf ) - каждая таблица сущности содержит уникальное имя и множество атрибутов.

Элемент множества RConf можно записать как RiConf _ {Nатe,VConf ), а элемент множества NConf имеет вид NiConf _ {Nатe)

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

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

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

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

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

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

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

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

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

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

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

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

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

^ Con f Еехр

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

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

QConf £ехр g рехр рехР ^ рехР ' ЕЕ ЕЕ '

NConf _ Еехр £ Еехр, R17 £ R-TI, например, Товары £ Еехр, ЕдиницыИзмерения £ Еехр,

Склады £ Еехр, Поставщики £ Еехр, Товары R ^Торговля, ..., Поставщики R ^Торговля.

(строка),

«Наименование»

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

уСоп/ е сС0п/ _ дехр Е Аехр> щхр е кехр,

усопг Е сСопг _ сехр е сехр , Яех е Яех,

например, Код Е Аехр, Наименование Е Аехр, ЕдиницаИзмерения Е Аехр, Товары Я^Д Код, Товары Я^Д Наименование, Товары Я^Д ЕдиницаИзмерения,

• • • 1

Поставщики Я^ Код, Поставщики Я^ Наименование, СтрокаТип Е Сехр, ЧислоТип Е Сехр, СсылкаТип Е Сехр,

Код СтрокаТип, Наименовани СтрокаТип,

, ехр

ЕдиницаИзмерения ЯАС СсылкаТип.

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

ТСоп/ е С С0п/ _ £ехр Е £~ехр Яехр Е Яехр уСоп/ ^ ^СопГ ^СопГ ^ дехр ^ дехр ^ехр ^ ^ехр

У соп/ е тСоп/ тсоп/ е сСоп/ _ Сехр е сехр Яехр е ЯехР

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

£)Со п/ _ рехр е ре хр ре хр е Яехр

ЯСопг _ рехр е ЕехрЯеЛ е Яехр

ЕЕ 11ЕЕ ' ехр _ тлвхр ЕЕ Ь КЕЕ

ехр

например, ПоставкаТовара , ПоставкаТовара Торговля.

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

УСоп/ е БСоп __ Яехр Е ЯеЕхр, У с о п / е я С о п/ -_. ¡^ЕХР е Я ЕХР

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

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

у Со п/ £ 1*С о п/ ^С о п/ е ^С о п/ ^е хр ^ ^е хр

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

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

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

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

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

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

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

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

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

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

иСБ = (Аис°,Рисо,Нис°), (6)

где Аисо - множество акторов диаграммы вариантов использования;

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

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

^исо _ ^исо ^исо ^исо+

в котором - множество отношений обобщения;

- множество отношений включения;

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

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

преобразовании онтологии Оехр (3) в элементы модели диаграммы (6).

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

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

Онтология Диаграмма вариантов использования

рвхр Прецедент Р?со

пехр рвхр ' ' ' Отношение включения Я^00

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

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

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

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

формирование иерархии сущностей онтологии для генерации диаграммы вариантов ис-

и г") сХ13 гтч г^бХТ)

пользования на основе анализа отношений вида онтологии, например: Товары Торговля, ..., Поставщики й Торговля;

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

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

После выполнения данного алгоритма формируется набор команд для системы Р1аМиМЬ [20], например: @$1атЫш1

:жет: - (Торговля)

(Торговля)..>(Поставка товара):include (Поставка товара).. >(Внести данные Поставщик):include (Поставка товара).. >(Внести данные Склад):include (Поставка товара).. >(Внести данные Товар):include (Поставка товара)..>(Оформить Поставка товара):include

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

1) 2)

3)

4)

5)

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

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

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

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

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

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

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

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

„ . . \Gen П Ехр\

Precision = -;-;-,

\Ехр\

где ¡Gen П Ехр \ - количество совпадающих элементов в сгенерированной диаграмме и диаграмме, построенной экспертом;

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

Recall = fe^,

\Gen\

где \Gen — Ехр\ - количество элементов в сгенерированной диаграмме, которые отсутствуют в диаграмме, построенной экспертом; \Gen\ - количество элементов в сгенерированной диаграмме.

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

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

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

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

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

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

■ справочники «Организации», «Валюты», «Партнеры», «Контрагенты», «Пользователи», «Номенклатура», «Назначения», «Склады»;

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

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

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

Рисунок 3 - Сгенерированная диаграмма вариантов использования для прикладного решения

на платформе 1С «Управление торговлей»

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

Время, затраченное на автоматическую генерацию диаграммы вариантов использования, составило 3 минуты (без учёта времени формирования онтологии ПрО Ойот). Экспертом на решение аналогичной задачи было потрачено 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.

Список источников

[1] ГОСТ Р 57100-2016/Is0/IEC/IEEE 42010:2011. Системная и программная инженерия. Описание архитектуры. М.: Стандартинформ, 2019. - http://docs.cntd.ru/document/1200139542.

[2] Heesch van, U. A documentation framework for architecture decisions / U. van Heesch, P. Avgeriou, R. Hilliard // Journal Syst. Softw. 2012. vol. 85, 4, p.795-820. D0I:10.1016/j.jss.2011.10.017.

[3] Hilliard, R. Using Aspects in Architectural Description / R. Hilliard // Lecture Notes in Computer Science, 2007. vol. 4765. P.65-68.

[4] Sosnin, P. Substantially evolutionary theorizing in designing software-intensive systems / P. Sosnin // Information (Switzerland), 2018. 9 (4). P.91.

[5] Sosnin, P. Ontological controlling the lexical items in conceptual solution of project tasks / P. Sosnin, A. Push-kareva // Lecture Notes in Computer, 2017. Vol. 10409. P.31-46.

[6] ISO/IEC 25010 2011. ISO/IEC 25010:2011: Systems And Software Engineering - Systems And Soft-Ware Quality Requirements And Evaluation (Square) - System And Software Quality Models.

[7] Макконнелл, С. Совершенный код: Практическое руководство по разработке программного обеспечения / С. Макконнелл. СПб.: Русская редакция/БХВ, 2017.

[8] Маклаев, В.А. Инструментально-технологическая среда формирования и использования опыта проектной организации / В.А. Маклаев, П.И. Соснин // Автоматизация процессов управления. 2009. № 2 (16). С.8-13.

[9] Соснин, П.И. Архитектурный подход к прецедентно-ориентированному решению задач в разработке автоматизированных систем / П.И. Соснин, С.С. Шумилов, А.Е. Ивасев // Автоматизация процессов управления. 2019. № 1 (55). С. 49-56.

[10] Загорулько, Ю.А. Использование паттернов онтологического проектирования для разработки онтологий предметных областей / Ю.А. Загорулько, О.И. Боровикова, Г.Б. Загорулько // Сборник тр. конф. «Знания-Онтологии-Теории» (З0НТ-2017). Новосибирск, 2017. С. 139-148.

[11] Муромцев, Д.И. Интеграция wiki-технологии и онтологического моделирования в задаче управления знаниями предприятия / Д.И. Муромцев [и др.] // Сборник тр. конф. «КИИ-2008». Дубна, 2008. С.360-368.

[12] Самойлов, Д.Е. Паттерны структурной организации системы измеряемых свойств в онтологическом анализе данных / Д.Е. Самойлов, В.А. Семенова, С.В. Смирнов // Сборник тр. конф. «Проблемы управления и моделирования в сложных системах». Самара, 2018. С.358-366.

[13] Shaaban, A.M. Ontology-based security tool for critical cyber-physical systems / A.M. Shaaban, T. Gruber, C. Schmittner // Proceedings of the 23rd International Systems and Software Product Line Conference. Vol. B. 2019. P.207-210.

[14] Bhatia, M.P.S. Ontologies for software engineering: past, present and future / M.P.S. Bhatia, A. Kumar, R. Beni-wal // Indian Journal of Science and Technology. 2016. Vol. 9. P.1-16.

[15] Falbo, R.A. et al. An ontology pattern language for service modeling / R.A. Falbo et al. // Proceedings of the 31st Annual ACM Symposium on Applied Computing. 2016. P.321-326.

[16] Ilyas, Q.M. Ontology Augmented Software Engineering / Q.M. Ilyas // Software Development Techniques for Constructive Information Systems Design. IGI Global, 2013. P.406-413.

[17] Isotani, S. et al. Ontology driven software engineering: a review of challenges and opportunities / S. Isotani et al. // IEEE Latin America Transactions. 2015. Vol.13. P.863-869.

[18] Pan, J.Z. et al. Ontology-driven software development / J.Z. Pan et al. Springer Science & Business Media, 2012.

[19] What is 1C:Enterprise? - https://1c-dn.com/1c_enterprise/what_is_1c_enterprise/.

[20] PlantUML. UML Diagram Generator. - https://plantuml.com.

[21] Protégé. Free, open-source ontology editor and framework for building intelligent systems. -https ://protege.stanford. edu.

Сведения об авторах

Гуськов Глеб Юрьевич, 1992 г. рождения, кандидат технических наук, окончил факультет информационных систем и технологий Ульяновского государственного технического университета (УлГТУ). Доцент кафедры «Информационные системы» УлГТУ. Имеет около 30 работ в области онтологического инжиниринга и интеллектуального анализа данных. Author ID (RSCI): 812005; Author ID (Scopus): 57021635300. g.guskov@ulstu.ru.

Наместников Алексей Михайлович, 1974 г. рождения, доктор технических наук, доцент, окончил радиотехнический факультет УлГТУ. Профессор кафедры «Информационные системы» УлГТУ. Имеет более 80 работ в области автоматизированного проектирования и интеллектуальных систем. Author ID (RSCI): 392690; Author ID (Scopus): 9277806100. nam@ulstu.ru.

Романов Антон Алексеевич, 1986 г. рождения, кандидат технических наук, окончил факультет информационных систем и технологий УлГТУ, доцент кафедры «Информационные системы» УлГТУ. Имеет около 60 работ в области интеллектуальных систем хранения и обработки информации. ORCID: 0000-0001-5275-7628; Author ID (RSCI): 684949; Author ID (Scopus): 55903279200. roma-nov73@gmail.com.

Филиппов Алексей Александрович, 1987 г. рождения, кандидат технических наук, окончил факультет информационных систем и технологий УлГТУ, доцент кафедры «Информационные системы» УлГТУ. Имеет около 80 работ в области онтологического инжиниринга и интеллектуального анализа данных. ORCID: 0000-0001-5275-7628; Author ID (RSCI): 708454; Author ID (Scopus): 57191472723. al.filippov@ulstu. ru.

Поступила в редакцию 27.05.2021, после рецензирования 17.06.2021. Принята к публикации 23.06.2021.

Formation of a knowledge base

to support the process of architectural design of software systems

G.Y. Guskov, A.M. Namestnikov, A.A. Romanov, A.A. Filippov

Ulyanovsk State Technical University, Ulyanovsk, Russia Abstract

This article describes an approach to knowledge base (KB) formation for automating the process of architectural design of software systems (SS) based on the experience of previous projects. Software architecting is the presentation of software systems in the form of design artifacts and their architecture. When developing a new SS it is possible to improve its quality based on the experience of previous projects. The experience of previous projects is successful architectural

solutions contained in the knowledge base of the design organization. Such a KB should be formed in the process of analyzing design artifacts extracted from previous projects: source code, project diagrams, data models, structured text resources, etc. This article describes a KB model of a design organization and a model of the 1C: Enterprise 8 (1C) application solution as an example of a design artifact. The article also presents a method for generating fragments of a KB in the process of analyzing an applied solution for the 1C application and a method for generating use-case diagrams based on the KB content. A set of experiments was executed to evaluate the adequacy of the proposed models and methods. The results of experiments for assessing quality in terms of accuracy (the presence of elements of the expert diagram in the generated diagram) and completeness (the presence of elements in the generated diagram that are absent in the expert diagram) are presented. According to the results of the experiments, the average value of accuracy is 0.875, and the completeness is 0.6.

Key words: architecting, software system, design artifact, knowledge base, design experience.

Citation: Guskov GY, Namestnikov AM, Romanov AA, Filippov AA. Formation of a knowledge base to support the architecting process of software systems [In Russian]. Ontology of designing. 2021; 11(2): 154-169. DOI: 10.18287/22239537-2021-11-2-154-169.

Acknowledgment: The authors acknowledge that the work was supported by the framework of the state task of the Ministry of Science and Higher Education of the Russian Federation No.075-00233-20-05 "Research of intelligent predictive multimodal analysis of big data, and the extraction of knowledge from different sources". The reported study was funded by RFBR and the government of Ulyanovsk region according to the research projects: 19-47-730006 and 19-47730005.

List of figures and tables

Figure 1 - Example of a generated ontology Figure 2 - Example of generated use case diagram

Figure 3 - Use case diagram for the "Trade Management" 1C application generated by the system

Figure 4 - Use case diagram for the "Trade Management" 1C application built by the expert

Table 1 - Correspondence between the 1C solution objects and the Oexp ontology axioms

Table 2 - Correspondence between design artifact ontology components and use-case diagram components

Table 3 - Experimental results

References

[1] ISO/IEC/IEEE 42010:2011 Systems and Software Engineering - Architecture Description. 2011. https://www.iso.org/standard/50508.html.

[2] Heesch U, Avgeriou P, Hilliard R. A documentation framework for architecture decisions. Journal Syst. Softw. 2012; 85(4): 795-820. D0I:10.1016/j.jss.2011.10.017.

[3] HilliardR. Using Aspects in Architectural Description. Lecture Notes in Computer Science, 2007; 4765: 65-68.

[4] Sosnin P. Substantially evolutionary theorizing in designing software-intensive systems. Information (Switzerland), 2018; 9 (4): 91.

[5] Sosnin P, Pushkareva A. Ontological controlling the lexical items in conceptual solution of project tasks. // Lecture Notes in Computer, 2017; 10409: 31-46.

[6] ISO/IEC 25010 2011. ISO/IEC 25010:2011: Systems And Software Engineering - Systems And Soft-Ware Quality Requirements And Evaluation (Square) - System And Software Quality Models.

[7] McConnell S. Code complete. - Pearson Education, 2004.

[8] Maklaev VA, Sosnin PI. Instrumental and technological environment for design organization experience formation and usage [In Russian] // Automation of Control Processes. 2009; 2(16): 8-13.

[9] Sosnin PI, Shumilov SS, Ivasev AE. An architectural approach to the precedent-oriented problem solving in the designing of automated systems [In Russian]. Automation of Control Processes. 2019; 1(55): 49-56.

[10] Zagorulko YA, Borovikova OI, Zagorulko GB. Using Ontological Design Patterns to Domain Ontologies Development [In Russian]. Proceedings of the Conference "Knowledge-Ontology-Theory" (30HT-2017). Novosibirsk, 2017. P.139-148.

[11] Muromtsev DI et al. Integration of wiki technology and ontological modeling in the enterprise knowledge management [In Russian]. Proceedings of the RCAI Conference (KHH-2008). Dubna, 2008. P.360-368.

[12] Samoylov DE, Semenova VA, Smirnov SV. Patterns of the structural organization of the system of measured properties in ontological data analysis [In Russian]. Proceedings of the Conference «Control and modeling problems in complex systems». Samara, 2018. P.358-366.

[13] Shaaban AM, Gruber T, Schmittner C. Ontology-based security tool for critical cyber-physical systems // Proceedings of the 23rd International Systems and Software Product Line Conference. 2019; B: 207-210.

[14] Bhatia MPS., Kumar A, Beniwal R. Ontologies for software engineering: past, present and future. Indian Journal of Science and Technology. 2016; 9: 1-16.

[15] Falbo RA et al. An ontology pattern language for service modeling. Proceedings of the 31st Annual ACM Symposium on Applied Computing. 2016. P.321-326.

[16] Ilyas QM. Ontology Augmented Software Engineering. Software Development Techniques for Constructive Information Systems Design. IGI Global, 2013. P.406-413.

[17] Isotani S. et al. Ontology driven software engineering: a review of challenges and opportunities. IEEE Latin America Transactions. 2015; 13: 863-869.

[18] Pan JZ. et al. Ontology-driven software development. Springer Science & Business Media, 2012.

[19] What is 1C:Enterprise? https://1c-dn.com/1c_enterprise/what_is_1c_enterprise/.

[20] PlantUML. UML Diagram Generator. https://plantuml.com.

[21] Protégé. Free, open-source ontology editor and framework for building intelligent systems. https ://protege.stanford. edu.

About the authors

Gleb Yurievich Guskov (b. 1992), graduated from Ulyanovsk State Technical University in 2014, PhD (2018). He is an Associate Professor at Ulyanovsk State Technical University (Department of information systems). He is a co-author of about 30 scientific articles and abstracts in the field of ontology engineering and data mining. Author ID (RSCI): 812005; Author ID (Scopus): 57021635300. g.guskov@ulstu.ru.

Aleksey Mihaylovich Namestnikov (b. 1974), graduated from Ulyanovsk State Technical University in 1996, D. Sc. Eng. (2018). He is a Professor at Ulyanovsk State Technical University (Department of information systems). He is a co-author of about 80 scientific articles and abstracts in the field of CAD and AI. Author ID (RSCI): 392690; Author ID (Scopus): 9277806100. nam@ulstu.ru.

Anton Alekseevich Romanov (b. 1986), graduated from Ulyanovsk State Technical University in 2009, PhD (2013). He is an Associate Professor at Ulyanovsk State Technical University (Department of information systems). He is a coauthor of about 60 scientific articles and abstracts in the field of intelligent systems. ORCID: 0000-0001-5275-7628; Author ID (RSCI): 684949; Author ID (Scopus): 55903279200. romanov73@gmail.com.

Aleksey Aleksandrovich Filippov (b. 1987), graduated from Ulyanovsk State Technical University in 2009, PhD (2013). He is an Associate Professor at Ulyanovsk State Technical University (Department of information systems). He is a co-author of about 80 scientific articles and abstracts in the field of ontology engineering and data mining. ORCID: 0000-0001-5275-7628; Author ID (RSCI): 708454; Author ID (Scopus): 57191472723. al.filippov@ulstu.ru.

Received 27 May, 2021. Revised June 17, 2021. Accepted 23 June, 2021.