Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 86
Текст из файла (страница 86)
При анализе источников знанийможет выявиться, что одни правила бесполезны, другие слишкомспециализированы или излишне обобщены, а некоторых явно недостает.После анализа правила источника могут модифицироваться. Иногда требуетсясоздание нового источника знаний.В процессе реализации источников знании могут выявиться общие длянескольких источников правила и/или поведение. Например, источник знанийо структуре слов и источник знаний о структуре предложений могут иметь всвоем составе общие правила относительно возможного порядка следованиянекоторых языковых структур. В обоих случаях суть правила одна и та же,поэтому целесообразно ввести новый класс-примесьStructureKnowledgeSource, отражающий знания о структуре, в который ипомещается это общее поведение.Такое изменение структуры классов подчеркивает тот факт.
чтопроцесс обработки правил определяется не только источниками знаний, но ихарактером объектов доски. Например, один из источников знаний можетреализовывать прямую последовательность рассуждений в отношении однихобъектов и обратную последовательность - в отношении других. Кроме того,различные источники знаний могут по-разному оперировать с одним и тем жеобъектом.11.4. СопровождениеРасширение функциональных возможностейВ этом разделе мы попытаемся улучшить возможности проектируемойсистемы и оценить ее гибкость.В интеллектуальных системах очень важно наряду с решением задачиполучить информацию о самом процессе поиска решения.
Для этого нужнопридать системе способность самоанализа: регистрировать ход активизацииисточников знаний, причины и характер выдвигаемых предположений и т. д.,чтобы иметь возможность запросить у системы, по какой причине сделаноконкретное предположение и к каким результатам оно приводит.Для реализации такого свойства необходимо сделать две вещи. Вопервых, нужно ввести механизм трассировки действий контроллера иисточников знаний, а во-вторых - модифицировать некоторые методы, чтобыони записывали соответствующую информацию. Идея состоит том, чтодействия источников знаний и контроллера регистрируются в некоторомобщем центральном хранилище.Посмотрим, какие классы нам понадобятся.
Прежде всего, введемкласс Action, регистрирующий действия источников знаний и контроллера:class Action ( public:Action(KnowledgeSource* who, BlackboardObject* what,char* why);Action<Controller* who, KnowledgeSource* what, char*why);};Экземпляр данного класса создается, например, при активизацииконтроллером какого-либо источника знаний.
При этом в аргумент who (кто)заносится указатель на контроллер, в аргумент what (что) - активныйисточник знаний, а в аргумент why (почему) - какое-либо пояснение(например, приоритет предположения).Первая часть нашего нового механизма создана, вторая тоже не оченьсложна. Посмотрим, где в нашей системе происходят основные события. Мыувидим, что основными являются следующие пять операций:•методы, которые выдвигают предположения;•методы, которые откатывают предположения;•методы, которые активизируют источники знаний;•методы, которые выполняют правила;•методы, которые регистрируют высказывания от источников знаний.Все эти события сконцентрированы в двух местах: в конечномавтомате контроллера и в механизме выдвижения предположений.
Нам непридется существенно изменять архитектуру системы, чтобы учестьуказанные выше требования.Для полноты нам остается только создать объект, отвечающий навопросы пользователя системы: кто? что? когда? почему?. Спроектироватьтакой объект несложно, поскольку вся нужная для его работы информацияможет быть получена от экземпляров класса Actions.Изменение технических требованийЕсли принятые проектные решения были реализованы правильно, тоновые технические требования к системе могут быть удовлетворены приминимальных изменениях проекта. Допустим, что предъявлены три новыетребования к данной системе:•возможность дешифровки с иностранных языков;•возможность дешифровки перестановочного и простогоподстановочного шифра, использующего (одну) подстановку иперестановку;•способность к самообучению.Первое требование самое простое, поскольку связь нашей системы санглийским языком не является существенной. Она отражается только направилах источников знаний.
Даже класс Alphabet сделан независимым отконкретного национального алфавита.Второе требование существенно сложнее, но разрешимо в рамкахмеханизма доски. Это потребует введения новых источников знанийотносительно шифров перестановки. Ключевые механизмы и абстракции приэтом также полностью сохранятся, но потребуется введение новых классов,которые будут действовать в рамках существующих механизмов выдвиженияпредположений и вывода.Труднее всего выполнить последнее требование, так как обучениекомпьютеров относится к области искусственного интеллекта. Можно,например, предложить контроллеру в тупиковых ситуациях обращаться запомощью к пользователю системы с просьбой выдвинуть предположение.Такие предположения (вкупе с последовательностью действий, которая завелав тупик) могут регистрироваться системой и позволят в дальнейшем избегатьподобных тупиков.
Такой простейший механизм обучения может быть введенв нашу систему без существенного изменения структуры классов и в рамкахдействующих механизмов.Дополнительная литератураПри рассмотрении архитектурных шаблонов Шоу (Shaw) [A 1991]обсуждает метафору информационной доски и другие базовые идеи.Енглемор и Морган (Englemore and Morgan) [С 1988] далиисчерпывающее обсуждение информационных досок, включая их эволюцию,теорию, проектирование и приложение. Существует описание двух объектноориентированных систем информационных досок: ВВ1 из Стэнфорда и BLOB,разработанной для Британского министерства обороны.
Другие полезныесведения относительно информационных досок могут быть найдены у ХайесаРота (Hayes-Roth) D 1985] и Нии (Nil) [) 1986].Подробное обсуждение индуктивного и дедуктивного подходов всистемах формального вывода можно найти в работах Барра и Фейгенбаума(Barr and Feigenbamn) [J 1981 ], Брахмана и Левескье (Brachman and Levesque)U 1985], Хайес-Рота, Ватермана и Лена (Hayes-Roth, Waterman, and Lenat) [J1983], а также Винстона и Хорна (Winston and Horn) [Gl 989].Мейер и Матиас (Meyer and Matyas) [I 1982] рассмотрели сильные ислабые стороны разных шифров и алгоритмы их дешифровки.Глава 12Управление: контрольза движением поездовПрограммная индустрия развилась настолько, что охватывает многие новые областиприложений: от встроенных микрокомпьютеров для управления двигателемавтомобиля до выполнения рутинной работы при изготовлении фильмов и обеспеченияинтерактивного доступа миллионов телезрителей к базам видеоинформации.Отличительной особенностью таких больших систем является их чрезвычайнаясложность.
Конечно, построить компактную реализацию системы - задача почетная, нонекоторые большие задачи несомненно требуют большого объема кода. В крупныхпроектах нередко участвуют программистские организации в сотни человек, которыедолжны написать миллионы строк кода. Программы должны удовлетворятьтребованиям, неизбежно меняющимся в процессе работы.
Как правило, в рамках такихпроектов создается не одна программа, работающая на одном компьютере, а комплекспрограмм, функционирующих в параллельной распределенной среде на несколькихкомпьютерах, связанных между собой разнообразными каналами передачиинформации. Для того, чтобы уменьшить вероятность неудачи, в таких проектахпредусматривается обычно центральная организация, отвечающая за архитектуру ицелостность системы.
Некоторые части системы нередко выполняются посубконтрактам другими компаниями. Таким образом, команда разработчиков никогда несобирается вместе, она распределена в пространстве и, - так как в больших проектахпроисходит постоянное обновление кадров, - во времени.Если за создание большой системы возьмется разработчик, который занималсянаписанием в оконной среде небольших программ, рассчитанных на одногопользователя, его несомненно испугают возникающие проблемы; возможно, даженастолько, что он сочтет глупостью попытку создать такую программу. Нодействительность такова, что большие системы должны строиться. И в некоторыхслучаях глупо не попытаться.
Вообразим себе ручное управление авиационнымиполетами во круг столичного аэропорта, систему жизнеобеспечения космическойстанции, зависящую от "человеческого фактора" или ведение учета в международномбанке, выполняемое на счетах. Успешная автоматизация таких систем приводит нетолько к решению очевидных проблем, но и приносит множество неожиданных выгод:снижение эксплуатационных расходов, повышение надежности, увеличениефункциональных возможностей.
Конечно же, ключевое слово здесь - успешная. Извсего сказанного понятно, что создание больших систем - чрезвычайно трудная задача.Поэтому при ее решении необходимо применять все лучшее из инженерной практики ииспользовать интуицию ведущих проектировщиков.В этой главе представлена как раз такая задача.
Она демонстрирует, как объектноориентированное проектирование облегчает выполнение сверхбольших программныхпроектов.12.1. АнализОпределение границ проблемной областиДля большинства люден, живущих в США, поезда являются символомдавно ушедшей эпохи. В Европе и странах Востока ситуация совершеннопротивоположная. В отличие от США, в Европе мало национальных имеждународных автомобильных магистралей, а цены на бензин и газсравнительно высоки.
Поэтому поезда составляют основу транспортной сетиконтинента; по десяткам тысяч километров путей ежедневно перевозитсямножество людей и грузов - и в отдельных городах, и между различнымистранами. Ради справедливости отметим, что в США поезда играют попрежнему важную роль в перевозке грузов. С разрастанием городов их центрыстановятся все более и более перегруженными, и на легкий рельсовыйтранспорт возлагаются надежды решить проблему перегрузки и загрязненияокружающей среды двигателями внутреннего сгорания.Железные дороги по-прежнему являются коммерческими и,следовательно, они должны быть прибыльными.
Железнодорожные компанииобязаны постоянно поддерживать баланс между требованиями экономии ибезопасности и нарастающей интенсивностью перевозок с одной стороны иэффективным и предсказуемым расписанием - с другой. Эти противоречиянаводят на мысль, что решения об управлении движением поездовнеобходимо принимать автоматически, и, в том числе, производить контрольза всеми элементами железной дороги с помощью компьютера.Такие автоматические и полуавтоматические системы сегоднясуществуют в Швеции, Великобритании, Германии, Франции и Японии [I].Подобная система, называемая Продвинутой Системой УправленияЖелезнодорожным Транспортом, была разработана в Канаде и США сучастием следующих компаний: Amtrak, Burlington, Canadian National RailwayCompany, CP Rail, CSX Transportation, Norfolk and Western Railway Company,Southern Railway Company, Union Pacific. Эффект от каждой из этих систембыл и экономический, и социальный; результа-Требования к системе управления движениемСистема управления движением выполняет две главные функции:выбор маршрутов железнодорожных перевозок и контроль систем,обеспечивающих перевозки.
Эти функции включают: планированиеперевозок, контроль местонахождения поездов, контроль за перевозками,предотвращение конфликтов, прогнозирование нарушении, регистрацию всехопераций. На рис. 12-1 показана схема основных элементов системыуправления движением [2].Рис. 12-1. Система управления движениемСистема анализа и отображения информации на локомотиве состоит измножества дискретных и аналоговых датчиков для контроля за такимипараметрами, как температура, давление масла, количество топлива,напряжение и сила тока на генераторе, число оборотов вала двигателя вминуту, температура воды, тяговая мощность. Значения параметров сдатчиков поступают к машинисту через дисплейную систему, а к диспетчеру иобслуживающему персоналу вне поезда - через сеть.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
