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

Соснин Пётр Иванович доктор технических наук профессор, кафедра «Вычислительная техника», Ульяновский государственный технический университет 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

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

Введение

В последние годы были предпринят ряд попыток переосмыслить базовые концепции программной инженерии, включая вопросы разработки систем, интенсивно использующих программное обеспечение (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, где видно, что семантическое значение любого компонента обычно выражается его именем.

Рис. 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 на примере концепта «удобство использования».

Рис. 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. Такой выбор основан на практике (методике), которая позволяет достичь запланированной версии объективизации характеристик. Кроме того, он помогает регистрировать историю изменения состояний соответствующих требований.