2. База знаний как элемент экспертной системы. Необходимые условия представления знаний. (эс)
База знаний содержит факты и правила. Факты – это фразы без условий, они содержат утверждения, которые всегда абсолютно верны. Правила содержат утверждения, истинность которых зависит от некоторых условий, образующих тело правила.
Факты содержат краткосрочную информацию в том смысле, что они могут меняться, например, в ходе время консультации.
Правила представляют собой долговременную информацию о том, как порождать новые факты или гипотезы из того, что сейчас известно.
Чем такой подход отличается от обычной методики использования БД?
Основное различие состоит в том, что БЗ обладает большими «творческими» возможностями.
Факты в БД обычно пассивны: они там либо там есть, либо их нет.
БЗ, с другой стороны, активно пытается пополнить недостающую информацию.
Необходимые условия представления знаний
Одной из основных проблем, характерных для СОЗ, является проблема представления знаний. Это объясняется тем, что форма представления знаний оказывает существенное влияние на характеристики и свойства системы.
Представление знаний изображено на рис. 2.2.
Для возможности оперирования знаниями из реального мира с помощью ПК, необходимо осуществить их моделирование (по аналогии с построением концептуальных и логических моделей БД). При этом необходимо отличать знания, предназначенные для обработки компьютером от знаний, используемых человеком.
При проектировании модели представления знаний следует учитывать такие факторы, как: однородность представления и простота понимания.
Однородность представления приводит к упрощению механизма управления логическим выводом и управлением знаниями.
Простота понимания предполагает доступность понимания представления знаний и экспертам, и пользователем системы. В противном случае затрудняется приобретение знаний и их оценка.
Однако выполнить эти требования в равной степени, как для простых, так и сложных задач довольно трудно. В настоящее время для представления знаний используют следующие виды моделей: модель на базе логики; продукционная модель; модель семантической сети; модель, основанная на использовании фреймов и др.
Иллюстрацией логической модели является приведенный выше пример.
Основная идея логического подхода состоит в том, чтобы рассматривать всю систему знаний необходимую для решения прикладных задач, как совокупность фактов (утверждений).
Факты представляются как формулы в некоторой логике (первого или высшего порядка, многозначной, нечеткой или др.) Система знаний отображается совокупностью таких формул и, представленная в ЭВМ, она образует БЗ.
Формулы неделимы и при модификации БЗ могут лишь добавляться или удаляться.
Логические методы обеспечивают развитый аппарат вывода новых фактов из тех, которые явно представлены в БЗ.
Основным примитивом манипуляции знаниями является операция вывода.
3. Модели жизненного цикла ис. Стадии моделей жц. Основные модели. Модель проектирования msf. (пис)
Модели жизненного цикла ПО
Модель ЖЦ ПО – структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. В рамках модели ЖЦ выделяют совокупности упорядоченных во времени, взаимосвязанных и объединенных в стадии работ.
Стадия – часть процесса создания ПО, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО, программных компонентов, документации). Стадии создания ПО выделяются по соображениям рационального планирования и организации работ, заканчивающихся заданными результатами.
В состав жизненного цикла ПО обычно включаются следующие стадии:
Стадия формирования требований к ПО. Данная стадия включает следующие этапы: 1)Планирование работ; 2)Проведение обследования деятельности автоматизируемого объекта (организации); 3)Построение моделей деятельности организации. Обычно формируются 2 модели: модели «AS-IS» («как есть»); модели «ТО-ВЕ» («как должно быть»).
Каждая из моделей включает в себя полную функциональную и информационную модель деятельности организации, а также, в случае необходимости, модель, описывающую динамику поведения организации. Прорабатывается процесс перехода от модели «AS-IS» к модели «ТО-ВЕ».
Стадия проектирования (разработка системного проекта). На этом этапе определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели «ТО-ВЕ».
Стадия разработки технического проекта. На основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальную проработку компонентов до требуемого уровня.
Стадия тестирования и все последующие стадии включают соответствующие процессы из ЖЦ.
Основные модели ЖЦ ПО:
Каскадная модель
Каскадная модель подразумевает ступенчатое выполнение стадий ЖЦ, следующая стадия наступает после полного завершения предыдущей стадии рис. 3.
Данная модель очевидна, последовательность этапов логична. Модель позволяет планировать объем работ при наличии данных о выполненных стадиях аналогичной системы.
Данный подход позволяет детально прорабатывать элементы системы при проектировании сложной вычислительной системы. Однако он не обеспечивает возможность доработки системы за счет возврата к предшествующему этапу, что характерно при разработке сложных систем с большим количеством задач. Поэтому при разработке многих систем нарушаются плановые сроки выполнения отдельных этапов, неверно планируются требуемые финансовые ресурсы. При использовании данного подхода срок выполнения работ системы значителен, при этом требования, предъявляемые к системе, могут изменяться.
Для преодоления перечисленных проблем была разработана спиральная модель.
Спиральная модель
Прикладное ПО создается не сразу, а по частям с использованием метода прототипирования. Создание прототипов осуществляется в несколько итераций, или витков спирали рис. 4.
Прототип – действующий программный компонент или набор, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО.
При использовании данного подхода возможно не только наращивание прототипов, но и изменение прототипов нижнего уровня.
Главное требование – преемственность прототипов, т.е. прототипы более высокого уровня должны наследовать основные функциональные и интерфейсные характеристики. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта.
Рис. 3. Каскадная схема разработки ПО
Рис. 4. Спиральная модель ЖЦ ПО
При разработке прототипа каждого уровня выполняются однотипные группы действий.
Основная проблема спирального цикла – определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков
Модель ЖЦ ИС. Модель MSF.
Принципы разработки приложений MSF — это набор моделей, принципов и методов, которые помогают организации более эффективно создавать и использовать ИТ для решения проблем бизнеса. Обеспечивая ощутимый прогресс и четкое руководство, MSF позволяет сделать приложение гибким и способным реагировать на изменяющиеся потребности организации.
Ядро этой системы составляют шесть основных моделей: 1) модель производственной архитектуры;2) модель проектной группы; 3)модель приложения. 4)модель процесса разработки ПО; 5)модель управления рисками; 6)модель процесса проектирования.
Модель производственной архитектуры
Эта модель предлагает набор принципов, обеспечивающих быстрое создание производственной архитектуры посредством выпуска версий. При этом информационные технологии приводятся в соответствие с требованиями бизнеса с четырех точек зрения: бизнеса, приложения, информации и технологии. Использование этой модели позволяет сократить затраты времени на разработку производственной архитектуры.
Модель проектной группы
Эта модель относится к группе, работающей над проектом: описывает роли, обязанности каждого участника, распределение ответственности и порядок работы. Гибкость позволяет привести модель в соответствие с характером проекта, размером группы и квалификацией участников. Использование этой модели и ее основных принципов помогает сформировать неравнодушную, энергичную и эффективную команду.
Модель процесса разработки ПО
Эта модель описывает организационную структуру процесса разработки и руководство им в течение всего времени выполнения проекта. Отличительные особенности модели — поэтапность, итеративность и гибкость. Она описывает фазы, этапы, виды деятельности и результаты процесса разработки приложения и их связь с моделью проектной группы MSF. Использование этой модели обеспечивает контроль за ходом разработки проекта, минимизацию рисков, повышение качества и сокращение сроков выполнения проекта.
Модель управления рисками
Эта модель предлагает организованный путь активного управления рисками проекта. Она описывает порядок и условия реализации упреждающих решений и мер для постоянного выявления потенциальных проблем, позволяет обнаружить наиболее существенные риски и реализовать стратегии их устранения. Использование этой модели и ее основных принципов помогает команде сосредоточиться на наиболее важных моментах, принимать верные решения и лучше подготовиться к тому времени, когда будущее откроет свои тайны.
Модель процесса проектирования
Эта модель описывает трехфазный, ориентированный на конечного пользователя, непрерывный процесс разработки, характеризующийся параллельными итерационным выполнением проекта и таким образом способствующий его эффективности и гибкости. Три фазы разработки — концептуальное, логическое и физическое проектирование — реализуют точку зрения на проект трех аудиторий: конечных пользователей, проектной группы и разработчиков, Продвижение от концептуального проекта к физическому превращает набор сценариев использования в совокупность компонентов и сервисов, образующих приложение, реализующее требования заказчика и пользователей. Таким образом, приложение разрабатывается не ради демонстрации технологических возможностей, а для решения насущных проблем бизнеса и пользователей.
Модель приложения
Эта модель реализует логичный, трехуровневый, ориентированный на сервисы метод проектирования и разработки программного обеспечения. Применение пользовательских сервисов, бизнес-сервисов и сервисов данных позволяет реализовать параллельную разработку, обеспечивает оптимальное использование технологии, облегчает эксплуатацию и сопровождение и обеспечивает максимальную гибкость развертывания, поскольку сервисы, составляющие приложение, могут располагаться и на единственном персональном компьютере, и на различных серверах и клиентах, установленных в разных странах.
Билет №28