Идея состоит в том, чтобы внутри базового класса (Конверта) хранить указатель на объект этого же типа (Письма). При этом Конверт должен «перенаправлять» вызовы виртуальных методов на Письмо. С хорошими примерами у меня, как всегда, небольшие проблемки, поэтому «промоделируем» систему магических техник (или заклинаний) =) Предположим, что для каждой техники используется один из пяти основных элементов (а может и их комбинация), от которых зависит воздействие этой техники на окружающий мир и на предмет, к которому она применяется. В то же время мы хотим иметь возможность работать со всеми техниками независимо от их типа.

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

#include
#include
#include
#include

using std:: cout ;
using std:: endl ;

enum
{
FIRE = 0x01 ,
WIND = 0x02 ,
LIGHTNING = 0x04 ,
SOIL = 0x08 ,
WATER = 0x10
} ;

class Skill // aka Jutsu =)
{
public :
// virtual (envelope) constructor (see below)
Skill(int _type) throw (std:: logic_error ) ;

// destructor
virtual ~Skill()
{
if (mLetter)
{
// virtual call in destructor!
erase() ;
}

delete mLetter; // delete Letter for Envelope
// delete 0 for Letter
}

virtual void cast() const { mLetter- > cast() ; }
virtual void show() const { mLetter- > show() ; }
virtual void erase() { mLetter- > erase() ; }

protected :
// letter constructor
Skill() : mLetter(NULL ) { }

private :
Skill(const Skill & ) ;
Skill & operator= (Skill & ) ;

Skill * mLetter; // pointer to letter
} ;

class FireSkill : public Skill
{
public :
~FireSkill() { cout << "~FireSkill()" << endl; }
<< "Katon!" << endl; }
<< "FireSkill::show()" << endl; }
<< "FireSkill:erase()" << endl; }
private :
friend class Skill;
FireSkill() { }
FireSkill(const FireSkill & ) ;
FireSkill & operator= (FireSkill & ) ;
} ;

class WoodSkill : public Skill
{
public :
~WoodSkill() { cout << "~WoodSkill()" << endl; }
virtual void cast() const { cout << "Mokuton!" << endl; }
virtual void show() const { cout << "WoodSkill::show()" << endl; }
virtual void erase() { cout << "WoodSkill::erase()" << endl; }
private :
friend class Skill;
WoodSkill() { }
WoodSkill(const WoodSkill & ) ;
WoodSkill & operator= (WoodSkill & ) ;
} ;

Skill:: Skill (int _type) throw (std:: logic_error )
{
switch (_type)
{
case FIRE:
mLetter = new FireSkill;
break ;

case SOIL | WATER:
mLetter = new WoodSkill;
break ;

// ...

default :
throw std:: logic_error ("Incorrect type of element" ) ;
}

// virtual call in constructor!
cast() ;
}

int main()
{
std:: vector < Skill* > skills;

try
{
skills.push_back (new Skill(FIRE) ) ;
skills.push_back (new Skill(SOIL | WATER) ) ;
// skills.push_back(new Skill(LIGHTNING));
}
catch (std:: logic_error le)
{
std:: cerr << le.what () << endl;
return EXIT_FAILURE ;
}

for (size_t i = 0 ; i < skills.size () ; i++ )
{
skills[ i] - > show() ;
delete skills[ i] ;
}

return EXIT_SUCCESS ;
}

В принципе это не так интересно, но вывод будет следующим:

Katon!
Mokuton!
FireSkill::show()
FireSkill:erase()
~FireSkill()
WoodSkill::show()
WoodSkill::erase()
~WoodSkill()

Давайте лучше разберёмся, что же происходит.

Итак, у нас есть класс Skill (конверт), содержащий указатель на объект такого же типа (письмо). Конструктор копирования и оператор присваивания скроем в private от греха подальше. Основной интерес представляют два конструктора класса, один из которых открытый, а другой защищенный, а также деструктор.

Открытый конструктор, он же конструктор Конверта, он же в нашем случае «виртуальный конструктор» (его определение находится ниже), принимает один параметр - тип «элемента», на основе которого будет вычислен тип конструируемого объекта. В зависимости от входного параметра указатель на письмо инициализируется указателем на конкретный объект (FireSkill, WoodSkill и т.п., которые унаследованы от Skill). В случае, если во входном параметре неверное значение, выбрасывается исключение.

В производных классах техник FireSkill, WoodSkill и т.д. конструкторы по умолчанию закрыты, но базовый класс Skill объявлен как friend, что позволяет создавать объекты этих классов только внутри класса Skill. Конструктор копии и оператор присваивания в этих классах закрыты и не определены. Все виртуальные методы класса Skill переопределены в производных.

Виртуальный конструктор должен быть определен ниже всех производных классов, чтобы не пришлось париться с опережающими объявлениями (forward declarations), так как внутри него создаются объекты производных классов.

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

Каким образом происходит вызов виртуальных методов? В базовом классе внутри виртуальных методов идет «перенаправление»: фактически Конверт играет роль оболочки, которая просто вызывает методы Письма. Так как методы Письма вызываются через указатель, то происходит позднее связывание, то есть вызов будет виртуальным. Более того! Мы можем виртуально вызывать методы в конструкторе и : при создании объекта Skill (Конверта) происходит вызов параметризованного конструктора этого класса, который конструирует Письмо и инициализирует mLetter. После этого мы вызываем cast(), внутри которого стоит вызов mLetter->cast(). Так как mLetter на этот момент уже инициализирован, происходит виртуальный вызов.

То же самое в деструкторе ~Skill(). Сначала мы проверяем, проинициализирован ли mLetter. Если да, значит мы находимся в деструкторе Конверта, поэтому виртуально вызываем метод зачистки Конверта, а затем его удаляем. Если же нет, значит, мы в деструкторе Конверта, в котором выполняется delete 0 (а эта конструкция вполне безопасна).

Важные моменты:

1. Все объекты теперь создаются через один конструктор, и дальше мы будто бы работаем с объектом базового класса. Все виртуальные вызовы находятся внутри самого класса. Мы даже можем создать объект класса Skill в стеке - методы этого объекта все равно будут работать будто виртуальные.
2. В конструкторе и деструкторе мы можем использовать виртуальный вызов методов.
3. Базовый класс является, можно сказать, в каком-то роде абстрактным, потому что все его виртуальные методы должны быть переопределены в производных классах. Если этого не сделать, это приведет к тому, что, к примеру, mLetter->cast() будет ничем иным как попытка вызвать метод NULL-указателе.
4. При вызове виртуального конструктора тип создаваемого объекта будет действительно определятся на этапе выполнения, а не на этапе компиляции. Однако такой вызов следует заключать в блок try-catch, иначе можно пропустить исключение.
5. Если мы захотим добавить в базовый класс еще один виртуальный метод, придется переопределять его во всех производных.

Надеюсь, кому-нибудь пригодится;)

Теги:

• cpp
• виртуальный конструктор

Добавить метки

» Виртуальный конструктор в C++

Виртуальный конструктор в C++

Как известно, в языке программирования C++ нет прямой поддержки виртуального конструктора, однако, существует идиома, с помощью которой можно имитировать его работу. Прежде чем ее рассматривать, попробуем понять, каким поведением должен обладать виртуальный конструктор.

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

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

Фабричные методы, например, на базе обобщенного конструктора (паттерны Factory Method и Prototype), также предназначены для создания объектов без указания их конкретных типов, однако их поведение отлично от поведения виртуального конструктора.

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

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

#include #include #include // Идентификаторы всех родов войск enum Warrior_ID { Infantryman_ID, Archer_ID, Horseman_ID }; class Warrior { public: Warrior(): p(0) { } Warrior(Warrior_ID id); virtual void info() { p->info(); } virtual ~Warrior() { delete p; p=0; } private: Warrior* p; }; class Infantryman: public Warrior { public: void info() { cout << "Infantryman" << endl; } private: Infantryman(): Warrior() {} Infantryman(Infantryman&); Infantryman operator=(Infantryman&); friend class Warrior; }; class Archer: public Warrior { public: void info() { cout << "Archer" << endl; } private: Archer(): Warrior() {} Archer(Archer&); Archer operator=(Archer&); friend class Warrior; }; class Horseman: public Warrior { public: void info() { cout << "Horseman" << endl; } private: Horseman(): Warrior() {} Horseman(Horseman&); Horseman operator=(Horseman&); friend class Warrior; }; Warrior::Warrior(Warrior_ID id) { if (id == Infantryman_ID) p = new Infantryman; else if (id == Archer_ID) p = new Archer; else if (id == Horseman_ID) p = new Horseman; else assert(false); } int main() { vector v; v.push_back(new Warrior(Infantryman_ID)); v.push_back(new Warrior(Archer_ID)); v.push_back(new Warrior(Horseman_ID)); for(int i=0; iinfo(); // ... }

Рассмотрим особенности реализации идиомы виртуального конструктора:

1. Класс Warrior одновременно является основным классом для конверта и базовым классом для подклассов писем Infantryman, Archer, Horseman.
2. Пользователи не могут непосредственно создавать воинов разных родов войск, так как конструкторы подклассов писем не являются общедоступными.
3. Для создания воина некоторого типа используется конструктор конверта Warrior(Warrior_ID id). По полученному идентификатору типа в куче создается объект-воин, адрес которого и присваивается указателю на письмо. При этом в самом письме этот указатель не используется, поэтому при конструировании самого письма будет вызван конструктор по умолчанию Warrior(), который и инициализирует его нулем.
4. Метод info() в базовом классе должен быть объявлен виртуальным для того, чтобы конверт мог автоматически перенаправить этот вызов в соответствующее письмо по указателю на объект базового класса.
5. При разрушении конверта его деструктор освобождает память, занимаемую письмом. Это в свою очередь приводит к вызову деструктора базового класса Warrior для письма, где выполняется ничего не делающая команда delete 0.

Страница 49 из 70

6.7.2 Указание размещения

По умолчанию операция new создает указанный ей объект в свободной памяти. Как быть, если надо разместить объект в определенном месте? Этого можно добиться переопределением операции размещения. Рассмотрим простой класс:
class X {
// ...
public:
X(int);
// ...
}; Объект можно разместить в любом месте, если ввести в функцию размещения дополнительные параметры:
// операция размещения в указанном месте:
void* operator new(size_t, void* p) { return p; } и задав эти параметры для операции new следующим образом:
char buffer;

Void f(int i)
{
X* p = new(buffer) X(i); // разместить X в buffer
// ...
} Функция operator new(), используемая операцией new, выбирается согласно правилам сопоставления параметров ($$R.13.2). Все функции operator new() должны иметь первым параметром size_t. Задаваемый этим параметром размер неявно передается операцией new.

Определенная нами функция operator new() с задаваемым размещением является самой простой из функций подобного рода. Можно привести другой пример функции размещения, выделяющей память из некоторой заданной области:

Class Arena {
// ...
virtual void* alloc(size_t) = 0;
virtual void free(void*) = 0;
};

Void operator new(size_t sz, Arena* a)
{
return a.alloc(sz);
} Теперь можно отводить память для объектов произвольных типов из различных областей (Arena):
extern Arena* Persistent; // постоянная память
extern Arena* Shared; // разделяемая память

Void g(int i)
{
X* p = new(Persistent) X(i); // X в постоянной памяти
X* q = new(Shared) X(i); // X в разделяемой памяти
// ...
} Если мы помещаем объект в область памяти, которая непосредственно не управляется стандартными функциями распределения свободной памяти, то надо позаботиться о правильном уничтожении объекта. Основным средством здесь является явный вызов деструктора:
void h(X* p)
{
p->~X(); // вызов деструктора
Persistent->free(p); // освобождение памяти
} Заметим, что явных вызовов деструкторов, как и глобальных функций размещения специального назначения, следует, по возможности, избегать. Бывают случаи, когда обойтись без них трудно, но новичок должен трижды подумать, прежде чем использовать явный вызов деструктора, и должен сначала посоветоваться с более опытным коллегой.

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

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

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

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

Таким образом, у нас возникает необходимость скопировать весь список с сохранением типов объектов, но самих типов мы не знаем.

Функции, которые помогают решить эту задачу, и называют виртуальными конструкторами.

Различают два вида виртуальных конструкторов - по умолчанию и копирующий. Означают эти термины то же, что и в случае обычных конструкторов. Конструктор по умолчанию создает "пустой" объект (такого же, как и у образца, типа). Копирующий конструктор еще и копирует во вновь созданный объект содержимое образца.

Делается это следующим образом: - в базовом классе определяются две виртуальные (в примере ниже это makeobject и copyobject), которые создают объект (copyobject еще и копирует в новый объект содержимое образца) и возвращают указатель на него:

#include #include using namespace std; class A { protected: int val; public: A(int v=0) : val(v) {}; A(const A& src) : val(src.val) {}; // makeobject() is a virtual default ctor virtual A* makeobject() { A* ptr=new A; return ptr; } // copyobject() is a virtual copy ctor virtual A* copyobject() { A* ptr=new A(*this); } virtual void show() { cout << "Object of type A, val=" << val << endl; } }; // End of class A definition

Затем, при разработке производного класса вы замещаете эти две функции другими - создающими и копирующими объект вашего нового типа, но по прежнему возвращающими указатель на базовый класс:

class B: public A { string s; public: B(const char *str) : s(str) {}; // Copy ctor B(const B& src) : A(src), s(src.s) {}; // Default ctor B() : s("") {}; // virtual default ctor for class B A* makeobject() { B* ptr=new B; return ptr; } // virtual copy ctor for class B. A* copyobject() { B* ptr=new B(*this); return ptr; } virtual void show() { cout << "Object of type B, s=" << s << endl; } }; // end of class B definition

Проверить, как это работает, поможет небольшая программа

main() { A a(1); B b("Hello"); A* psrc = {&a, &b}; A* pmake; A* pcopy; for (int i=0; i<2; i++) { pmake[i] = psrc[i]->makeobject(); pcopy[i] = psrc[i]->copyobject(); psrc[i] ->show(); pmake[i]->show(); pcopy[i]->show(); } return 0; }

Object of type A, val=1 Object of type A, val=0 Object of type A, val=1 Object of type B, s=Hello Object of type B, s= Object of type B, s=Hello

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

Каждый объект уникальный поэтому при написантт программы не можем указать всем объектам одну сигнатуру

Вызывают внутри метода

Вызывающее значение порождающего объекта как класса, находящегося на самом нижнем иерархии наследования

Введение

В настоящее время учебных виртуальных конструкторов (учебных сред) изобретено мало, хотя в условиях быстрой компьютеризации общества они приобретают все большую популярность. Их идея довольно проста. Можно дать ребенку возможность наблюдать за ходом физического эксперимента на экране компьютера, а можно позволить ему самому этот эксперимент ставить - расположить наклонные плоскости, гирьки, тележки, бильярдные шары, планеты Солнечной системы, электроны и пешеходов и посмотреть, что получиться. И не только посмотреть, но, если надо, получить все графики во всех осях координат и т. д. Сложна ли постановка виртуального эксперимента? Не сложнее, чем рассказ о ней и много проще, чем реальная постановка. Возможность постановки виртуального эксперимента, а, если нужно, и сотен и тысяч экспериментов, радикально меняет учебный процесс.

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

Основная часть

1. Понятие «Виртуальный конструктор»

Виртуальный конструктор (учебная среда) - это образовательный электронный ресурс, позволяющий в рамках законов и правил, заданных предметной областью, строить модели и работать с ними в объектной технологии.

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

Обучение при использовании виртуальных конструкторов становится более интерактивным. Интерактивное обучение основано на прямом взаимодействии учащихся (обучаемых) с учебным окружением. Учебное окружение, или учебная среда, выступает как реальность, в которой участники находят для себя область осваиваемого опыта.

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

2. Особенности учебных сред

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

· во-первых, они должны быть доступными учащимся и соответствовать их уровню знаний и мышления;

· во-вторых, они должны быть воспроизводимыми и соответственно представлять все системные связи и отношения;

· - в-третьих, они должны содержать максимально возможное количество средств самоактивизации.

В этом, очевидно, большое преимущество компьютерных средств обучения. Их средства управления и пользовательского интерфейса обязаны соответствовать уровню искусственного интеллекта, возлагая на себя часть функций учителя. Таким образом, печатные и компьютерные средства в системе обучения «ученик - учебная среда – технологии» должны соответствовать системному подходу. Такой тип обучения может быть применим в средней школе, во-первых, в дифференцированной форме, а во-вторых, только как надстройка над базовой системой с учетом специфики и профильной направленности обучения. Разумеется, любые печатные и компьютерные средства могут использоваться в полной системе обучения в качестве дополнительных учебных пособий (помимо основных учебников). В этом случае они выступают в качестве иллюстративных аудиовизуальных средств или сборников экспериментального материала, и поэтому к ним не предъявляются никакие требования, кроме требований качества и соответствия целям обучения.

Как дополнительные средства обучения компьютерные технологии имеют много преимуществ перед обычными средствами (учебниками): в полной мере реализуют деятельностный подход, обеспечивая оперативность исполнения любого запроса к системе и реализации обратной связи, а также не только выдачу в реальном режиме работы результатов (оценки) деятельности ученика, но и возможность мгновенного исправления допущенных ошибок в серии попыток. Это и позволяет учителю, освободившись тем самым от рутинных забот, сосредоточиться на базовых проблемах обучения и системного восприятия обучаемыми его содержания, реализуя технологии индивидуального подхода в обучении.

3. Основные виды виртуальных конструкторов

Логомиры .

Самой знаменитой учебной средой является Лого. В ЛогоМирах ребенок рисует фантастические пейзажи, сопровождает их письменными и устными текстами, населяет самыми разными персонажами, задавая для них математические законы поведения. Перволого - Лого для маленьких позволяет делать все это тем, кто еще не умеет читать и считать, но хочет научиться этому, а заодно многому другому. Используя прикладные программные средства общего назначения учитель (а тем паче, ученик) может создать собственную специальную образовательную среду для конкретного проекта. Например - нарисовать на экране визитную карточку, которую дети заполняют (с индивидуальной, посильной для них скоростью и грамотностью) придя в первый класс. Внутри компьютера все визитные карточки слетаются в одну общую записную книжку. Компьютер для каждого ученика печатает все листочки этой книжки. Ну, а разукрасить и вырезать сбоку страничку до нужной буквы и сшить в настоящую, не виртуальную, книжку - это дело самого ученика. Эта записная книжка становится для учащегося и его родителей не только полезным информационным продуктом, но и метафорой современной жизни в Сети (Интернете), где каждый рассказывает о себе и может узнать обо всех.

Элкон .

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

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

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

Элкон - безъязыковая среда, поэтому особенно эффективна для работы с маленькими детьми, ещё достаточно хорошо не овладевшими речью. Принято считать, что в первую очередь математика и логика способствуют формированию абстрактного мышления. При этом нередко забывают, что таким средством выступает и язык.

Аскун .

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

Разработка такого тезауруса является далеко не тривиальной задачей, а сам тезаурус представляет интеллектуальный продукт. Описание каждого термина в системе его связей становится отдельным исследованием, поскольку эта работа проводится на самом глубоком уровне изучения лингвистического объекта - как в парадигматике (в ряду аналогичных объектов), так и в энциклопедическом аспекте (в системе знаний).

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

При использовании АСКУН достигаются следующие цели:

Изучение основной терминологической лексики предметной области и системы семантических связей между понятиями (тематическая и структурная ориентация);

Формирование производных словарей (микротезаурусов) на базе основного тезауруса (функциональная ориентация);

Ассоциативное усвоение элементов знаний изучаемой предметной области на основе многоаспектного использования словарной информации и графического изображения связей понятий (когнитивная ориентация).

Контур .

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

Система Контур позволяет решить любую задачу данного класса из школьного курса стереометрии, условие задачи формируется в режиме диалога. Одновременно создаются графические модели исходных объектов. При решении задачи учащийся работает с реальными объектами предметной области (точкой, прямой, отрезком, плоскостью, многоугольником, многогранником), использует набор графических операций, ему доступны различные виды вращения фигуры, работа в оконной среде.

Система Контур направляет деятельность учащегося на решение задачи и независимо от него генерирует правильный ответ. Никаких готовых решений в систему заранее не заложено. Контрольно-оценочный этап возлагается на преподавателя. Статистическую информацию о работе учащегося можно посмотреть в протоколе системы. Учитель получает информацию о том, сколько раз учащийся менял своё решение при описании объектов предметной области; сколько сделано попыток повторного решения задачи после сравнения собственного ответа с ответом компьютера; исследовалась ли задача на наличие других решений (если да, то сколько раз); какое время было затрачено на создание формальной модели условия задачи; каково общее количество задач, решённых учащимся за один сеанс работы с системой.

Основные достоинства разработки:

Построение формальной модели условия задачи;

Возможность исследования задачи на наличие других решений;

Приближение объекта к реальному, за счёт учёта свойств элементов многогранника;

Идея конструктора задач;

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

Заключение

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

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

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