Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях
Предлагается модель связи онтологии, лежащей в основе разработки системы, с набором требований к ней. Минимальный набор требований формируется на основе онтологии предметной области и с учетом традиционного распределения функций между подсистемами такой системы. Модель обеспечивает возможность ав...
Saved in:
| Date: | 2009 |
|---|---|
| Main Author: | |
| Format: | Article |
| Language: | Russian |
| Published: |
Інститут проблем штучного інтелекту МОН України та НАН України
2009
|
| Subjects: | |
| Online Access: | https://nasplib.isofts.kiev.ua/handle/123456789/8161 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Cite this: | Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях / Е.А. Шалфеева // Штучний інтелект. — 2009. — № 4. — С. 472-481. — Бібліогр.: 4 назв. — рос. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1859643977201876992 |
|---|---|
| author | Шалфеева, Е.А. |
| author_facet | Шалфеева, Е.А. |
| citation_txt | Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях / Е.А. Шалфеева // Штучний інтелект. — 2009. — № 4. — С. 472-481. — Бібліогр.: 4 назв. — рос. |
| collection | DSpace DC |
| description | Предлагается модель связи онтологии, лежащей в основе разработки системы, с набором требований
к ней. Минимальный набор требований формируется на основе онтологии предметной области и с
учетом традиционного распределения функций между подсистемами такой системы. Модель обеспечивает
возможность автоматического формирования таких требований.
Пропонується модель зв’язку онтології, що лежить в основі розробки системи, з набором вимог до
неї. Мінімальний набір вимог формується на основі онтології предметної області та з урахуванням
традиційного розподілу функцій між підсистемами такої системи. Модель забезпечує можливість
автоматичного формування таких вимог.
The model of linkage which is at the heart of a system development and system requirements set is offered.
Minimal requirements set is formulated on the basis of domain and and taking into account traditional functions
distributing between subsystems. The model gives an opportunity for automatic requirements formulation.
|
| first_indexed | 2025-12-07T13:25:02Z |
| format | Article |
| fulltext |
«Искусственный интеллект» 4’2009 472
8Ш
В
УДК 004.8
Е.А. Шалфеева
Институт автоматики и процессов управления ДВО РАН, г. Владивосток, Россия
shalf@iacp.dvo.ru
Модель связи структурных свойств онтологии
со структурой модели требований системы,
основанной на редактируемых знаниях*
Предлагается модель связи онтологии, лежащей в основе разработки системы, с набором требований
к ней. Минимальный набор требований формируется на основе онтологии предметной области и с
учетом традиционного распределения функций между подсистемами такой системы. Модель обеспечивает
возможность автоматического формирования таких требований.
Создание и внедрение экспертных систем выдвинуло проблему технологической
поддержки разработок в области искусственного интеллекта на передний план [1].
Ввиду все возрастающего использования систем искусственного интеллекта в конк-
ретных приложениях, к ним начинают предъявляться практически те же требования,
что и к традиционным программным комплексам и системам. В связи с этим становится
весьма актуальной поддержка жизненного цикла разработки этих систем. Как и в случае
обычных программных систем, разработка системы искусственного интеллекта должна
начинаться с формулирования полных, непротиворечивых и однозначных требований к
ней [2]. Таким образом, создание ПО систем, основанных на знаниях, (СОЗ) имеет как
общие моменты с разработкой традиционных систем ПО, так и свою специфику, кото-
рая явным образом должна отражаться в соответствующих моделях жизненного цикла.
Традиционно при разработке СОЗ используется формализованная онтология пред-
метной области, а сами СОЗ включают в себя типичные архитектурные компоненты, в
числе которых есть редактор знаний и подсистема решения задач пользователя. Редак-
тор знаний вместе с базой знаний являются относительно независимой подсистемой,
ориентированной на своего пользователя – эксперта предметной области и инженера
знаний. Поэтому функциональные требования к ней могут рассматриваться отдельно от
требований к остальной части СОЗ, ориентированной на специалиста, решающего зада-
чи в своей предметной области.
В статье рассматривается возможность поддержки автоматического формирова-
ния требований к обеим подсистемам на основе онтологий, лежащих в основе разра-
ботки системы.
Постановка задачи
Формулирование полных, непротиворечивых и однозначных требований начи-
нается с их явного представления в виде документа. Известно, что учет разных точек
зрения при создании требований обеспечивает их максимальную адекватность. Важны
как точки зрения разных участников разработки, так и разные аспекты их представле-
ния – функциональный, информационный, поведенческий.
* Работа выполнена при финансовой поддержке ДВО РАН, проект «Обеспечение качества
интеллектуального программного обеспечения в процессе его проектирования на основе онтологий».
Модель связи структурных свойств онтологии со структурой модели...
«Штучний інтелект» 4’2009 473
8Ш
Онтология предметной области, лежащая в основе разрабатываемой СОЗ, со-
держит согласованное мнение экспертов, а с другой стороны, охватывает функцио-
нальный и информационный аспекты анализа требований к программному обеспече-
нию, разрабатываемому в предметной области.
В модели онтологии предметной области целесообразно различать две составляю-
щие – систему понятий знаний (вместе с ограничениями целостности знаний) и систему
понятий действительности (вместе с ограничениями целостности ситуаций).
Обе составляющие по форме представления схожи и соответствуют типичным
представлениям об онтологии, как взаимосвязанной совокупности определений тер-
минов-сущностей, терминов-связей и онтологических соглашениях об ограничениях
на их интерпретацию:
Онтология = ({Сущностьk},{Связьl},{Соглашениеm}).
Часто формальное представление системы понятий знаний и системы понятий
действительности размещены в разных теориях (модулях) онтологии предметной
области. Например, для решения задачи построения рентгеновского спектра терминами
системы понятий действительности являются: источник возбуждающего излучения,
активность источника, относительная эффективность регистрации, энергетичес-
кое разрешение, угол падения первичного излучения, угол отбора вторичного излуче-
ния, количество каналов, коэффициенты калибровки, плотность пробы, толщина пробы
и др. А система понятий знаний включает: характеристические линии элемента, энер-
гия характеристического излучения, энергии линий изотопа, сечение возбуждения и др.
Выделяют также и такую часть модели онтологии, как связь знаний и действи-
тельности, которая, например, может содержать все формулы, требующиеся для полу-
чения решения конкретных задач.
Такое разделение позволяет использовать систему понятий знаний (вместе с огра-
ничениями целостности знаний) для поддержки формирования требований к редактору
знаний, а систему понятий действительности и связь знаний и действительности –
для поддержки формирования требований к подсистеме решения задач. Требуется по-
лучить модель связи онтологии с набором требований, которые могут быть получены
исходя из описания предметной области и из традиционного распределения функций
между подсистемами СОЗ. Прочие требования, если они есть, будут добавлены анали-
тиком к этому методологически обоснованному набору требований.
Формальное представление онтологии дает возможность извлекать ее внутреннее
содержание, структуру и оценивать внутренние свойства, это позволяет построить модель
связи структурных свойств онтологии со структурой модели требований. Получаемый та-
ким способом набор требований должен обеспечить «каркас» для их точной спецификации.
Формирование требований к СОЗ
Традиционно документ, описывающий требования к программному обеспечению,
включает в себя такие подразделы (группы требований), как: общие функциональные
требования, требования к качеству и эксплуатационным характеристикам, описание
информации, описание поведения, спецификации функций, описание критериев для
подтверждения и др.
Общие функциональные требования включают описание предназначения всей
СОЗ, их написание не является рутинной работой и не требует автоматизации. При-
мер формулировки для СОЗ, выполняющей построение характеристического рентге-
новского спектра1, таков. «Программная система должна выполнять построение ха-
1 Первая версия разработана в лаборатории интеллектуальных систем ИАПУ ДВО РАН.
Шалфеева Е.А.
«Искусственный интеллект» 4’2009 474
8Ш
рактеристического рентгеновского спектра по известным элементному составу про-
бы и ее геометрическим свойствам, позволять выполнять перемещение по графику и его
масштабирование, позволять сохранять полученный спектр в файл, позволять до-
бавлять, изменять и удалять знания, используемые при построении спектра».
Далее для СОЗ явно указывается (или оно очевидно) распределение общих функ-
ций по подсистемам, как минимум, по двум – подсистемы для эксперта и для пользо-
вателя. Например, редактор знаний должен: позволять пользователю просматривать,
добавлять, изменять и удалять информацию обо всех сущностях, знания о которых не
зависят от текущего состояния действительности, но используются для решения задач.
«Построитель» должен: позволять пользователю задавать входные условия задачи,
решать задачу и обеспечивать удобство при просмотре результатов.
Более конкретные функциональные требования (типичный минимум для таких
систем) и описание информации создаются на основе метода анализа структуры онто-
логий [2], [3]. Требования к качеству и эксплуатационным характеристикам слишком
мало связаны с моделью предметной области, поэтому к рассматриваемой методоло-
гии не относятся. Описание поведения мало связано с моделью предметной области,
но может быть формализовано на основе модели пользовательских задач, которая бази-
руется на онтологии пользовательских задач. Формализация описания поведения воз-
можна, но основана на другой онтологии и модели. А описание критериев для под-
тверждения достаточно легко формулируется при наличии готовых спецификаций
функций и описании используемой информации.
Модель для формирования требований к подсистеме
редактирования знаний. Описание функций
Наиболее популярный случай определения сущностей в онтологии знаний – их
описание названием и атрибутами:
Сущность = (Название, 1..*{Атрибутi}).
Структура соответствующего фрагмента текста онтологии знаний (на языке
прикладной логики [4]) такова:
сорт «названиеСущ»: {}n;
{сорт «названиеАтр»: ( «названиеСущ» СтдТип)},
где СтдТип – предопределенное множество значений или его подмножество, напри-
мер, все положительные целые.
Кроме формального подхода к выявлению атрибутов сущности может быть
применен анализ смысла названия, а именно: «названиеАтр», как правило, не указы-
вает на процесс или действие.
Менее распространены случаи, когда сущность задается только своим назва-
нием, либо задается как частный случай другой сущности (или подмножество неко-
торого множества).
Типичный набор функций для редактора знаний связан с вводом всех таких
сущностей (составных объектов) и их атрибутов: добавление сущности, добавление \
изменение одного или нескольких атрибутов, удаление сущности.
Модель отображения структуры онтологии на структуру требований включает
следующую пару (элементы онтологии – элементы требований).
Онтология. Сущность = (Название, 1..*{Атрибутi})
Требования.
ФункцииРедактированиеДанных.
Ф-Добавить-Экземпляр-Сущности<Название>;
Модель связи структурных свойств онтологии со структурой модели...
«Штучний інтелект» 4’2009 475
8Ш
Вход: Название,
Выход: обновленная таблица экземпляров сущности;
Ф-Удалить-Экземпляр-Сущности<Название>;
Вход: Название,
Выход: обновленная таблица экземпляров сущности;
1..*{Ф-Изменить-Атрибут<Атрибутi>Экземпляра-Сущности<Название>
Вход: Атрибутi,
Выход: обновленный набор атрибутов экземпляра сущности;
}
Достаточно распространено в онтологии знаний задание агрегирующих связей,
когда сущность включает в себя набор однотипных частей либо характеризующих ее
других сущностей:
Онтология.Связь = (ХарактеристикаИлиЧасть,
НазваниеСущности,
1..*{ОблЗначХарактеристикаИлиЧасть i}),
здесь 1..* – указывает на кардинальность связи сущности со своей характеристикой
или частью – «не менее одного».
В этом случае к набору функций редактора знаний должен быть добавлен ввод
всех этих компонентов сущностей.
Обычно в онтологии задаются также свойства этих компонентов (характеристик
или частей) – так называемые совместные свойства сущности и ее компонента.
Онтология. Связь = (НазваниеСвязи, (НазваниеСущности,
ОблЗначХарактеристикаИлиЧасть ), ОблЗначСвязи)
Это требует добавления к функциональности редактора ввода всех «совместных
свойств» (добавить запись о совместных свойствах, изменить одно или несколько
совместных свойств, удалить запись).
Пример. В онтологии знаний вышеупомянутой задачи каждому элементу сопо-
ставлены «энергетические уровни»:
сорт энергетические уровни элемента:
( химические элементы {}энергетические уровни ).
Есть также функции, сопоставляющие всем таким парам некоторые действитель-
ные числа:
сорт энергия связи: ( {(v: (× химические элементы, энергетические уровни))
π(2, v) энергетические уровни элемента(π(1, v))} r(0; +∞) )
сорт скачок поглощения: ( {(v: (× химические элементы, энергетические уровни))
π(2, v) энергетические уровни элемента(π(1, v))} r(1; +∞) )
Модель отображения структуры онтологии на структуру требований включает
также следующие блоки (вход и выход функций для краткости опустим).
Онтология. Связь =(ХарактеристикаИлиЧасть, НазваниеСущности,
1..*{ОблЗначХарактеристикаИлиЧасть i})
Требования.
ФункцииРедактированиеДанных.
Ф-Добавить-Экземпляр-ХарактеристикиИлиЧасти
<ХарактеристикаИлиЧасть>Экземпляра-Сущности
<НазваниеСущности>;
Ф-Удалить-Экземпляр-ХарактеристикиИлиЧасти
<ХарактеристикаИлиЧасть>Экземпляра-Сущности
<НазваниеСущности>;
и
Онтология. Связь = (НазваниеСвязи, (НазваниеСущности,
ОблЗначХарактеристикаИлиЧасть ), ОблЗначСвязи)
Шалфеева Е.А.
«Искусственный интеллект» 4’2009 476
8Ш
И
Онтология. Связь = (НазваниеСущности, 1..*{ХарактеристикаИлиЧасть i})
Требования.
ФункцииРедактированиеДанных.
Ф-Добавить-СовмСвойство<НазваниеСвязи>Сущности <НазваниеСущности>
и Сущности<ХарактеристикаИлиЧасть>;
Ф-Удалить-СовмСвойство<НазваниеСвязи>Сущности< НазваниеСущности>
и Сущности<ХарактеристикаИлиЧасть>;
1..*{Ф-Изменить-Значение-Свойства<НазваниеСвязи>Сущности<
НазваниеСущности>и Сущности< ХарактеристикаИлиЧасть>;
Ограничения на значения сущностей и/или их свойств являются важной инфор-
мацией при разработке редактора знаний. Онтология знаний и ее раздел «Ограничения
целостности знаний» позволяет получить эту информацию.
Каждое онтологическое соглашение является источником функционального тре-
бования к редактору знаний, если оно содержит в качестве операндов вводимые и из-
меняемые сущности, атрибуты, характеристики, части, свойства.
Например, предложение онтологии
(v: энергетические уровни) орбитальное квантовое число(v) < главное квантовое число
энергетического уровня(v)
приводит к необходимости функции контроля вводимой информации в соответствии с
утверждением: при вводе орбитального квантового числа любого энергетического уров-
ня электронной оболочки проверить, чтобы оно было меньше главного квантового числа
электронной оболочки. Такая проверка должна быть активизирована в редакторе вся-
кий раз, когда вводится новое значение атрибута – орбитальное квантовое число и глав-
ное квантовое число, чтобы сопоставить с введенными ранее значениями.
Для анализа очередности активизации функции (чтобы работала в паре с соот-
ветствующей функцией ввода) важно увидеть в структуре соглашения отдельные опе-
ранды, а для формулирования функции важен сам текст. Поэтому минимальная модель
структуры соглашения такова.
Онтология.Соглашение = Онтология.Соглашение.Текст
+ Онтология.Соглашение.Операнды
Онтология.Соглашение.Операнды = {ЗначениеСвойства| ЗначениеАтрибута|
ЗначениеХарактеристикиИлиЧасти}
Если есть в соглашениях условия на некоторое данное, то в редакторе при ввод/
добавлении/изменении должны быть подфункции, обеспечивающие выполнение этих
условий. Для каждого отдельно добавляемого данного – своя функция проверки или
набор подфункций по каждому условию.
Модель отображения структуры онтологии на структуру требований должна вклю-
чать следующий блок.
Онтология.Соглашение = Онтология.Соглашение.Текст +
Онтология.Соглашение.Операнды
И
Операндj= Атрибутi | ЗначениеХарактеристикиИлиЧастиs
Требования.
ФункцииПроверкиДанных.
Ф-проверить-выполнение-ограничения.
Вход: Операндj,
Описание: <Текст>;
Выход: Boolean и сообщение пользователю о некорректности ввода.
Вышеперечисленный (и зафиксированный в модели отображения структуры онтоло-
гии на структуру требований) набор требований является проверяемым и однозначно по-
Модель связи структурных свойств онтологии со структурой модели...
«Штучний інтелект» 4’2009 477
8Ш
нимаемым. Такой набор может быть передан аналитиком проектировщику или кодиров-
щику, он же становится основой для формулирования критериев для подтверждения.
Этими достоинствами не обладает следующая формулировка требования к редактору,
созданная вне рассматриваемой методологии: «При нажатии кнопки “Изменить” рядом
с таблицей “Энергетические уровни электронной оболочки” новые значения (в полях
ввода) свойств выделенного энергетического уровня выделенной электронной оболочки
должны быть проверены на корректность с помощью условий, таких как “У каждого
энергетического уровня орбитальное квантовое число меньше главного квантового числа
электронной оболочки, которой этот энергетический уровень принадлежит”. Если
значения корректны, то в базе знаний и в таблице “Энергетические уровни электронной
оболочки” значения свойств выделенного энергетического уровня выделенной электрон-
ной оболочки должны быть изменены на указанные. Если значения некорректны, то
должно быть выведено сообщение о недопустимости указанных значений». Такая фор-
мулировка оправданна, когда аналитик является и проектировщиком, и кодировщиком, и
испытателем, т.е. фиксирует требования «для себя».
Модель для формирования требований к подсистеме
редактирования знаний. Описание информации
Если программное обеспечение создается в рамках одной предметной области,
то ожидается, что все объекты данных редактора знаний присутствуют в онтологии
знаний. Анализ теоретико-множественных связей между сущностями в онтологии
знаний (и/или таксономических связей) редактора знаний позволяет сформировать
описание входных данных для редактора знаний.
Модель отображения структуры онтологии на структуру требований включает
следующую пару (элементы онтологии – элементы требований).
Онтология. Атрибут = (НазваниеСущности, Название Атрибута, ОбластьЗначений)
Требования.
Спецификация входных данных.
Сущность. Название Атрибута. ОбластьЗначений
Например, на основе фрагмента онтологии знаний
сорт орбитальное квантовое число: (энергетические уровни i[0; +∞) )
и
сорт спин-орбитальное связывание: (энергетические уровни r[1/2; +∞) )
будут сформированы области определений двух атрибутов сущности «энергетические
уровни»:
энергетические уровни. орбитальное квантовое число
имеет область значений целые числа в диапазоне [0; +∞);
энергетические уровни. спин-орбитальное связывание
имеет область значений действительные числа в диапазоне [1/2; +∞) ).
Модель для формирования требований
к подсистеме решения задач
Терминологию, связанную с решением задач, отражают такие части онтологии,
как система понятий действительности и связь знаний и действительности. Кроме
того, необходима спецификация задач или класса задач для разрабатываемой СОЗ,
которая позволяет выделить среди терминов система понятий действительности те,
что являются пользовательскими входными данными, и те – что выходными.
Для подсистемы решения задач характерны такие группы функций, как функ-
ции «вычислительные» и функции «взаимодействия с пользователем».
Шалфеева Е.А.
«Искусственный интеллект» 4’2009 478
8Ш
Формирование «вычислительных» функций по онтологии включает два этапа.
Первый на основе системы понятий действительности дает спецификацию назва-
ния и входа-выхода функции.
Например, по предложениям онтологии:
сорт элементы пробы: {}химические элементы
характеристические линии ≡ радиационные переходы
сорт радиационные переходы: {}n
сорт интенсивность характеристической линии: ( {(v: ( элементы пробы,
характеристические линии)) (2, v) характеристические линии
элемента((1, v))} r[0; +) )
сорт площадь пика: ( {(v: {(w: ( элементы пробы, характеристические линии))
(2, w) характеристические линии элемента((1, w)}) интенсивность
характеристической линии(v) > 0} r(0; +) )
формируются первичные спецификации двух функций:
Найти интенсивность характеристической линии
Вход: 1) элементы пробы: множество подмножеств множества «химические элементы»,
2) характеристические линии: множество подмножеств множества названий
Выход: интенсивность: Действительное число в диапазоне [0; +)
Найти площадь пика
Вход: 1) элементы пробы: множество подмножеств множества «химические элементы»,
2) характеристические линии: множество подмножеств множества названий
Выход: площадь пика: Действительное число в диапазоне [0; +)
Модель отображения структуры онтологии действительности на структуру требо-
ваний включает следующую пару (элементы онтологии – элементы требований).
Онтология. Связь = (НазваниеФункции, 1..*{НазваниеАргументаj}
Область ЗначенийФункции)
И
Онтология. Сущность = (НазваниеАргументаj, Область Определения)
Требования.
ФункцииВычисления.
Ф-<НазваниеФункции>.
Вход: 1..*{( НазваниеАргументаj, Область Определения)}
Выход: (НазваниеФункции, Область ЗначенийФункции)
На основе модели «связь знаний и действительности» спецификация дополняется
описанием сути преобразования входных данных в выходные.
В соответствии с фрагментами вида
Онтология. Формула = ({Локальная Переменнаяj, ОбластьОпредПеременнойj},
НазваниеФункции, ТекстФормулы)
модель отображения расширяется таким образом:
Ф-<НазваниеФункции>.
Вход: 1..*{( НазваниеАргументаj, Область Определения)}
Описание: ТекстФормулы
Выход: (НазваниеФункции, Область ЗначенийФункции)
Пример. Система понятий действительности содержит предложение:
(el: элементы пробы) (hl: характеристические линии элемента(el)) интенсивность ха-
рактеристической линии(el, hl) = содержание элемента в пробе(el) * инструментальная
постоянная * относительная эффективность регистрации (энергия характеристического
излучения(el, hl)) * активность источника * (∑(e: энергии линий изотопа (источник воз-
буждающего излучения)) выход линии (источник возбуждающего излучения, e) * ((се-
чение возбуждения(el, hl))(e) * (фактор поглощения(el, hl))(e) + (фактор вторичного воз-
буждения(el, hl))(e)))
Модель связи структурных свойств онтологии со структурой модели...
«Штучний інтелект» 4’2009 479
8Ш
Итоговое требование таково:
Найти интенсивность характеристической линии
Вход: 1) элементы пробы: множество подмножеств множества «химические элементы»,
2) характеристические линии: множество подмножеств множества названий
Описание: (el: элементы пробы) (hl: характеристические линии элемента(el)) интенсив-
ность характеристической линии(el, hl) = содержание элемента в пробе(el) * инст-
рументальная постоянная * относительная эффективность регистрации (энергия харак-
теристического излучения(el, hl)) * активность источника * (∑(e: энергии линий изотопа
(источник возбуждающего излучения)) выход линии (источник возбуждающего излу-
чения, e) * ((сечение возбуждения(el, hl))(e) * (фактор поглощения(el, hl))(e) + (фактор
вторичного возбуждения(el, hl))(e)))
Выход: интенсивность: Действительное число в диапазоне [0; +)
Вместе с вычислительными функциями важно специфицировать и функции
проверки вычисляемых значений, если в онтологии действительности присутствуют
соответствующие онтологические соглашения. Модель отображения такая же, как и
для редактора знаний.
Пример специфицированной функции:
Проверить ограничение 8
Вход: элементы пробы, характеристические линии, используемые как одна пара (т.е.
второй элемент пары вычислен как функция характеристические линии элемента от
первого элемента пары)
Описание: Проверить выполнение равенства: (el: элементы пробы) (hl: {(v: характери-
стические линии элемента(el)) интенсивность характеристической линии(el, v) > 0})
площадь пика(el, hl) = интенсивность характеристической линии(el, hl)
Выход: boolean
Описание интерфейсов с пользователем
Для взаимодействия конечного пользователя с системой разрабатывается гра-
фический пользовательский интерфейс, требования к которому включают описание
сценария решения каждой задачи, а для каждого шага сценария – функции ввода данных
и управляющих воздействий пользователя плюс функции отображения результатов.
Функции ввода и проверки данных от пользователя формируются по модели,
аналогичной модели отображения в требования редактора знаний.
Пример:
Ф-Проверить ограничение-на элементы-пробы
Вход: элементы пробы.
Описание: Проверить выполнение элементы пробы
Выход: boolean
Остальные требования формируются с учетом модели задач пользователя. Каж-
дая задача в этой модели разбивается на линейную последовательность шагов1 и воз-
можное множество альтернативных подпоследовательностей, каждый из «последних»
также разбивается на линейную последовательность шагов и возможное множество
альтернативных подпоследовательностей. Шаг здесь – некоторое воздействие пользо-
вателя через пользовательский интерфейс. В этой модели одинаковые шаги могут пов-
торяться в одной или нескольких задачах, они должны иметь одинаковые названия.
1 Другой вариант модели задач пользователя – граф сценария или карта диалога, еще один ва-
риант – блок-схема сценария.
Шалфеева Е.А.
«Искусственный интеллект» 4’2009 480
8Ш
Пример фрагмента модели задачи пользователя (здесь – эксперта):
Вводит некорректные значения свойств новой электронной оболочки и нажи-
мает кнопку «Добавить»
ИЛИ
Вводит корректные значения свойств новой электронной оболочки и нажимает
кнопку «Добавить»
ИЛИ
Выделяет в таблице «Электронные оболочки» какую-то электронную оболочку
и нажимает кнопку «Удалить»
ИЛИ
вводит некорректные новые значения свойств выделенной электронной
оболочки и нажимает кнопку «Изменить» рядом с данной таблицей
ИЛИ
вводит корректные новые значения свойств выделенной электронной
оболочки и нажимает кнопку «Изменить»
ИЛИ
вводит некорректные значения свойств нового энергетического уровня
выделенной электронной оболочки и нажимает кнопку «Добавить»
ИЛИ
вводит корректные значения свойств нового энергетического уровня
выделенной электронной оболочки и нажимает кнопку «Добавить»
ИЛИ
Выделяет в таблице «Электронные оболочки» какую-то электронную обо-
лочку, выделяет в таблице «Энергетические уровни электронной оболоч-
ки» какой-то энергетический уровень
и нажимает кнопку «Удалить».
ИЛИ
вводит некорректные новые значения свойств выделенного энер-
гетического уровня и нажимает кнопку «Изменить» рядом с по-
следней таблицей
ИЛИ
вводит корректные новые значения свойств выделенного энерге-
тического уровня и нажимает кнопку «Изменить»
Каждый шаг этой модели отображается на две функции требований: одна тре-
бует от подсистемы обеспечить пользователю очередное состояние интерфейса, дру-
гая – обработать воздействие пользователя (шаг).
Например, в последовательности шагов есть шаг:
Добавить новое свойство выделенной электронной оболочки
Получим две функции:
1. Выделить выбранную пользователем строку электронной оболочки в таблице
«Электронные оболочки», предоставить поля ввода значений свойств, сделать
доступной кнопку ввода измененных значений.
2. Обработать воздействие пользователя:
2-1) проверить новые значения (в полях ввода) свойств выделенной элект-
ронной оболочки,
2-2) изменить в базе знаний значения свойств выделенной электронной обо-
лочки должны быть на указанные,
2-3) вывести сообщение о недопустимости указанных значений.
Введение и рассмотрение онтологии моделей задач позволит построить модель
отображения фрагментов модели на требования.
Модель связи структурных свойств онтологии со структурой модели...
«Штучний інтелект» 4’2009 481
8Ш
Заключение
Разработка систем, основанных на знаниях, производимая в рамках архитектуры
«редактор знаний – решатель – интерфейс – система объяснения», производится на
основе технологии, в которой уделено много внимания начальным этапам жизненного
цикла, и недостаточно внимания – этапам, традиционным для разработки программного
обеспечения. Однако полнота и однозначность описания требований по-прежнему яв-
ляются «залогом» качества программного обеспечения, в частности СОЗ. Предла-
гаемая методология, позволяющая автоматизировать поддержку создания требований,
добавляет к технологии СОЗ «недостающее звено». В основе этой методологии лежит
модель связи структуры онтологии знаний предметной области и действительности с
требованиями к создаваемым системам, решающим задачи на основе этих знаний.
Литература
1. Гаврилова Т.А. Базы знаний интеллектуальных систем: учебник / Т.А. Гаврилова, В.Ф. Хорошевский. –
СПб.: Изд-во «Питер», 2000. – 382 с.
2. Ontologies for Software Engineering and Software Technology / [Calero C., Ruiz F., Piattini M. (Eds.)]. –
Berlin : Springer-Verlag, 2006. – 339 p.
3. Клещев А.С. Определение структурных свойств онтологий / А.С. Клещев, Е.А. Шалфеева // Изв.
РАН. Теория и системы управления. – 2008. – № 2. – С. 69-78.
4. Клещев А.С. Необогащенные системы логических соотношений / А.С. Клещев, И.Л. Артемьева //
НТИ. Сер. 2. – 2000. – Часть 1. – № 7; Часть 2. – № 8.
О.А. Шалфеєва
Модель зв’язку структурних властивостей онтології зі структурою моделі вимог системи,
що заснована на редагованих знаннях
Пропонується модель зв’язку онтології, що лежить в основі розробки системи, з набором вимог до
неї. Мінімальний набір вимог формується на основі онтології предметної області та з урахуванням
традиційного розподілу функцій між підсистемами такої системи. Модель забезпечує можливість
автоматичного формування таких вимог.
Ye.A. Shalfeyeva
The Model of Linkage between Structural Properties Ontology and Requirements Model Structure
System Based on Knowledge’s Being Edidet
The model of linkage which is at the heart of a system development and system requirements set is offered.
Minimal requirements set is formulated on the basis of domain and and taking into account traditional functions
distributing between subsystems. The model gives an opportunity for automatic requirements formulation.
Статья поступила в редакцию 11.06.2009.
|
| id | nasplib_isofts_kiev_ua-123456789-8161 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1561-5359 |
| language | Russian |
| last_indexed | 2025-12-07T13:25:02Z |
| publishDate | 2009 |
| publisher | Інститут проблем штучного інтелекту МОН України та НАН України |
| record_format | dspace |
| spelling | Шалфеева, Е.А. 2010-05-14T07:56:17Z 2010-05-14T07:56:17Z 2009 Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях / Е.А. Шалфеева // Штучний інтелект. — 2009. — № 4. — С. 472-481. — Бібліогр.: 4 назв. — рос. 1561-5359 https://nasplib.isofts.kiev.ua/handle/123456789/8161 004.8 Предлагается модель связи онтологии, лежащей в основе разработки системы, с набором требований к ней. Минимальный набор требований формируется на основе онтологии предметной области и с учетом традиционного распределения функций между подсистемами такой системы. Модель обеспечивает возможность автоматического формирования таких требований. Пропонується модель зв’язку онтології, що лежить в основі розробки системи, з набором вимог до неї. Мінімальний набір вимог формується на основі онтології предметної області та з урахуванням традиційного розподілу функцій між підсистемами такої системи. Модель забезпечує можливість автоматичного формування таких вимог. The model of linkage which is at the heart of a system development and system requirements set is offered. Minimal requirements set is formulated on the basis of domain and and taking into account traditional functions distributing between subsystems. The model gives an opportunity for automatic requirements formulation. Работа выполнена при финансовой поддержке ДВО РАН, проект «Обеспечение качества интеллектуального программного обеспечения в процессе его проектирования на основе онтологий». ru Інститут проблем штучного інтелекту МОН України та НАН України Прикладные интеллектуальные системы Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях Модель зв’язку структурних властивостей онтології зі структурою моделі вимог системи, що заснована на редагованих знаннях The Model of Linkage between Structural Properties Ontology and Requirements Model Structure System Based on Knowledge’s Being Edidet Article published earlier |
| spellingShingle | Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях Шалфеева, Е.А. Прикладные интеллектуальные системы |
| title | Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях |
| title_alt | Модель зв’язку структурних властивостей онтології зі структурою моделі вимог системи, що заснована на редагованих знаннях The Model of Linkage between Structural Properties Ontology and Requirements Model Structure System Based on Knowledge’s Being Edidet |
| title_full | Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях |
| title_fullStr | Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях |
| title_full_unstemmed | Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях |
| title_short | Модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях |
| title_sort | модель связи структурных свойств онтологии со структурой модели требований системы, основанной на редактируемых знаниях |
| topic | Прикладные интеллектуальные системы |
| topic_facet | Прикладные интеллектуальные системы |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/8161 |
| work_keys_str_mv | AT šalfeevaea modelʹsvâzistrukturnyhsvoistvontologiisostrukturoimodelitrebovaniisistemyosnovannoinaredaktiruemyhznaniâh AT šalfeevaea modelʹzvâzkustrukturnihvlastivosteiontologíízístrukturoûmodelívimogsistemiŝozasnovananaredagovanihznannâh AT šalfeevaea themodeloflinkagebetweenstructuralpropertiesontologyandrequirementsmodelstructuresystembasedonknowledgesbeingedidet |