Рус Eng Cn Перевести страницу на:  
Please select your language to translate the article


You can just close the window to don't translate
Библиотека
ваш профиль

Вернуться к содержанию

Кибернетика и программирование
Правильная ссылка на статью:

Контролируемое формирование понятий с нечётким значением в архитектурном моделировании систем с программным обеспечением

Соснин Пётр Иванович

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

профессор, кафедра «Вычислительная техника», Ульяновский государственный технический университет

432027, Россия, Ульяновская Область область, г. Ульяновск, ул. Северный Венец, 32

Sosnin Petr

Doctor of Technical Science

Professor, Department of Computer Engineering, Ulyanovsk State Technical University

432027, Russia, Ul'yanovskaya Oblast' oblast', g. Ul'yanovsk, ul. Severnyi Venets, 32

sosnin@ulstu.ru
Куликова Анна Александровна

аспирант, кафедра «Вычислительная техника», Ульяновский государственный технический университет

432027, Россия, Ульяновская область, г. Ульяновск, ул. Северный Венец, 32

Kulikova Anna

Postgraduate Student, Department of Computer Engineering, Ulyanovsk State Technical University

432027, Russia, Ul'yanovskaya oblast', g. Ul'yanovsk, ul. Severnyi Venets, 32

a.push1206@gmail.com
Наместников Алексей Михайлович

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

доцент, кафедра «Информационные системы», Ульяновский государственный технический университет

432027, Россия, Ульяновская область, г. Ульяновск, ул. Северный Венец, 32

Namestnikov Aleksey

Doctor of Technical Science

Associate Professor, Department of Information Systems, Ulyanovsk State Technical University

432027, Russia, Ul'yanovskaya oblast', g. Ul'yanovsk, ul. Severnyi Venets, 32

nam@ulstu.ru

DOI:

10.25136/2644-5522.2019.3.28245

Дата направления статьи в редакцию:

03-12-2018


Дата публикации:

19-11-2019


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


Ключевые слова:

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

Исследование выполнено в рамках грантов Российского фонда фундаментальных исследований (РФФИ) №18-07-00989а, №18-47-730016 р_а, №18-47-732012 р_мк, а также государственного задания №2.1534.2017/4.6.

Abstract: The subject of the research is ontological modeling of concepts (concepts) that are of fuzzy significance, the uncontrolled use of which usually leads to problems with the success of the development of systems that use software intensively (Software Intensive Systems, SIS). The object of the study is the reification of SIS quality characteristics that relate to typical concepts of this type. Particular attention is paid to the requirements of those persons of the project environment (stakeholders), whose diverse interests usually add uncertainty to the requirements for the developed SIS, but must be taken into account in the project without fail. The paper proposes a coordinated application of architectural modeling methods and fuzzy logic for evaluating quality characteristics, which should be computable and controlled during the design process. The novelty of the study is determined by the inclusion in the structure and content of concepts with a fuzzy value of new components that register the dynamics of their formation during the design of a certain SIS so that for each of these concepts the current value of its content allows you to control the achieved value of the degree (level) of professional maturity of the concept. New components are the expansion of the attributes of the concept and the operational computational connection of attributes with the normative work flows, the groups of which are consistent with the levels of professional maturity of the conceptualization of the concepts in the project.


Keywords:

computer-aided design, project ontology, fuzzy logic, software intensive systems, requirements analysis, conceptual space, membership function, applied ontologies, maturity model, estimated value

Введение

В последние годы были предпринят ряд попыток переосмыслить базовые концепции программной инженерии, включая вопросы разработки систем, интенсивно использующих программное обеспечение (SIS), важнейшим подклассом которых являются автоматизированные системы (АС). Основной причиной инновационного переосмысления была и является проблема чрезвычайно низкой степени успешности [1] в создании современных SIS, в решении которой конструктивный учёт человеческого фактора занимает принципиальное место. Среди перспективных попыток переосмысливания концепций следует особо отметить инициативу SEMAT (Software Methods and Theory) [2] и внедрение в практику проектирования SIS методологии проектного мышления (Design Thinking, DT) [3]. Обе эти попытки затрагивают особенности концептуальной активности проектировщиков в реальном процессе проектирования. Для подхода SEMAT это активное использование гибкого мышления, в то время как DT-подход фокусирует внимание проектировщиков на осознании задачных ситуаций, формулировке постановок задач, идей их решения и концептуальном прототипировании. Но практически все попытки исходят из того, что негативные проявления человеческого фактора обусловлены проблемами с пониманием задач, ситуаций и событий в процессах индивидуальной или совместной работы над проектом в условиях непривычной и высокой сложности взаимодействия разработчиков SIS с их проектами.

Одним из принципиальных направлений овладения сложностью и снижения негативных проявлений человеческого фактора, обусловленных проблемами с пониманием, считается архитектурное моделирование SIS [4], в осуществлении которого центральное место занимает снижение сложности взаимодействия с SIS в точках её жизненного цикла за счёт использования совокупности согласованных «точек зрения» (viewpoints) на проект и соответствующих им видов (views), в каждом их которых конструктивно регистрируется необходимое понимание.

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

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

Среди важнейших форм регистрации согласованного понимания необходимо отметить архитектурное описание проектируемой системы. Такое описание состоит из комплекса архитектурных видов, каждый из которых связывает определенную блок-схему с ее описанием на языке проекта LP(t). Качество интегрированных архитектурных решений существенным образом зависит от ядра LP(t), которое целесообразно строить в форме онтологии проекта OP(t), включающей в себя понятия (концепты), без которых обеспечение понимания и повторное использование его зарегистрированных следов невозможно.

Принципиальной особенностью любой онтологии OP(t) является то, что её компоненты должны найти свою объективацию в соответствующем проекте. Это требование распространяется на концепты (понятия), прямо или косвенно связанные с оценкой «успешности» проекта. Среди подобных концептов важное место занимают те из них, которые применяется в описании архитектурных видов, – прежде всего, подмножество концептов, выражающих интересы (concerns), вовлеченных в проект стейкхолдеров. Зачастую нарушения требований, выражающих интересы стейкхолдеров, приводят к неудачам проектирования. С этой точки зрения, часть требований, учитываемых в архитектурных моделях имеет как семантическое выражение, так и оценочное значение: например, требования, предъявляемые к характеристикам качества, – «расширяемость», «масштабируемость», «понятность» и т.д.

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

1. Предпосылки

1.1. Проблемы, связанные с архитектурными описаниями и их характеристиками

Как было отмечено выше, по ходу разработки определенной SIS проектировщики формируют язык проекта, ядро которого содержит значимые концепты – некоторые из них относятся к требованиям (характеристикам), которые должны найти свои спецификации в процессе архитектурного моделирования разрабатываемой SIS. Согласно стандарту ISO/IEC/IEEE 42010:2011, такие характеристики имеют следующее определение: «интересы к разрабатываемой системе, проявляемые одной или рядом заинтересованных сторон».

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

Рис.1. Виды характеристик, выражающих интересы

Понимание заинтересованных сторон и их интересов является основой для создания успешной архитектуры, поскольку разнообразие заинтересованных сторон и их интересов создают плодотворную среду и, соответственно, приводят к сложностям, с которыми сталкиваются архитекторы, а они, в свою очередь, должны учитывать эти сложности при разработке архитектурных решений. Чтобы подчеркнуть значимость данных условий, представим ряд интересов из их списка, приведённого в публикации [6]: приемлемость, доступность, точность, адаптивность, управляемость, ценовая доступность, гибкость, гарантированность, проверяемость, автономность, возможность резервного копирования, соответствие бизнес-целям, сертифицированность, совместимость с другими подсистемами, полнота, сложность, соответствие нормативным требованиям, концептуальная целостность, согласованность, конфиденциальность, конфигурируемость, правильность, настраиваемость, доступность данных, конфиденциальность данных, надежность, удобство развертывания, возможность аварийного восстановления, документируемость, долговечность, легкость обучения, простота использования, экономичность, эффективность, производительность, расширяемость, отказоустойчивость, гибкость, внедряемость, взаимозаменяемость, интуитивность, правомерность, локализуемость, ремонтопригодность, управляемость, мобильность, изменяемость, модульность, открытость, оперативность, переносимость, качество обслуживания, возможность восстановления, соответствие нормативным требованиям, воспроизводимость, время отклика, возможность повторного использования, безопасность, масштабируемость, удобство обслуживания, простота, стабильность, тестируемость, своевременность, отслеживаемость, понятность, удобство использования, универсальность и др. Этот список открыт для включения в него других характеристик, но его можно взять за основу для заимствований в любом проекте (это основная причина включения данного списка в нашу статью).

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

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

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

· Большая часть характеристик, соответствующих требованиям качества, содержит формулы для вычисления их метрик в стандарте ISO/IEC/IEEE 52010:2011 (бывший стандарт ISO 9126), и эти метрики могут использоваться для определения характеристик качества как соответствующих нечетких переменных.

· Для оценок некоторых характеристик можно использовать стандарты, которые предписывают им нормативы профессиональной зрелости – например, CMMI-1.3 Development, PMBOK 5 или P1M3.

· Существуют нечеткие характеристики, которые уже имеют нормативные шкалы для выражения их оценочного значения – например, «информационная безопасность» имеет шкалу с семью уровнями оценки (по стандарту ISO/IEC 15408).

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

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

1.2. Профессиональная зрелость архитектурного моделирования

В предметной области архитектурного моделирования сложился богатейший опыт, практики которого принято квалифицировать и оценивать с позиций профессиональной зрелости, ориентируясь на модели профессиональной зрелости (Maturity Models) [7].

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

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

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

Именно по этой причине архитектурное описание (Architeture Description, AD) в его текущем состоянии (изменяясь при необходимости) востребовано на всех этапах жизненного цикла разработки и эксплуатации соответствующей SIS.

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

Если интерпретировать создание AD в разработке определённой АС как проект по созданию системы (подсистемы AD), то, в связи с вышесказанным, для неё особо значимым атрибутом качества является «сопровождаемость» (maintainability). Учитывая, что подавляющее число атрибутов качества являются нечёткими понятиями, в первом приближении к «архитектурной сопровождаемости» с этим понятием целесообразно связать значение «сопровождаемости» в его понимании, представленном в стандарте ISO/IEC 9126.

Согласно данному стандарту, «сопровождаемость» интегрирует проявления свойств, описанных чуть ниже, за каждым их которых также стоит интеграция совокупности родственных качественных разновидностей, причем также нечётких по своей природе. На первом уровне детализации сопровождаемость включает в себя:

1. Анализируемость (Analyzability), или удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа необходимости изменений и их возможных последствий.

2. Удобство внесения изменений (Changeability) – показатель, обратный трудозатратам на выполнение необходимых изменений.

3. Стабильность (Stability) – показатель, обратный риску возникновения неожиданных эффектов при внесении необходимых изменений.

4. Удобство проверки (Testability) –­ показатель, обратный трудозатратам на проведение тестирования и других видов проверки того, что внесенные изменения привели к нужным результатам.

5. Соответствие стандартам удобства сопровождения (Maintainability compliance).

Учитывая специфику конструкта AD, интерпретируемого как подсистема, применяемая в проектировании АС, используемую в стандарте 9126 спецификацию «сопровождаемости» целесообразно расширить, включив в него характеристику «понятность» (Understandability).

Такой приём осуществлён в [8], где авторы этой публикации приводит версию модели зрелости для разработки AD, представляя «сопровождаемость» композицией следующих атрибутов (и их составляющих): Stability (структурируемость, секционность, сложность), Analyzability (понятность, трассируемость), Changeability (модифицируемость, расширяемость), Testability (в смысле предсказуемость). Для выбранных атрибутов в [8] предложена модель зрелости, в которой специфика уровней зрелости отражена в их названиях:

1. Уровень 1. Диаграммный.

2. Уровень 2. Моделируемый.

3. Уровень 3. Документируемый.

4. Уровень 4. Трассированный.

5. Уровень 5. Обоснованный.

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

1.3. Характеристики проектных онтологий в среде WIQA

Как было отмечено выше, для работы с нечеткими характеристиками авторами принято решение использовать инструментарий OwnWIQA, который включает подсистему для создания проектных онтологий и их объединения в комплексы – например, для семейства связанных проектов (для семейства SIS). Концептуальная модель таких онтологических структур представлена на рис. 2.

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

Рис. 2. Структура создаваемой онтологии проекта

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

Рисунок4

Рис. 3. Типичная структура концепта

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

2. Родственные исследования

Первая группа родственных работ содержит публикации, посвященные месту и роли характеристик, выражающих интересы различных стейкхолдеров, в архитектурном описании систем с программным обеспечением. Глубокий анализ разнообразных характеристик, а также характеристики из стандарта ISO/IEC/IEEE 42010:2011 приводится в публикации [6]. Ряд представлений среды архитектурного моделирования приведён в статье [9], где описываются точки зрения, которые определяют главные принципы для создания и построения архитектурных представлений. В исследовании [10] рассматриваются особенности таких характеристик и точек зрения в сервис-ориентированных приложениях. Реальная практика архитектурных решений обсуждается в публикации [11], учитывающей промышленную разработку SIS. Ретроспективный обзор теории и практики построения архитектурных описаний представлен в работе [12].

Среди работ, посвященных использованию онтологий в проектировании SIS, начнём с публикации [13], в которой отмечено, что в теории и практики применения онтологий в проектировании ещё не накоплено достаточно опыта. Специфика проектных онтологий раскрыта в отчёте [14], в котором основное внимание уделяется «людям, процессу и продукту» и совместному пониманию взаимодействий. Проблемы онтологического сопровождения процессов разработки программных систем раскрыты в работе [15]. Особо отметим публикацию [16], в которой онтология проекта применяется для анализа и формулировки архитектурных требований.

Еще одна группа родственных работ посвящена использованию онтологий и нечетких концептов в практике архитектурного моделирования. В этой группе, прежде всего, необходимо отметить публикацию [17], в которой приведена конструктивная версия онтологического сопровождения процесса формирования требований к разрабатываемой SIS, и статью [18], в которой представлен нечеткий подход к количественной оценке характеристик AD, основанный на архитектурных знаниях. Оригинальная версия онтологического подхода к принятию решений, учитывающая нечёткость используемых понятий, представлена в публикации [19].

3. Онтологическая спецификация архитектурных характеристик

3.1. Масштаб оценочных значений

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

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

2. Текущее состояние характеристики согласуется с другими характеристиками с целью образования соответствующей системы характеристик.

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

4. Материализованы условия, соответствующие представлению характеристики, которые корректируются при достижении запланированного значения.

5. Интегрированная модель состояний характеристики подготовлена и зарегистрирована для повторного использования.

Указанные состояния являются контролируемыми результатами процесса, направленного на достижение запланированного оценочного значения характеристики, интерпретируемой как соответствующее требование. Более того, это достижение подтверждается материализацией данного требования. Что подсказывает решение связать с характеристикой нечеткий атрибут «достигнутое состояние планируемого значения характеристики», который позволил бы в режиме реального времени отслеживать состояния материализации характеристики в ходе проектирования.

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

Рис. 4. Шаблоны функции принадлежности

Шаблоны «a)» и «b)» типичны для архитектурных требований. Они построены и скорректированы для шкалы с пятью уровнями для того, чтобы они соответствовали требованиям качества (шаблон «c)»). Четвертый шаблон «d)» перекликается с семью уровнями оценки по стандарту ISO/IEC 15408.

3.2. Детали реализации

Чтобы использовать и оценивать характеристики, упомянутые в предыдущем разделе, при разработке определенного проекта, мы создали в онтологии специальный подраздел «Характеристики», который может использоваться в качестве основы для различных проектов. Каждый элемент этого подраздела имеет имя, текстовое определение и несколько атрибутов, таких как:

· исполнитель (проектировщик);

· дата;

· представление;

· ссылки на точку зрения стейкхолдеров;

· оценочное значение и т. д.

На рис. 5 показано, как раздел «Характеристики» представлен в инструментальной среде OwnWIQA на примере концепта «удобство использования».

Рисунок6

Рис. 5. Секция «Характеристики» в онтологии проекта

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

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

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

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

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

3.3. Поиск в онтологии

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

1) выбрать текст T для анализа;

2) разбить текст T на словоформы и сформировать список {WF};

3) привести словоформы к нормальной форме с использование морфологического анализатор и сформировать список нормализованных словоформ {(WF, WFN)};

4) M = 0;

5) выбрать нормализованную словоформу с индексом M – WFNM;

6) IF WFNM находится в разделе онтологии «Характеристики» (OPC) THEN BEGIN;

7) добавить слова, связанные с WFNM (WFM-3, WFM-2, WFM-1, WFM+1, WFM+2, WFM+3) в атрибут, относящийся к оценочному значению соответствующего концепта;

8) END;

9) IF в наборе {WFN} ещё есть концепты THEN BEGIN

10) M = M+1;

11) GOTO 5;

12) ELSE END.

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

3.4. Пример использования предлагаемого метода

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

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

Процедура, которая проверяет наличие определенного термина в онтологии проекта и добавляет понятие, если оно отсутствует, может быть запрограммирована на языке псевдокода непосредственно инструментальной среде OwnWIQA (как показано ниже). Для удобства мы создали текстовый файл: «interface_elements.txt», который хранит всю текстовую информацию из прототипа пользовательского интерфейса.

&i& := 0

LABEL &LCycle& // индекс начала цикла

&conceptsNumber& := CountStringsInFile(“C:WIQAinterface_elements.txt”)

IF &i& >= &conceptsNumber& THEN goto &LOut&

&word& := ReadFromFile(&i&, “C:WIQAinterface_elements.txt”)

// чтение строки с индексом i из файла с нормализованными словоформами

&wordID& := Onto_GetWordId(&dictID&, &groupID&, &word&)

IF &wordID& != 0 THEN BEGIN

//если ID слова не равен нулю, то это означает, что данное слово содержится в онтологии

&newWordID& := Onto_CreateWord (&groupID&, &word&)

END

&i& := &i& +1

GOTO &LCycle&

LABEL &LOut&

Заключение

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

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

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

Библиография
1. Chaos reports 1994–2018. The Standish Group International, Inc. – URL: http://www.standishgroup.com (date of access: 11.12.2018).
2. Jacobson I., Ng P.-W., McMahon P., Spence I., Lidman S. The essence of software engineering: the SEMAT kernel // Queue. – 2012. – Vol. 10. – № 10. – P. 1–12.
3. Häger, F., Kowark T., Krüger, J., Vetterli Ch., F Übernickel, F., Uflacker, M.: DT@Scrum: Integrating Design Thinking with Software Development Processes // Design Thinking. Understanding Innovation. – Switzerland : Springer, Cham, 2014. – P. 263-289.
4. Hilliard R. Lessons from the Unity of Architecting // Software Engineering in the Systems, Context. – 2015. – P. 225-250.
5. Sosnin P. Experience-Based Human-Computer Interactions: Emerging Research and Opportunities. – IGI-Global. – Hershey, 2017. – 296 p.
6. Capability Maturity Model Integrated for Development, Version 1.3, 2010. – URL: http://www.sei.cmu.edu/reports/10tr033.pdf (date of access: 15.01.2019).
7. Rathfelder C. and Groenda H. Towards an Architecture Maintainability Maturity Model // Softwaretechnik-Trends. – 2008. – Vol. 28. – №4. – P. 3-7.
8. Sosnin, P. Substantially Evolutionary Theorizing in Designing Software-Intensive Systems // Information, 2018. – Vol. 9. – №4. – P. 1-29.
9. Bedjeti A., Lago P., Lewis G., De Boer R.D., Hilliard R. Modelling Context with an Architecture Viewpoint // Proceedings of IEEE International Conference on Software Architecture. – Gothenburg, Sweden : The Institute of Electrical and Electronics Engineers, Inc., 2017. – Р. 117–120.
10. Gu Q., Lago P. On service-oriented architectural concerns and viewpoints // 2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software. – Architecture, Cambridge, 2009. – P. 289-292.
11. Dasanayake S., Markkula J., Aaramaa S., Oivo M. Software Architecture Decision-Making Practices and Challenges: An Industrial Case Study // Proceedings of 24th Australasian Software Engineering Conference. – Adelaide, SA, Australia : ACM, 2015. – P. 88–97.
12. Hasselbring W. Software Architecture: Past, Present, Future. In: Gruhn V., Striemer R. // The Essence of Software Engineering. – Switzerland : Springer, 2018. – P. 168-184.
13. Garcia A.C.B., Kunz J., Ekstrom M. Kiviniemi A. Building a Project Ontology with Extreme Collaboration and Virtual Design & Construction // CIFE Technical Report #152. – Stanford University, 2003.
14. Fitsilis P., Gerogiannis V., Anthopoulos L. Ontologies for Software Project Management // A Review, Journal of Software Engineering and Applications. – 2014. – Vol. 713. – P. 1096-1110.
15. Eden A.H., Turner R. Problems in the Ontology of Computer Programs // Applied Ontology. – Amsterdam, IOS Press, 2007. – Vol. 2. – P. 13-36.
16. Bhat M., Shumaiev K., Biesdorf A., Hohenstein U., Hassel M., Matthes F. An Ontology-based Approach for Software Architecture Recommendations // 23rd Americas Conference on Information Systems. – AMCIS. – 2017. – Vol. 4. – P. 3110-3120.
17. Alashqar A.M., El-Bakry H.M., Abo Elfetouh A. A Framework for Selecting Architectural Tactics Using Fuzzy Measures // International Journal of Software Engineering and Knowledge Engineering. – 2015. – Vol. 27. – P. 475–498.
18. Dhaya C., Zayaraz G. Fuzzy based Quantitative Evaluation of Architectures using Architectural Knowledge // International Journal of Advance Science and Technology. – 2012. – P. 137-154.
19. Di Noia T., Mongiello M., Nocera F., Straccia U. A fuzzy ontology-based approach for tool-supported decision making in architectural design // Knowledge and Information Systems. – 2018. – P. 1–30.
References
1. Chaos reports 1994–2018. The Standish Group International, Inc. – URL: http://www.standishgroup.com (date of access: 11.12.2018).
2. Jacobson I., Ng P.-W., McMahon P., Spence I., Lidman S. The essence of software engineering: the SEMAT kernel // Queue. – 2012. – Vol. 10. – № 10. – P. 1–12.
3. Häger, F., Kowark T., Krüger, J., Vetterli Ch., F Übernickel, F., Uflacker, M.: DT@Scrum: Integrating Design Thinking with Software Development Processes // Design Thinking. Understanding Innovation. – Switzerland : Springer, Cham, 2014. – P. 263-289.
4. Hilliard R. Lessons from the Unity of Architecting // Software Engineering in the Systems, Context. – 2015. – P. 225-250.
5. Sosnin P. Experience-Based Human-Computer Interactions: Emerging Research and Opportunities. – IGI-Global. – Hershey, 2017. – 296 p.
6. Capability Maturity Model Integrated for Development, Version 1.3, 2010. – URL: http://www.sei.cmu.edu/reports/10tr033.pdf (date of access: 15.01.2019).
7. Rathfelder C. and Groenda H. Towards an Architecture Maintainability Maturity Model // Softwaretechnik-Trends. – 2008. – Vol. 28. – №4. – P. 3-7.
8. Sosnin, P. Substantially Evolutionary Theorizing in Designing Software-Intensive Systems // Information, 2018. – Vol. 9. – №4. – P. 1-29.
9. Bedjeti A., Lago P., Lewis G., De Boer R.D., Hilliard R. Modelling Context with an Architecture Viewpoint // Proceedings of IEEE International Conference on Software Architecture. – Gothenburg, Sweden : The Institute of Electrical and Electronics Engineers, Inc., 2017. – R. 117–120.
10. Gu Q., Lago P. On service-oriented architectural concerns and viewpoints // 2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software. – Architecture, Cambridge, 2009. – P. 289-292.
11. Dasanayake S., Markkula J., Aaramaa S., Oivo M. Software Architecture Decision-Making Practices and Challenges: An Industrial Case Study // Proceedings of 24th Australasian Software Engineering Conference. – Adelaide, SA, Australia : ACM, 2015. – P. 88–97.
12. Hasselbring W. Software Architecture: Past, Present, Future. In: Gruhn V., Striemer R. // The Essence of Software Engineering. – Switzerland : Springer, 2018. – P. 168-184.
13. Garcia A.C.B., Kunz J., Ekstrom M. Kiviniemi A. Building a Project Ontology with Extreme Collaboration and Virtual Design & Construction // CIFE Technical Report #152. – Stanford University, 2003.
14. Fitsilis P., Gerogiannis V., Anthopoulos L. Ontologies for Software Project Management // A Review, Journal of Software Engineering and Applications. – 2014. – Vol. 713. – P. 1096-1110.
15. Eden A.H., Turner R. Problems in the Ontology of Computer Programs // Applied Ontology. – Amsterdam, IOS Press, 2007. – Vol. 2. – P. 13-36.
16. Bhat M., Shumaiev K., Biesdorf A., Hohenstein U., Hassel M., Matthes F. An Ontology-based Approach for Software Architecture Recommendations // 23rd Americas Conference on Information Systems. – AMCIS. – 2017. – Vol. 4. – P. 3110-3120.
17. Alashqar A.M., El-Bakry H.M., Abo Elfetouh A. A Framework for Selecting Architectural Tactics Using Fuzzy Measures // International Journal of Software Engineering and Knowledge Engineering. – 2015. – Vol. 27. – P. 475–498.
18. Dhaya C., Zayaraz G. Fuzzy based Quantitative Evaluation of Architectures using Architectural Knowledge // International Journal of Advance Science and Technology. – 2012. – P. 137-154.
19. Di Noia T., Mongiello M., Nocera F., Straccia U. A fuzzy ontology-based approach for tool-supported decision making in architectural design // Knowledge and Information Systems. – 2018. – P. 1–30.

Результаты процедуры рецензирования статьи

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

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

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

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

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

Стиль изложения научный. Статья написана русским литературным языком.

Структура рукописи включает следующие разделы: 1. Введение (разработка систем, интенсивно использующих программное обеспечение (SIS), автоматизированные системы (АС), конструктивный учёт человеческого фактора, инициатива SEMAT (Software Methods and Theory), внедрение методологии проектного мышления (Design Thinking, DT), архитектурное моделирование SIS, достижение достаточного понимания, язык проекта LP(t), архитектурное описание проектируемой системы, онтология проекта OP(t), подмножество концептов, выражающих интересы (concerns) вовлеченных в проект стейкхолдеров, инструментальная среда моделирования OwnWIQA), 2. Предпосылки, 2.1. Проблемы, связанные с архитектурными описаниями и их характеристиками (интересы к разрабатываемой системе, проявляемые одной или рядом заинтересованных сторон, виды характеристик, выражающих интересы, оценочное значение характеристики, подходы к нечёткой спецификации характеристик, которые имеют оценочное значение, построениt подходящей функции принадлежности), 2.2. Профессиональная зрелость архитектурного моделирования (модели профессиональной зрелости (Maturity Models), уровни профессиональной зрелости «сопровождаемость», «понятность»), 2.3. Характеристики проектных онтологий в среде WIQA (структура создаваемой онтологии проекта, типичная структура концепта), 3. Родственные исследования (характеристики из стандарта ISO/IEC/IEEE 42010:2011, представления среды архитектурного моделирования, особенности характеристик и точек зрения в сервис-ориентированных приложениях, практика архитектурных решений, обзор теории и практики построения архитектурных описаний, специфика проектных онтологий, проблемы онтологического сопровождения процессов разработки программных систем, конструктивная версия онтологического сопровождения процесса формирования требований к разрабатываемой SIS, нечёткий подход к количественной оценке характеристик AD, основанный на архитектурных знаниях, оригинальная версия онтологического подхода к принятию решений, учитывающая нечёткость используемых понятий), 4. Онтологическая спецификация архитектурных характеристик, 4.1. Масштаб оценочных значений (адекватная спецификация и запланированная материализация, стадии материализации характеристик AD, шаблоны функции принадлежности), 4.2. Детали реализации (подраздел «Характеристики» – исполнитель (проектировщик), дата, представление, ссылки на точку зрения стейкхолдеров, оценочное значение и т. д., базовые и дополнительные атрибуты), 4.3. Поиск в онтологии (алгоритм инструментария по поиску концептов онтологии в проектных документах и получения потенциальных значений концептов из этих текстов), 4.4. Пример использования предлагаемого метода (характеристики «понятность» и «удобство использования» пользовательского интерфейса), Заключение (выводы), Библиография.

Раздел «Введение» нумеровать не следует. Текст включает шесть рисунков. Содержание рисунка 2 может быть представлено в текстовой форме. Точку в названии рисунка 6 следует удалить.

Содержание в целом соответствует названию. Возможно, в формулировке заголовка следует более конкретно отразить предмет исследования, связанный с инициативой SEMAT (Software Methods and Theory), методологией проектного мышления (Design Thinking, DT), а также архитектурным моделированием SIS.

Библиография включает 20 источников зарубежных авторов – монографии, научные статьи, материалы научных мероприятий, Интернет-ресурсы. Библиографические описания некоторых источников нуждаются в корректировке в соответствии с ГОСТ и требованиями редакции, например:
1. Chaos reports 1994–2018. The Standish Group International, Inc. – URL: http://www.standishgroup.com (date of access: 11.12.2018).
3. Jacobson I., Ng P.-W., McMahon P., Spence I., Lidman S. The essence of software engineering: the SEMAT kernel // Queue. – 2012. – Vol. 10. – № 10. – P. 1–12.
4. Häger F., Kowark T., Krüger J., Vetterli Ch., Übernickel F., Uflacker M. DT@Scrum: Integrating Design Thinking with Software Development Processes // Design Thinking. Understanding Innovation. – Место издания ??? : Наименование издательства ???, 2014. – P. 263–289.
10. Bedjeti A., Lago P., Lewis G., De Boer R.D., Hilliard R. Modelling Context with an Architecture Viewpoint // Proceedings of IEEE International Conference on Software Architecture. – Место издания ??? : Наименование издательства ???, 2017. – Р. ???–???.
12. Dasanayake S., Markkula J., Aaramaa S., Oivo M. Software Architecture Decision-Making Practices and Challenges: An Industrial Case Study // Proceedings of 24th Australasian Software Engineering Conference. – Место издания ??? : Наименование издательства ???, 2015. – P. 88–97.
20. Di Noia T., Mongiello M., Nocera F., Straccia U. A fuzzy ontology-based approach for tool-supported decision making in architectural design // Knowledge and Information Systems. – 2018. – P. 1–30.

Апелляция к оппонентам (Jacobson I., Ng P.-W., McMahon P., Spence I., Lidman S., Häger F., Kowark T., Krüger J., Vetterli Ch., Übernickel F., Uflacker М., Sosnin P., Hilliard R., Rathfelder C., Groenda H., Bedjeti A., Lago P., Lewis G., De Boer R. D., Hilliard R., Gu Q., Lago P., Dasanayake S., Markkula J., Aaramaa S., Oivo M., Hasselbring W., Garcia A. C. B., Kunz J., Ekstrom M., Kiviniemi A., Fitsilis P., Gerogiannis V., Anthopoulos L., Eden A. H., Turner R., Bhat M., Shumaiev K., Biesdorf A., Hohenstein U., Hassel M., Matthes F., Alashqar A. M., El-Bakry H. M., Abo Elfetouh A., Dhaya C., Zayaraz G., Di Noia T., Mongiello M., Nocera F., Straccia U.) имеет место.

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