Оглавление

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

2. Предметная область (ПО) и проблемная среда. Особенности задач, решаемых в классе СОЗ. Анализ и синтез в проектировании программных систем: от CASE-технологий к технологиям концептуального моделирования (КМ). 8

3. Универсум Эрбрана. Модели «миров». 8

4. Проблема представления знаний. Методы и языки представления знаний. Языки структурной и логической спецификации понятий. Модальные описания. Примеры. 12

5. Концептуализация. Принципы «непроцедурного» программирования ПО. Декларативная и процедурная компоненты представляемых знаний. Семейство концептуальных объектно-ориентированных языков представления знаний (КООЯ). 12

Методология объектно-ориентированного анализа и проектирования 13

6. Концептуальное моделирование – современная информационная технология искусственного интеллекта. Структурное описание предметной области. Примеры. 16

7. Подъязык диаграмм потоков объектов – графическое представление. 16

8. Формальная модель понятия. Точки соотнесения. Полный экстенсионал понятия. 16

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

10. Агрегация, таксономия, итерация в представлении знаний эксперта. Примеры в синтаксисе КООЯ. 16

11. Инкапсуляция и наследование в описании ПО. 16

12. Отношение иерархии при описании сложной ПО. 16

13. Общее описание и синтаксис КООЯ. 16

14. Семантика КООЯ, основанная на формальной модели понятия. 17

15. Описание типов. Примитивные типы и конструкторы типов. 18

16. Имена понятий. Суррогаты – встроенные системные идентификаторы. 18

17. Концептуальные схемы и базы данных при построении концептуальной модели (КМ) ПО: КМ = КС UБД. 18

18. Значения и типы значений (Boolean, Num, Real, Char). Стандартные конструкторы сложных типов значений. Помеченные кортежи: [А:]. Имя и атрибуты формального понятия. Встроенные (системные) атрибуты. Примеры и контрпримеры понятия. 20

19. Описание типов. Синтаксис ТЗ-спецификаций. 20

20. Примитивные типы значений и операции над множествами типов. 20

Примеры примитивных типов в различных языках 20

21. Конструктор декартова произведения “n” типов. Пример спецификации. Селекторы как функции. Селекторы как виртуальные атрибуты. 21

22. Спецификация рекурсивных типов данных: пример «Бинарное дерево». 22

23. Задание функций на типах данных («союз», «соединение списков», «сортировка» и т.д.). Примеры. 22

24. Логические и модальные утверждения. Пример «Механообработка деталей». 24

25. База знаний (БЗ) СОЗ. Машина вывода. Прямая и обратная цепочки рассуждений (понятие, примеры). 25

26. Многосортное исчисление предметов как язык представления знаний. 27

27. Альтернативные методы представления знаний: фреймы, семантические сети, продукционные модели. 37

Структура фрейма 37

Графическое представление 39

Математическая запись 39

Семантические отношения 39

Модификации продукционной модели 39

28. Основные задачи разработки СОЗ. 40

29. Основы референциальной теории Фреге. 41

30. Отношение кореференции, семантика имён. 42

31. Элементы бинарных моделей данных и знаний. Примеры. 43

32. Темпоральные описания. Интервальная логика событий (Дж. Аллена). 43

33. Базы знаний и логическое следование. Запросы к БД с неполной информацией. 46

Отличие от баз данных 47

34. RDF-описание для SemanticWeb. 48

35. Онтологии и их представлениекак формальная спецификация концептуализации. 49

36. Агенты для представления знаний. 51

TODO LIST

2.Предметная область (ПО) и проблемная среда. Особенности задач, решаемых в классе СОЗ. Анализ и синтез в проектировании программных систем: от CASE-технологий к технологиям концептуального моделирования (КМ).

3.Универсум Эрбрана. Модели «миров».

4.Проблема представления знаний. Методы и языки представления знаний. Языки структурной и логической спецификации понятий. Модальные описания. Примеры.

6.Концептуальное моделирование – современная информационная технология искусственного интеллекта. Структурное описание предметной области. Примеры.

7.Подъязык диаграмм потоков объектов – графическое представление.

8.Формальная модель понятия. Точки соотнесения. Полный экстенсионал понятия.

Х  Х_о – информация,  - мнение эксперта

Пусть любое формальное описание множества понятий опред. бинарн. отнош., которое определяется на декартовом произведении inst  UxU, оно соответствует имени понятия тогда и только тогда, когда е – имя понятия с именем c е inst c – где е - сущность, с – концепт. е  Е  U, inst  - точка соотнесения. ~ - бинарное отношение, кореферентное отношение ~ SUxU : x ~ y имена x и y соответствуют одному и тому же объекту модели предметной области.

тут еще какое-то ололо

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

10.Агрегация, таксономия, итерация в представлении знаний эксперта. Примеры в синтаксисе КООЯ.

11.Инкапсуляция и наследование в описании ПО.

12.Отношение иерархии при описании сложной ПО.

15. Описание типов. Примитивные типы и конструкторы типов.

16.Имена понятий. Суррогаты – встроенные системные идентификаторы.

При описании предметной области, обычо вырабатывается система понятий, связи внутренние и внешние.

Понятие  абстракция объекта

Объект  класс

Целью использования формальной модели является концептуальная модель.

КМ = КС  БД

Каждое имя КМ имеет внешнюю интерпретацию как объект, расшифровывается как сущность, явление или событие.

Этот объект называется референтом или денотатом или десигнатом имени ”a”, которое будет принадлежать к этой концптуальной модели, и обозначается ref(a).

Собственные имена понятий

с большой буквы без пробелов

Суррогаты

особые имена, которые обычно обозначают номера #1, #2,... – системные встроенные имена для описания отдельных объектов и объектов-образцов. Ими оперируют те, кто специфицируют предметную область – автор концептуальной модели.

Имена отдельных объектов и отдельных констант (логических констант, не суррогатов)

их определяют разработчики модели. это так же, как собственные имена понятий, либо строки символов без пробелов.

Концептуальный язык расширяет возможности исчисления предикатов.

Известно, что успех в ршении задач существенно зависит от языка, в котором эта задача представлена.

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

Синтаксис и семантика языка

Алфавит:

1. Логические символы (¬, Ʌ, V, →, ↔)

2. Для любого, существует

3. =, ͼ

4. Имена сортов (имена классов)

5. Имена констант, предикатов, функций

6. (индивидуальные) переменные

7. «(», «) », «. », «, », …

8. Специальные знаки, символы

Все зависит от выбора формальной системы.

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

Сорт  Понятие  Объект  Класс

Объекты и классы – с большой буквы Остальные имена и переменные – только малыми буквами, возможно с индексами.

a: B₁ x B₂ x … x B_j x … x B_n  C(1)

где B_j, C – имена понятий (сортов) а – имя из списка спец. символов в алфавите из (д) или (е) (1) – указатель сортности для имени а

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

Среди всех сортов выделим множество Т – множество истинностных значений.

Т = {0; 1} – ложь/истина

В любом представлении верно Т.

Опрделение

Имя а из (д) – списка символов (алфавита) называют именем предиката в сигнатуре , если в  входит указатель типа (1), у которого С – правая часть есть Т. В дальнейшем для краткости указатель (1) при условии С=Е можно записать как а  B₁ x B₂ x … x B_j x … x B_n – функция, определенная на прямом произведении B₁ x B₂ x … x B_j x … x B_n а (b₁,b₂,…b_n) – определяется через значение b_n где b_i  B_i на множестве тех b_n, где значение истинно: а (b₁,b₂,…b_n) = 1

Определение

Имя а называется именем логической функции (в сигнатуре ), если в  входит указатель вида (1), у которого С  Т при условии что n  0

Определение

Имя а из (д) называется именем константы в сигнатуре , если в  входит указатель вида (1), у которого С  Т при условии что n = 0 – нульместный предикат. Т.е. константа является нульместным символом сигнатуры, а указатель переписан как а:  C(1) (читаем как “истина, что С”) либо а  С

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

18.Значения и типы значений (Boolean, Num, Real, Char). Стандартные конструкторы сложных типов значений. Помеченные кортежи: [А:]. Имя и атрибуты формального понятия. Встроенные (системные) атрибуты. Примеры и контрпримеры понятия.

Вопросы к экзамену («Представление знаний в ИС», Тюхов Б.П.)

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

Системы поддержки принятия решений (английский эквивалент —

DSS: Decision Support System) — это компьютерные системы, предна-

значенные для усовершенствования процесса управления предприя-

тием или иным сложным объектом.

Архитектура OLAP-системы определяется типом хранилища дан-

ных, на котором она основывается. Различают три вида информаци-

онных хранилищ.

1. Виртуальное (логическое) хранилище. В его основе лежит ре-

позитарий метаданных, которые описывают источники данных

(БД, внешние файлы и т.д.), SQL-запросы, процедуры обработ-

ки и представления информации. Доступ к ним обеспечивает

программное обеспечение промежуточного слоя (middleware).

Избыточность данных минимальная, пользователь-аналитик ра-

ботает фактически с «живыми» данными OLTP-систем, что

сопровождается снижением их производительности и реальной

угрозой нарушения их работоспособности.

2. Централизованное хранилище. Это самый распространенный

способ организации OLTP-систем. В качестве СУБД обычно

используются либо профессиональные реляционные, либо мно-

гомерные СУБД, специально приспособленные для построения

OLTP-систем. Наполнение централизованного хранилища про-

изводится из баз данных транзакционных систем и внешних ис-

точников путем обработки (компиляции) первичных, «сырых»,

детальных данных.

3. Распределенное информационное хранилище. Такая форма

свойственна крупным организациям с большим числом

удаленных филиалов, являющихся автономными центрами

принятия решений. В этом случае для каждого управленче-

ского уровня открывается свой фрагмент информационного

хранилища, называемый информационной витриной (datamart)

и реализуемый в виде отдельной локальной базы данных, куда

копируется из центрального хранилища только та информация,

которая необходима для данного подразделения.

Системы обнаружения знаний в базах данных (KDD). Системы обнаружения

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

образов или классов, которые можно интерпретировать как полезные

и интересные знания. У таких систем также много общего со статисти-

кой, со специальным исследовательским анализом данных. Системы

KDD всегда располагают встроенными конкретными статистически-

ми процедурами для моделирования данных и подавления шума в

данных. Две главные цели DataMining можно сформулировать как про-

гноз (предсказание) и получение описаний классов объектов.

2. Предметная область (ПО) и проблемная среда. Особенности задач, решаемых в классе СОЗ. Анализ и синтез в проектировании программных систем: от CASE-технологий к технологиям концептуального моделирования (КМ).

3. Универсум Эрбрана. Модели «миров».

Про модель миров хз что имел ввиду автор вопросника

4. Проблема представления знаний. Методы и языки представления знаний. Языки структурной и логической спецификации понятий. Модальные описания. Примеры.

5. Концептуализация. Принципы «непроцедурного» программирования ПО. Декларативная и процедурная компоненты представляемых знаний. Семейство концептуальных объектно-ориентированных языков представления знаний (КООЯ).

Из лекции (дополните у кого есть больше)

{

БМДЗ – бинарная модель представления данных и знаний

Язык Concept

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

...

Язык -> 1. Концептуальный уровень программирования (в понятиях экспертизы предметно области )

2. Объектно- ориентированый – предполагает эффективный вывод

КООЯ – это либо conceptлибо БМДЗ

Модели	КООЯ
1. Логическая	ССП
2. Фреймовая	ЯЛСП (язык логических специальных понятий)
3.Продукционная	ЯФЗ (язык функциональных зависимостей)
4.Семантические сети	ЯЯУ (язык ядерных условий ; “если” антицендентный условий)
	2.3 ЯОУ (язык неполных условий и ограничений)
	2.4 ЯПУ (язык полных условий)
	ЯКСП (язык концептуальных сетей Петри)
	ЯТЗ (язык темпоральных зависимостей, логика Алена(!), описание временных интервалов)
	ДЛ
	ЯВУ(язык вероятностных условий)
	ЯНЗ(язык нечетких зависимостей)
	?
	?
	?(ЯНПП)?
	OWL (для описания ...) + RDFSchema + XML (для программирования в интернете (ололо))

}

Возможно он имел ввиду вот это

Методология объектно-ориентированного анализа и проектирования

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

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

Для выделения или идентификации компонентов предметной области было предложено несколько способов и правил. Сам этот процесс получил название концептуализации предметной области. При этом под компонентой понимают некоторую абстрактную единицу, которая обладает функциональностью, т. е. может выполнять определенные действия, связанные с решением поставленных задач. На предварительном этапе концептуализации рекомендуется использовать так называемые CRC-карточки (Component, Responsibility, Collaborator– компонента, обязанность, сотрудники) [1]. Для каждой выделенной компоненты предметной области разрабатывается собственная CRC-карточка (рис. 1.6).

Рис. 1.6. Общий вид CRC-карточки для описания компонентов предметной области

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

Разделение процесса разработки сложных программных приложений на отдельные этапы способствовало становлению концепции жизненного цикла программы. Под жизненным циклом (ЖЦ) программы понимают совокупность взаимосвязанных и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее использования. Стандарт ISO/IEC 12207, хотя и описывает общую структуру ЖЦ программы, не конкретизирует детали выполнения тех или иных этапов. Согласно принятым взглядам ЖЦ программы состоит из следующих этапов:

• Анализа предметной области и формулировки требований к программе

• Проектирования структуры программы

• Реализации программы в кодах (собственно программирования)

• Внедрения программы

• Сопровождения программы

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

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

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

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

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

Примечание 8

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (ComputerAidedSoftwareEngineering, CASE). Появление первых CASE-средств было встречено с определенной настороженностью. Со временем появились как восторженные Отзывы об их применении, так и критические оценки их возможностей. Причин для столь противоречивых мнений было несколько. Первая из них заключается в том, что ранние CASE-средства были простой надстройкой над некоторой системой управления базами данных (СУБД). Хотя визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, она не решает проблем разработки приложений других типов.

Вторая причина имеет более сложную природу, поскольку связана с графической нотацией, реализованной в том или ином CASE-средстве. Если языки программирования имеют строгий синтаксис, то попытки предложить подходящий синтаксис для визуального представления концептуальных схем БД были восприняты далеко неоднозначно. Появилось несколько подходов, которые более подробно будут рассмотрены в главе 2. На этом фоне появление унифицированного языка моделирования (UnifiedModelingLanguage, UML), который ориентирован на решение задач первых двух этапов ЖЦ программ, было воспринято с большим оптимизмом всем сообществом корпоративных программистов.

Примечание 9

Последнее, на что следует обратить внимание, это осознание необходимости построения предварительной модели программной системы, которую, согласно современным концепциям ООАП, следует считать результатом первых этапов ЖЦ программы. Поскольку язык UML даже в своем названии имеет отношение к моделированию, следует дополнительно остановиться на целом ряде достаточно важных вопросов. Таким образом, мы переходим к теме, которая традиционно не рассматривается в изданиях по ООАП, но имеющая самое прямое отношение к процессу построения моделей и, собственно, моделированию. Речь идет о методологии системного анализа и системного моделирования.

http://lib.rus.ec/b/69851/read

6. Концептуальное моделирование – современная информационная технология искусственного интеллекта. Структурное описание предметной области. Примеры.

http://www.pvv.org/~bct/sprithesis/iathesis.html - копцептуальное Моделирование в агентном подходе, хз копировать сюда или нет

7. Подъязык диаграмм потоков объектов – графическое представление.

8. Формальная модель понятия. Точки соотнесения. Полный экстенсионал понятия.

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

10. Агрегация, таксономия, итерация в представлении знаний эксперта. Примеры в синтаксисе КООЯ.

11. Инкапсуляция и наследование в описании ПО.

12. Отношение иерархии при описании сложной ПО.

13. Общее описание и синтаксис КООЯ.

На кафедре МОСОИиУ разработан концептуальный объектно - ориентированный язык «Концепт», объединяющий семейство формализмов - языков представления данных и знаний о предметной области в различных формах.

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

Воспроизводимый инструментарием адекватный описаниям Эксперта пользовательский интерфейс предоставляет Пользователю возможность получать консультацию в формах:

• графической аналитической информации;

• полнотескстовой справочной информации;

• экспертной информации, рекомендации Эксперта, полученной на основе анализа конкретной ситуации.

КООЯ (технология программирования):

1. «структурная спецификация понятий» (ССП)

2. «язык логической спецификации понятий» (ЯЛСП)

1. Язык функциональных зависимостей

2. Язык ядерных условий

3. Язык ограничений и условий (неполных)

4. Язык полных условий

3. «язык параллельных описаний» или язык концептуальных сетей Петри

Сети Петри — математический аппарат для моделирования динамических дискретных систем. Впервые описаны Карлом Петри в 1962 году.

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

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

4. «язык темпоральных зависимостей» (пример: Логика Альвина)

5. «язык динамической логики»

6. «язык вероятностных условий»

7. «язык нечетких зависимостей»

 В нечеткой логике нечеткие правила играют центральную роль в языке нечетких зависимостей и команд (Fuzzy Dependency and Command Language, FDCL). С неформальной точки зрения, это как раз тот язык, который используется в большинстве приложений нечеткой логики.

….

n) «языки современного программирования для интерпретаторов» ( OWL (для описания структурного онтологического плана), OWL будет работать с RDF.Shema, XML)