Студопедия

Главная страница Случайная страница

КАТЕГОРИИ:

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Реализация интерфейсного класса black_board






 

Обратите внимание на то, что в интерфейсном классе (см. листинг 13.1) нет объявлений переменных. Вспомните, что интерфейсный класс в CORBA-реализации ограничивается только объявлением методов. В интерфейсном классе не существует компонентов, предназначенных для хранения информации. CORBA-классы должны тесно контактировать с С++-реализациями до конца работы приложения. Реальные реализации методов и необходимых переменных вносятся в производный класс (выведенный из этого интерфейсного класса). Производный класс, выведенный из интерфейсного класса black_board, представлен в листинге 13.2.

// Листинг 13.2. Фрагмент класса реализации для

// интерфейсного класса black_board

#include «black_board.h»

#include < set.h>

class blackboard: virtual public POA_black_board{

protected:

//...

set< long> SuggestionForMajor;

set< long> SuggestionForMinor;

set< long> SuggestionForGeneral;

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-задача м и.

 


Поделиться с друзьями:

mylektsii.su - Мои Лекции - 2015-2024 год. (0.007 сек.)Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав Пожаловаться на материал