11.3. Эволюция

11.3. Эволюция

Интеграция

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

Интеграция объектов верхнего уровня. На рис. 11-7 показана диаграмма объектов нашей системы на самом верхнем уровне, которая полностью соответствует структуре информационной доски, приведенной на рис. 11-1. Физическое содержание объектов доски в коллекции theBlackboard и источников знаний в коллекции theKnowledgeSources показано в соответствии с описанием вложенности классов.

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

Рис. 11-7. Диаграмма объектов криптоанализа.

Для этого класса следует определить две основные операции:

reset - Перезапустить информационную доску.

decipher - Начать дешифровку криптограммы.

Конструктор этого класса должен создать зависимости между доской и источниками знаний, а также между источниками знаний и контроллером. Метод reset предельно прост: его цель состоит в том, чтобы вернуть эти связи и объекты в начальное состояние.

Метод decipher принимает строку - криптограмму. Теперь функции высокого уровня нашего приложения становятся предельно простыми, как это обычно и происходит в объектно-ориентированных системах:

char* solveProblem(char* ciphertext) {

Cryptographer theCryptographer; return theCryptographer.decipher(ciphertext);

}

Метод decipher оказывается несколько сложнее. В первую очередь с помощью операции assertProblem задание помещается на доску. После этого активизируются источники знаний. И, наконец, начинается циклический процесс обращения источников знаний к контроллеру с новыми и новыми предположениями и утверждениями до тех пор, пока не будет найдено решение задачи либо процесс не зайдет в тупик. Для иллюстрации можно воспользоваться диаграммами взаимодействия или диаграммами объектов, но код на C++ выглядит тоже не слишком сложно:

theBlackboard.assertProblem(); theKnowledgeSources.reset(); while (!theController.isSolved || !theController.unableToProceed())

theController.processNextHint();

if (theBlackboard.isSolved())

return theBlackboard.retrieveSolution();

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

Посмотрим на две операции, определенные в классе decipher, а именно assertProblem и retrieveSolution. Первая из них интересна тем, что создает структуру доски. Опишем наш алгоритм следующим образом:

убрать из строки все начальные и концевые пробелы if получилась пустая строка return создать объект-предложение занести предложение на доску создать объект-слово (самое крайнее слева) занести слово на доску добавить слово к предложению for каждый символ строки слева направо

if символ есть пробел

сделать текущее слово предыдущим создать объект-слово занести слово на доску добавить слово к предложению

else

создать объект "буква шифра" занести букву на доску добавить букву к слову

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

Операция retrieveSolution очень проста: она возвращает строку, записанную в данный момент на доске. Вызывая эту операцию до того как функция isSolved вернула значение True, можно получать частичные решения.

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

На рис. 11-8 показан сценарий выдвижения предположений. Источник знаний сообщает об имеющихся предположениях информационной доске, которая применяет их к алфавиту и оповещает остальные источники.

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

Рис. 11-8. Выдвижение предположений.

Можно действовать тоньше. Пусть мы предположили, что однобуквенное слово соответствует I (нужна гласная). Далее, сделано предположение, что некоторое двухбуквенное сочетание - это NN (нужны согласные). Если первое предположение окажется ошибочным, то второе вполне может быть сохранено. При таком подходе класс Assumption нужно дополнить еще одним методом, регистрирующим связь предположений между собой (взаимозависимость). Реализацию этого поведения можно отложить на более поздний срок, поскольку оно мало влияет на архитектуру.

Добавление источников знаний

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

Убедившись в правильной работе механизма вывода, можно последовательно вводить в систему источники знаний. Целесообразность именно такого процесса объясняется двумя причинами:

• Трудно заранее выяснить, какие правила существенны для каждого из источников знаний, не испытав систему на конкретной задаче.

• Отладка базы знаний существенно упрощается при последовательном добавлении правил.

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

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

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Эволюция My Yahoo!

Из книги Бизнес путь: Yahoo! Секреты самой популярной в мире интернет-компании автора Вламис Энтони


17.1. Эволюция С

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

17.1. Эволюция С Главным фактом практики Unix-программирования всегда была стабильность языка С и небольшого количества служебных интерфейсов, которые всегда ему сопутствовали (особенно стандартная 1/О-библиотека и подобные ей). Тот факт, что i язык, созданный в 1973 году, в


Эволюция PowerPC

Из книги Основы AS/400 автора Солтис Фрэнк

Эволюция PowerPC Концепция RISC была разработана Джоном Коком (John Cocke) из IBM Research. Кок установил, что прогресс в области компиляторов достиг той точки, когда можно упростить набор команд процессора, и возложить на компилятор значительную часть работы, ранее выполнявшейся


8.3. Эволюция

Из книги Объектно-ориентированный анализ и проектирование с примерами приложений на С++ автора Буч Гради

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


9.3. Эволюция

Из книги Фреймы для представления знаний автора Мински Марвин

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


11.3. Эволюция

Из книги Феномен науки. Кибернетический подход к эволюции автора Турчин Валентин Фёдорович

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


12.3. Эволюция

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

12.3. Эволюция Модульная архитектура Мы уже говорили о том, что модульность для больших систем необходима, но не достаточна; для задач такого масштаба, как система управления движением, нужно сосредоточиться на декомпозиции по подсистемам. На ранних стадиях эволюции мы


5.4. Эволюция

Из книги Основы объектно-ориентированного программирования автора Мейер Бертран

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


14.12. Этика и эволюция

Из книги TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) автора Фейт Сидни М


17.1. Эволюция С

Из книги Защита от хакеров корпоративных сетей автора Автор неизвестен

17.1. Эволюция С Главным фактом практики Unix-программирования всегда была стабильность языка С и небольшого количества служебных интерфейсов, которые всегда ему сопутствовали (особенно стандартная I/O-библиотека и подобные ей). Тот факт, что язык, созданный в 1973 году, в


Функции и эволюция

Из книги Как накормить слона, или первые шаги к самоорганизации с Evernote автора Султанов Гани

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


Эволюция Windows

Из книги автора

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


11.6 Эволюция BOOTP

Из книги автора

11.6 Эволюция BOOTP Протокол BOOTP обеспечивает в работе достаточную гибкость:? Перед запуском клиент может не иметь никакой информации или быть частично сконфигурированным.? Клиент может получить информацию на сервере загрузки или выбрать для этого специально указанный


Эволюция доверия

Из книги автора

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


ГЛАВА 6: ЭВОЛЮЦИЯ

Из книги автора

ГЛАВА 6: ЭВОЛЮЦИЯ Вы накормили и приручили слона. Но со временем он будет расти и развиваться, станет умнее.Ваша система должна меняться, потому что будет меняться ваша жизнь, её ценности и способы реализации ваших целей. Через год вы, может быть, плюнете на GTD и пошлёте