set<long> SuggestionForMinor;
set<long> SuggestionForGeneral;
set<long> SuggestionForElective;
set<long> Schedule;
set<long> DegreePlan;
mutex Mutex[10];
//.. .
public:
blackboard(void) ;
~blackboard(void);
void suggestionsForMajor(set<long> &X);
void suggestionsForMinor(set<long> &X);
void suggestionsForGeneral(set<long> &X);
void suggestionsForElectives(set<long> &X);
set<long> currentDegreePlan(void);
set<long> suggestedSchedule(void);
//.. .
};
Класс blackboard предназначен для реализации в качестве глобального объекта, к которому смогут получать доступ все потоки в программе. Обратите внимание на то, что класс blackboard в листинге 13.10 включает массив мьютексов. Эти мьютексы используются для защиты критических разделов «классной доски». При реализации источников знаний практически нет необходимости беспокоиться о синхронизации доступа к критическим разделам, поскольку код синхронизации инкапсулирован в классе blackboard.
Активизация источников знаний с помощью потоков
В этом разделе рассматривается реализация источников знаний в отдельных потоках. Потоки создаются здесь при выполнении конструктора класса «классной доски» (blackboard), и каждому потоку назначается конкретный источник знаний. Тем самым реализуется модель MIMD. Фрагмент кода конструктора класса blackboard приведен в листинге 13.11.
// Листинг 13.11. Конструктор класса blackboard,
// используемый для создания потоков,
// содержащих источники знаний
blackboard::blackboard(void) {
pthread_t Tid[4];
//.. .
try{
pthread_create(&Tid[0],NULL,suggestionForMajor, NULL);
pthread_create(&Tid[l],NULL, suggestionForMinor, NULL);
pthread_create(&Tid[2], NULL,suggestionForGeneral, NULL);
pthread_create(&Tid[3],NULL, suggestionForElective, NULL);
pthread_join(Tid[0],NULL);
pthread_join(Tid[l],NULL);
pthread_join(Tid[2],NULL);
pthread_join(Tid[3],NULL);
}
//. . .
}
Обратите внимание на то, что конструктор вызывает функцию pthread_join(). Этот вызов заставляет конструктор ожидать завершения работы всех четырех потоков. Эти потоки могут активизироваться и с помощью других функций-членов класса blackboard. Но те действия, которые выполняют источники знаний «в рамках» конструктора, представляют своего рода предварительную инициализацию «классной доски», поэтому весьма уместно не продолжать работу по созданию объекта «классной доски» до тех пор, пока эти потоки не доведут до конца свою работу. Такой подход к созданию потоков в конструкторе заставляет задуматься об обработке ошибок и исключительных ситуаций. Что произойдет, если по какой-то причине при выполнении потоков случится сбой? Поскольку конструкторы не возвращают никаких значений, то здесь просто необходимо позаботиться об обработке исключительных ситуаций. Каждый поток связывается со «своей» функцией.
void *suggestionForMajor(void *X);
void *suggescionForMinor(void *X);
void *suggestionForGeneral(void *X);
void *suggestionForElective(void *X);
Эти четыре функции используются потоками для реализации действий соответствующих источников знаний. Поскольку «классная доска» является глобальным объектом, каждая из этих функций имеет непосредственный доступ к функциям-членам класса blackboard. Поэтому источники знаний могут вызывать функции-члены «классной доски» напрямую.
//...
Combination.generateCombinations(1,9, Courses);
Result = Combination.element(9);
//.. .
Blackboard.suggestionsForMinor(Value);
//.. .
Поскольку некоторые разделы «классной доски» имеют ограниченный доступ для отдельных источников знаний, то к этим разделам можно применить CRCW-стратегию доступа (рис. 13.9).
Тип параллелизма, представленный на рис. 13.9, вполне естествен для систем, реализующих модель «классной доски», поскольку «классная доска» часто делится на разделы, относящиеся к определенным частям задачи или подзадачи. Обычно одной проблемной области соответствует один источник знаний, поэтому параллельный доступ к этим разделам вполне уместен.
Резюме
Рис. 13.9. Четыре источника знаний могут параллельно считывать информацию из соответствующих разделов «классной доски» и записывать ее туда
Модель «классной доски» поддерживает параллелизм, который присутствует как в структуре «классной доски», так и в отношениях между «классной доской» и источниками знаний, а также между самими источниками знаний. Модель «классной доски» — это модель решения некоторой задачи. Общая задача делится на части, соответствующие конкретным областям знаний. Каждой области назначается источник знаний, или решатель задач. Источники знаний обычно отличаются самодостаточностью (автономностью) и не требуют интенсивного общения с другими источниками знаний. Необходимое взаимодействие осуществляется через «классную доску». Следовательно, источники знаний позволяют организовать обработку данных в рамках программы по модульному принципу. Такие своеобразные модули могут работать отдельно и параллельно, не требуя сложной синхронизации. «Классную доску» можно реализовать в виде CORBA-объектов. В этом случае источники знаний могут быть распределены в сетях intranet или Internet. «Классная доска» действует как разновидность общей распределенной па м яти д ля за д ач, выполняе м ых в сре д е PVM-типа. В м о д ель «классной д оски» легко вписываются м о д ели MPMD (MIMD) и SPMD (SIMD). Концепция «классной д оски» побуж д ает разработчика раз д елить работу, которую должна выполнить програ мм а, на области знаний. После проведения деко м позиции работ «классная доска» должна содержать м одели ПО пред м етной области и пространства решений. Эти м одели ПО позволяют проектировщику и разработчику вскрыть параллелиз м, который необходи м о реализовать в програ мм е. После классической м одели распределенного програ мм ирования «клиент-сервер» м одель «классной доски» является одной из м о щ ных м оделей, доступных как для распределенного, так и д л я парал л е л ьного програ мм ирования. Источники знаний, и л и решате л и задач, в м оде л и «классной доски» зачастую реализуются как агенты.
Приложение A
Это приложение представляет собой краткий справочник UML-диаграмм, используемых в этой книге. Универсальный язык моделирования (Unified Modeling Language - UML) предлагает графические обозначения, используемые для проектирования, визуализации, моделирования и документирования артефактов системы программного обеспечения. Этот язык является стандартом «де-факто» для моделирования объектно-ориентированных систем. В нем используются символы и обозначения для представления артефактов системы ПО с различных точек зрения. И хотя в книге используются и другие обозначения, это приложение позволит читателю быстро ознакомиться с основными элементами и символами языка UML, которые могут понадобиться ему при составлении Документации на разрабатываемые системы ПО.
Диаграммы классов и объектов
Диаграммы классов и объектов — самые распространенные диаграммы, используемые в моделировании объектно-ориентированных систем. Диаграммы классов используются для представления классов любого типа, в том числе шаблонных и интерфейсных классов. Эти диаграммы могут содержать члены класса (атрибуты и операции). В диаграммах классов и объектов отображаются типы данных, значения переменных и типы значений, возвращаемых функциями. В диаграммах объектов можно отобразить имя объекта. В диаграммах обоих типов можно указать количество классов или объектов, используемых в системе, а также отношения между классами и объектами.
