set<long> SuggestionForElective;
courses Schedule; courses DegreePlan;
public:
blackboard(void); ~blackboard(void);
void suggestionsForMajor(const courses &X);
void suggestionsForMinor(const courses &X);
void suggestionsForGeneral(const courses &X);
void suggestionsForElectives(const courses &X);
courses *currentDegreePlan(void);
courses *suggestedSchedule(void);
//. . .
} ;
Этот класс реализации используется для предоставления реальных определений методов, объявленных в интерфейсном классе. Помимо реализации методов, производный класс может содержать компоненты данных, поскольку они не объявлены в качестве интерфейса. Обратите внимание на то, что класс реализации black_board, представленный в листинге 13.2, наследует непосредственно не интерфейсный класс black_board, а класс POA_black_board, который является одним из тех классов, которые создает IDL-компилятор от имени интерфейсного класса black_board. Объявление класса POA_black_board приведено в листинге 13.3.
// Листинг 13.3. Фрагмент объявления класса POA_black_board,
// созданного idl-компилятором для
// интерфейсного класса black_board
class POA_black_board : virtual public PortableServer::StaticImplementation
{
public:
virtual -POA_black_board (); black_board_ptr _this ();
bool dispatch (CORBA::StaticServerRequest_ptr); virtual void invoke (CORBA::StaticServerRequest_ptr); virtual CORBA::Boolean _is_a (const char *); virtual CORBA::InterfaceDef_ptr _get_interface (); virtual CORBA::RepositoryId _primary_interface
(const PortableServer::ObjectId &, PortableServer::POA_ptr);
virtual void * _narrow_helper (const char *); static POA_black_board * _narrow (
PortableServer::Servant); virtual CORBA::Object_ptr _make_stub (PortableServer::
POA_ptr,
CORBA::Object_ptr);
//.. .
virtual void suggestionsForMajor (const courses& Major)
= 0;
virtual void suggestionsForMinor (const courses& Minor)
= 0;
virtual void suggestionsForGeneral (
const courses& General) = 0;
virtual void suggestionsForElectives (
const courses& Electives) = 0;
virtual courses* currentDegreePlan() = 0;
virtual courses* suggestedSchedule() = 0;
//. . . protected:
POA_black_board () {}; private:
POA_black_board (const POA_black_board &); void operator= (const POA_black_board &);
};
Обратите внимание на то, что класс в листинге 13.3 является абстрактны м, поскольку он содержит чисто виртуальные функции-члены, напри м ер:
virtual courses* suggestedSchedule() = 0;
Это означает, что данный класс нельзя использовать напря м ую. Из него необходи м о вывести производный класс, в которо м будут определены реальные функции-члены для всех объявлений чисто виртуальных функций. Класс POA_black_board, представленный в листинге 13.2, содержит требуе м ые определения для всех чисто виртуальных функций-членов. Что касается нашего класса «классной доски*', то для реализации действий са м ой «доски» и источников знаний используются С ++-м етоды. Однако источники знаний реализованы частично в языке С++ и частично в языке логического про г ра мм ирования Prolog. [24] Но поскольку С++ под д ерживает мультиязыковую и мультипарадигматическую разработку, к средствам С++ можно вполне добавить достоинства языка Prolog. В С++ мы можем либо породить Prolog-задачи (с помощью posix_spawn() - или fork-exec-функций), либо получить доступ к среде Prolog через ее интерфейс с незнакомыми языками программирования, который позволяет Prolog-среде общаться непосредственно с С++ и наоборот. Независимо от того, на каком языке создана реализация источников знаний — С++ или Prolog, объект «классной доски» должен взаимодействовать только с С++-методами.
Порождение источников знаний в конструкторе «классной доски»
«Классная доска» реализуется как распределенный объект, использующий CORBA-протокол. В данном случае одной из основных целей «классной доски» является порождение источников знаний. Это важный момент, поскольку «классная доска» должна иметь доступ к идентификационным номерам задач. Начальное состояние «классной доски» (оно устанавливается в конструкторе) включает информацию о студенте, его академической характеристике, текущем семестре, требованиях для получения диплома и т.д. С помощью «классной доски», исходя из начального состояния, определяется, какие источники знаний следует запустить в работу. Иначе говоря, оценив начальную задачу и исходное состояние системы, «классная доска» составляет список запускаемых на выполнение источников знаний. Каждый источник знаний имеет соответствующий двоичный файл, а для хранения имен этих файлов «классная доска» использует контейнер Solvers. Позже, при функционировании конструктора, с по м ощью функционального объекта (или объекта-функции) и алгоритма for_each() порождаются источники знаний. Вспомните, что любой класс, в котором определена операторная функция operator(), м ож н о испо л ьзовать как функциональный объект. Объекты-функции, как прави л о при м еняют сов м естно со стандартны м и алгорит м а м и в м есто функций и л и в допо л нение к ни м. Обычно везде, где м ожно использовать обычную функцию, ее м ожно за м енить объекто м -функцией. Чтобы определить собственный функциональный объект, необходи м о определить операторный м етод operator (), придав е м у соответствующий с м ысл, указав список пара м етров и тип возвращае м ого и м значения. Наша CORBA-реализация «классной доски» м ожет под д ерживать источники знаний, реализованные с по м ощью PVM-задач, традиционных UNDC/Linux-задач или от д ельных потоков, использующих библиотеки POSIX thread. По типу задач, порождае м ых в конструкторе, м ожно определить, с каки м и и м енно задача м и будет работать «классная доска»: с POSIX-потока м и, традиционны м и UNIX/Linux-процесса м и или PVM-задача м и.
Порождение источников знаний с помощью PVM-задач
Конструктор «классной доски» содержит следующий вызов алгоритма, for_each(Solve.begin(),Solve.end(), Task);
Алгоритм for_each () применяет операторный метод объекта функции (созданного для класса задачи) к каждому элементу контейнера Solve. Этот метод используется для порождения источников знаний в соответствии с моделью MIMD, при реализации которой все источники знаний имеют различную специализацию и работают с различными наборами данных. Объявление этого класса задач приведено в листинге 13.4.
// Листинг 13.4. Объявление класса задачи
class task{
int Tid[4];
int N;
//. . .
public:
//. . .
task(void) { N = 0; } void operator()(string X);
};
void task::operator()(string X) {
int cc; pvm_mytid();
cc = pvm_spawn(const_cast<char *>(X.data()),NULL,0,"",l,&Tid[N]);
N++;
}
blackboard::blackboard(void) {
task Task;
vector<string> Solve;
//.. .
// Determine which KS to invoke
//. . .
Solve.push_back(KS1);
Solve.push_back(KS2);
Solve.push_back(KS3);
Solve.push_back(KS4);
for_each(Solve.begin(), Solve.end(), Task);
}
Этот класс task инкапсулирует порожденный процесс. Он содержит идентификационный но м ер задачи (поскольку у нас используется PVM-задача). В случае при м енения стандартных UNDC/Linux-процессов или Pthread-потоков, он должен содержать идентификационный но м ер процесса или потока. Этот класс действует как интерфейс между создаваемым процессом или потоком и «классной доской». «Классная доска» здесь является основным компонентом управления. Она может управлять PVM-задачами с помощью их идентификационных номеров. Кроме того, «классная доска» может использовать групповые PVM-операции для синхронизации PVM-задач с использованием барьеров, организации PVM-задач в логические группы, которые должны отрабатывать определенные аспекты решаемой задачи, и сигнализации членов группы с помощью соответствующих тегов сообщений. Групповые PVM-операции перечислены и описаны в табл. 13.2.
