авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 | 2 || 4 |

«ГУСС СВЯТОСЛАВ ВЛАДИМИРОВИЧ Монография АРХИТЕКТУРНАЯ СРЕДА КОМПОНЕНТОВ ВОПРОС ОТВЕТНЫХ ЛИНГВИСТИЧЕСКИХ ИГР ДЛЯ ОБУЧАЮЩИХ ПРОГРАММНЫХ ...»

-- [ Страница 3 ] --

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

4.2. Эксплуатация подсистемы «Безопасность»

От подсистемы «Безопасность» требуется, чтобы она блокировала компьютер на время работы программы в режиме тестирования.

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

Решение – заблокировать «Диспетчер задач» операционной системы, меню «Пуск» и комбинацию таких клавиш, как «Alt + Tab»

(переключение между окнами), «Alt + F4» (закрытие активного окна приложения), «Alt + Esc» (активация другого выполняющегося при ложения), «Alt + Ctrl + Del» (вызов «Диспетчера задач»).

Подсистема «Безопасность» берт на себя ответственность закрытия приложения, которому оно предоставляет функцию безопасности. Вызвано это тем, что подсистема «Безопасность»

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

4.2.1. Компоненты системы Основные компоненты (которыми пользуется разработчик):

«Security System Configurator.exe» – модуль конфигурирования подсистемы «Безопасность»;

«GSEducation.AssistantL.exe» – модуль блокировки компьютера;

«GSEducation.AssistantL.config» – файл конфигурации для мо дуля блокировки компьютера;

«GSEducation.AssistantP.exe» – модуль для задания пароля сис теме;

«GSEducation.AssistantRL.exe» – модуль разблокировки компью тера после неудачного завершения работы приложения;

«GSEducation.TestReportSystem.dll» – дополнительный модуль, дающий возможность предоставлять информацию о статисти ке процесса обучения.

Реализующие компоненты (которые использует подсистема «Безопасность»):

«GSEducation.SSystem.dll»;

«GSEducation.AssistantH.exe»;

«GSEducation.WindowsSpecialFunctions.dll»;

«GSEducation.AssistantLSF.dll»;

«GSEducation.AssistantS.config»;

«GSEducation.LanguageController.dll»;

«GSEducation.ExceptionLogger.dll».

Дополнительный модуль (внешний по отношению к подсистеме):

GSEducation.TestReportSystem.dll – модуль, реализующий воз можность выдачи результатов тестирования обучающегося.

Компонент «Security System Configurator.exe»

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

Далее приводится программный код для использования конфигуратора (это автоматизированный способ, возможен так же ручной запуск модуля «Security System Configurator.exe» с вво дом в появившемся окне требуемой информации, т.е. нужно бу дет вручную задать «Application Name»).

В программном коде: «Application Name» – имя приложения, которому оказывается услуга безопасности, «Security System Con figurator.exe» – конфигуратор, которому передатся имя прило жения «Application Name». Для работы кода потребуется использо вание пространства имн «System.Diagnostics» библиотеки «.NET Framework 2.0».

private readonly string m_ApplicationPath = Application.StartupPath + "\\";

private readonly string m_SecuritySystemConfiguratorName = "Security System Configurator.exe";

private void ClickBtnConfigure(object sender, EventArgs e){ Process.Start(m_ApplicationPath + m_SecuritySystemConfiguratorName, “Application Name”);

} После выполнения программного кода, в девятой строке файла конфигурации модуля блокировки «GSEduca tion.AssistantL.config», будет следующая надпись:

add key="LockingApplicationName" value="Application Name"/ Эта информация говорит модулю «GSEduca tion.AssistantL.exe» о том, что он должен работать с приложением «Application Name».

Компонент «GSEducation.AssistantL.exe»

Чтобы подсистема «Безопасность» выполняла свою функ цию, необходима работа модуля «GSEducation.AssistantL.exe».

Следующий программный код вызывает модуль блокировки.

Для работы кода потребуется использование пространства имн «System.Diagnostics» библиотеки «.NET Framework 2.0». Этот код должна содержать система, которой требуются услуги подсисте мы «Безопасность».

private readonly string m_ApplicationPath = Application.StartupPath + "\\";

private readonly string m_PathToSystemSecurityLockerModule = "GSEducation.AssistantL.exe";

private void ClickBtnStart(object sender, EventArgs e){ Process locker = Process.Start(m_ApplicationPath + m_PathToSystemSecurityLockerModule);

} После выполнения последней функции подсистема «Безо пасность» будет запущена.

Компонент «GSEducation.AssistantP.exe»

Подсистема «Безопасность» не будет выполнять свои главные функции до тех пор, пока ей не будет задан пароль (т.е. если па роль не задан, то система «Безопасность» будет считать, что защи та не нужна). Для задания пароля, необходимо запустить модуль «GSEducation.AssistantP.exe», и следуя инструкциям ввести пароль:





Рис. 24. Программа задания пароля Компонент «GSEducation.AssistantRL.exe»

Если произошл сбой подсистемы «Безопасность», необходимо запустить модуль «GSEducation.AssistantRL.exe», который вернт систему в прежнее состояние.

Компонент «GSEducation.TestReportSystem.dll»

Если приложению, которому оказывается услуга безопасности, необходимо передать статистику процесса обучения, можно вос пользоваться модулем «GSEducation.TestReportSystem.dll».

Модуль может использоваться отдельно от подсистемы «Безопасность», в таком случае будет невозможна защита колонки «Ответы» в окне выдачи результатов. В случае использования вместе с подсистемой безопасности, можно защитить паролем выдачу правильных ответов пользователю.

Далее представлен пример кода работы с окном выдачи статистики (результатов прохождения теста).

Для работы с библиотекой необходимо использовать про странство имн «GSEducation.TestReportSystem».

В программном коде: «m_Points» – оценка, «m_Questions» – вопросы теста, «m_CorectAnswers» – правильные ответы, «m_UserAnswers» – ответы, которые ввл пользователь, «m_TestMode»

– активация тестового режима (активен или неактивен), «m_Passwored» – указание на то, что используется пароль в систе ме безопасности, «m_FIO» – фамилия, имя и отчество пользовате ля.

private double m_Points;

private bool m_TestMode;

private bool m_Passwored;

private Liststring m_Questions = new Liststring();

private Liststring m_CorectAnswers = new Liststring();

private Liststring m_UserAnswers = new Liststring();

private string m_FIO;

… private void ClickBtnShowResults(object sender, EventArgs e){ Results results = new Results( m_Points, m_Questions, m_CorectAnswers, m_UserAnswers, m_TestMode, m_Passwored, m_FIO);

results.ShowDialog();

} Далее, в качестве примера приводится окно выдачи резуль татов, и детально разбираются его элементы.

Рис. 25. Окно «Результаты»

По середине вверху стоит Ф.И.О. – это текущее значение пе ременной m_FIO. Количество набранных баллов – «22». «7» – это значение переменной m_Points. Весовой коэффициент одного от вета – 100/(количество вопросов). В секции список ответов: а) ко лонка «Вопрос» – переменная m_Questions;

б) колонка «Ответ» – переменная m_CorectAnswers;

в) колонка «Введено» – переменная m_UserAnswers. Если (m_TestMode == false), тогда значение пере менно m_Passwored не будет учитываться. Если (m_TestMode == true) и (m_Passwored == true), тогда закрытие окна выдачи результа тов будет запрещено. Смысл в том, чтобы пользователь не смог за крыть окно в случае плохого результата (реализация принципа «строгое выполнение обязательств» подсистемы «Безопасность»).

В классе «Results» объявлен статический класс «MarkColors».

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

В реализации класс объявлен следующим образом.

public static class MarkColors{ public static Color Good = Color.PaleGreen;

public static Color Bad = Color.Pink;

public static Color MayBeRight = Color.NavajoWhite;

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

Results.MarkColors.Bad = Color.Red;

Results.MarkColors.Good = Color.Green;

Results.MarkColors.MayBeRight = Color.Orange;

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

Элементы словаря:

1. Язык («LanguageOfParticipants»). Реализация каркаса предпо лагает выбор между английским («LanguageOfPartici pants.English») и русским («LanguageOfParticipants.Russian») языками. Возможно расширение словарного запаса за счт редактирования файла со словарм или добавлением новых слов в процессе (на время игры).

2. Алфавит («Alphabet.Characters»). Набор литер выбранного языка.

3. Лексемы. Элементы словаря («KnowledgeHolder.Vocabulary»), могут быть отфильтрованы по длине, либо начальной литере.

4. Роль. Определнное представление поведения в процессе решения задачи. Виды ролей: соперник («CompetitorRole»), иг рок («PlayerRole»), судья («UmpireRole»). Действия, производи мые такими методами класса «GameManager», как «Start Game» и «MakeGameStep» происходят от лица игрока.

5. Задача-головоломка («WordPuzzle»). Состоит из обязательного условия, начального условия и секрета. Обязательное условие («WoedPuzzle.CompulsoryCondition») – то, без чего невозможно решение задачи. Например, это может быть требование – со ставлять лексемы, начинающиеся только на определнную бу кву, определнной длины или содержащие заданные буквы. В реализации каркаса этот элемент представлен в виде строко вой переменной, формат и логика обработки которой, долж на предусматриваться создателем задачи. Начальное условие и секрет также представлены в виде строковых переменных и соответственно предполагают создание логики их обработки и интерпретации. Начальное условие («WordPuzzle.InitialCondi tion») – то с чего следует начинать процесс решения. Напри мер, это может быть требование – начинать процесс с со ставления лексемы определнной длины. Секрет («WordPuz zle.Secret») – представление задачи-головоломки в формате, предусмотренном составителем задачи.

6. Процесс решения («GameProcessState»). Состояние процесса решения: активный («GameProcessState.Active»), неактивный («GameProcessState.Inactive»). Если задача решена полностью, логика каркаса переводит процесс в неактивное состояние.

7. Вопрос/Ответ. Вопрос – действие игрока по отношению к со пернику. Ответ – действие соперника по отношению к игроку.

Ответы и вопросы – элементы диалога, сообщения которыми они обмениваются. В листинге 2 главы 4, в методах «VerifyQues tionLogic» и «GetAnswerLogic» представлены точки расширения, которые требуют определения логик проверки вопросов и вы дачи соответствующего ответа. В рамках логики проверки во просов («VerifyQuestionLogic») необходимо выдать результат обработки вопроса («QuestionVerificationResult»). Результат может быть следующим: корректный вопрос («QuestionVerifi cationResult.Correct»), некорректный вопрос («QuestionVerifica tionResult.Incorrect»), повторный вопрос («QuestionVerificatio nResult.Repeat»). В рамках логики ответа на вопрос («GetAns werLogic») необходимо указать состояние решения задачи («GamePuzzleState»). Состояния решения задачи: почти реше на («GamePuzzleState.AlmostCompleted»), решена («GamePuz zleState.Completed»), нерешена («GamePuzzleState.NotComp leted»).

8. Правила («GameRules»). Следят за исполнением логики про верки вопроса («VerifyQuestionLogic»).

9. Шаг. В рамках процесса решения задачи, шаг представляет собой последовательность действий – задать вопрос, получить ответ. Статистика шагов («StepsStatistics»). Логика каркаса фиксирует каждый шаг (совершнный ход) в рамках статисти ки. Статистика учитывает: состояния решения задачи, времен ные отметки, вопросы.

4.3.2. Реализация задач-головоломок для лингвистиче ских игр Лингвистическая задача «What Letter I Thought»

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

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

Логика создания задачи-головоломки (точка расширения метода «MakePuzzle» в листинге 2 главы 4) заключается в следую щем. Сопернику необходимо выбрать случайным образом букву, которую игрок должен угадать. В данном случае можно воспользо ваться такими элементами предметной области, как «GameCom petent.CharacterSet.Characters» и «CompetitorRole.Puzzle.Secret».

Случайным образом выбирается буква из алфавита текущего язы ка. Е значение становится секретом задачи-головоломки.

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

Логика стратегии выдачи ответа (точка расширения метода «GetAnswerLogic»). Суть такова – анализируется вопрос, заданный игроком. Если его вопрос, он же требуемое слово (либо буква, если игрок на втором этапе), содержит секрет задачи, т.е. букву, которую нужно угадать, то в зависимости от того, на каком этапе находится игрок, решается, перевести его на второй этап или же поздравить с победой. С первого взгляда, кажется, что игрок на первом же этапе может назвать требуемую букву, не переходя на второй этап. Однако это невозможно, т.к. вышеописанная логика стратегии проверки вопроса игрока, на первом этапе сравнивает его вопрос на принадлежность словарю. А словарь, по крайней мере, входящий в реализацию описываемого каркаса, не содер жит слов длиною в одну букву.

Листинг. Реализация «What Letter I Thought»:

«MakePuzzle» extension point:

Random randomizer = new Random();

Liststring alphabet = CharacterSet.Characters;

if (alphabet != null){ int currentIndex = randomizer.Next(0, alphabet.Count - 1);

if (alphabet.Count currentIndex){ Competitor.Puzzle = new WordPuzzle();

Competitor.Puzzle.Secret = alphabet[currentIndex];

}} «VerifyQuestionLogic» extension point:

verificationResult = QuestionVerificationResult.Incorrect;

st //1 stage if (gameManager.Umpire.PuzzleState == GamePuzzleState.NotCompleted){ if (gameManager.HolderOfKnowledge.FindWord(question[0])) verificationResult = QuestionVerificationResult.Correct;

} nd //2 stage if (gameManager.Umpire.PuzzleState == GamePuzzleState.AlmostCompleted){ if (question[0].Length == 1 && gameManager.CharacterSet.Characters.Contains(question[0])){ verificationResult = QuestionVerificationResult.Correct;

}} «GetAnswerLogic» extension point:

if (question[0].Contains(gameManager.Umpire.Competitor.Puzzle.Secret)){ if (gameManager.Umpire.PuzzleState == GamePuzzleState.NotCompleted) puzzleState = GamePuzzleState.AlmostCompleted;

else if (gameManager.Umpire.PuzzleState == GamePuzzleState.AlmostCompleted) puzzleState = GamePuzzleState.Completed;

} else{ if (gameManager.Umpire.PuzzleState == GamePuzzleState.AlmostCompleted && question[0].Length == 1){ puzzleState = GamePuzzleState.AlmostCompleted;

}} Лингвистическая задача «What Word I Thought»

Описание задачи. Условие – случайным образом загадывается слово. От игрока требуется угадать это слово. Игрок последова тельно должен задавать вопросы в виде требуемых слов. После каждого вопроса игрок получает ответ. Ответ – количество букв в загаданном слове, которые встречаются в вопросе игрока. Т.е. от вет представлен в виде подсказки, уточняющей правильность на правлений поиска игрока в процессе решения задачи. Задача считается решнной только тогда, когда игрок отгадает загаданное слово.

Листинг. Реализация «What Word I Thought»:

«MakePuzzle» extension point:

Random randomizer = new Random();

Liststring dict = HolderOfKnowledge.Vocabulary;

if (dict != null){ int currentIndex = randomizer.Next(0, dict.Count - 1);

if (dict.Count currentIndex){ Competitor.Puzzle = new WordPuzzle();

Competitor.Puzzle.Secret = dict[currentIndex];

}} «VerifyQuestionLogic» extension point:

QuestionVerificationResult result = QuestionVerificationResult.Incorrect;

if (gameManager.HolderOfKnowledge.FindWord(question[0])){ result = QuestionVerificationResult.Correct;

} «GetAnswerLogic» extension point:

if (question[0].Contains(gameManager.Umpire.Competitor.Puzzle.Secret)) puzzleState = GamePuzzleState.Completed;

else{ int lettersNumber = 0;

for (int i = 0;

i question[0].Length;

i++){ if (gameManager.Umpire.Competitor.Puzzle.Secret.Contains( question[0][i].ToString())) lettersNumber++;

} answer = lettersNumber.ToString();

} Лингвистическая задача «Funny Stairs»

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

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

Ещ один момент, который реализован стратегией проверки во проса – первый вопрос игрока должен начинаться со слова дли ной не более 3. Длина каждого последующего корректного во проса должна быть на единицу больше предыдущего. Задача бу дет решена тогда, когда игрок добертся до самого последнего вопроса. Таким образом, в начале процесса игроку даются усло вия – построить лестницу слов, начиная со слов длиною, не более 3, причм каждое должно начинаться с определнной обязатель ным условием буквы. В представленной реализации алгоритма каждый новый вопрос игрока – дополненный предыдущий. Отсюда следует, что игрок может заменять уже составленные в предыду щем ходе слова на новые, более ценные с его точки зрения или точки зрения игровой системы, где используется данный компо нент. Например, каркас не предоставляет возможности оценива ния результата решения задачи, т.к. было сделано предположение, что это обязанность «игрового движка» (game engine). Игровой движок может обращаться к статистике решения задачи посред ством объекта класса «StepsStatistics» и произвести оценку в соот ветствии со своими потребностями.

Листинг. Реализация «Funny Stairs»:

«MakePuzzle» extension point:

Random randomizer;

bool testResultIsGood = true;

Liststring alphabet = CharacterSet.Characters;

int iterationNumber = 0;

again:

if (alphabet != null){ randomizer = new Random();

int currentIndex = randomizer.Next(0, alphabet.Count - 1);

int stairsLength = randomizer.Next(4, 8);

string compLetter = "";

if (alphabet.Count currentIndex){ Competitor.Puzzle = new WordPuzzle();

compLetter = alphabet[currentIndex];

Competitor.Puzzle.CompulsoryCondition = compLetter;

Competitor.Puzzle.InitialCondition = stairsLength.ToString();

} Liststring words;

for (int i = 0;

i stairsLength;

i++){ words = HolderOfKnowledge.GetWordsByParams( i + 3, compLetter[0]);

if (words == null || words.Count == 0) testResultIsGood = false;

}} if (!testResultIsGood && iterationNumber 10){ iterationNumber++;

testResultIsGood = true;

goto again;

} «VerifyQuestionLogic» extension point:

QuestionVerificationResult result = QuestionVerificationResult.Correct;

if (question.Length Convert.ToInt32( gameManager.Umpire.Competitor.Puzzle.InitialCondition)) return QuestionVerificationResult.Incorrect;

for (int i = 0;

i question.Length;

i++){ if (question[i][0].ToString() != gameManager.Umpire.Competitor.Puzzle.CompulsoryCondition) return QuestionVerificationResult.Incorrect;

if ((i == 0) && question[0].Length 3) return QuestionVerificationResult.Incorrect;

if (i = 1){ if (question[i].Length - question[i - 1].Length != 1) return QuestionVerificationResult.Incorrect;

}} «GetAnswerLogic» extension point:

if (question.Length == Convert.ToInt32( gameManager.Umpire.Competitor.Puzzle.InitialCondition)) return GamePuzzleState.Completed;

Лингвистическая задача «Word Group»

Описание задачи. Алгоритм представлен (включая проверку на возможность решения составленной задачи) далее в листинге. Не обходимое условие – случайно выбранное слово из словаря. На чальное условие – длина этого слова, в контексте задачи – количе ство слов, которые необходимо составить. Длина составляемых игроком слов – произвольная. Главное требование (в соответствии с необходимым условием) – чтобы игрок на каждую букву задан ного слова составил по одному своему слову. Составление слов должно идти последовательно, от начальной буквы заданного сло ва до последней. Ещ один момент, на который необходимо об ратить внимание – логика каркаса не пропустит слов в вопросе игрока, которых нет в словаре каркаса. Чтобы каркас не отвергал слов, которые он не знает, необходимо перед началом игры доба вить в его базу знаний новые слова, которые будут действовать только на время процесса решения задачи. Делается это с по мощью метода «AddWord» класса «HolderOfKnowledge».

Листинг. Реализация «Word Group»:

«MakePuzzle» extension point:

Random randomizer = new Random();

bool testResultIsGood = true;

int iterationNumber = 0;

again:

Liststring dict = HolderOfKnowledge.Vocabulary;

if (dict != null){ randomizer = new Random();

int currentIndex = randomizer.Next(0, dict.Count - 1);

if (dict.Count currentIndex){ Competitor.Puzzle = new WordPuzzle();

string mainWord = dict[currentIndex];

Competitor.Puzzle.CompulsoryCondition = mainWord;

Competitor.Puzzle.InitialCondition = mainWord.Length.ToString();

} Liststring words = new Liststring();

int wordLength = Convert.ToInt32( Competitor.Puzzle.InitialCondition);

int count = wordLength;

for (int i = 0;

i count;

i++){ words = HolderOfKnowledge.GetWordsByParams( wordLength, Competitor.Puzzle.CompulsoryCondition[i]);

if (words == null || words.Count == 0) testResultIsGood = false;

}} if (!testResultIsGood && iterationNumber 10){ iterationNumber++;

testResultIsGood = true;

goto again;

} «VerifyQuestionLogic» extension point:

QuestionVerificationResult result = QuestionVerificationResult.Correct;

if (question.Length Convert.ToInt32( gameManager.Umpire.Competitor.Puzzle.InitialCondition)) return QuestionVerificationResult.Incorrect;

for (int i = 0;

i question.Length;

i++){ if (question[i][0] != gameManager.Umpire.Competitor.Puzzle.CompulsoryCondition[i]) return QuestionVerificationResult.Incorrect;

} «GetAnswerLogic» extension point:

if (question.Length == Convert.ToInt32( gameManager.Umpire.Competitor.Puzzle.InitialCondition)) return GamePuzzleState.Completed;

Лингвистическая задача «Word Square»

Описание задачи. Реализация алгоритма представлена далее в листинге. Отличие от предыдущего случая – длины всех составляе мых игроком слов должны быть одного размера.

Листинг. Реализация «Word Square»:

«MakePuzzle» extension point:

Random randomizer;

bool testResultIsGood = true;

int iterationNumber = 0;

again:

Liststring dict = HolderOfKnowledge.Vocabulary;

if (dict != null){ randomizer = new Random();

int currentIndex = randomizer.Next(0, dict.Count - 1);

if (dict.Count currentIndex){ Competitor.Puzzle = new WordPuzzle();

string mainWord = dict[currentIndex];

Competitor.Puzzle.CompulsoryCondition = mainWord;

Competitor.Puzzle.InitialCondition = mainWord.Length.ToString();

} Liststring words = new Liststring();

int wordLength = Convert.ToInt32( Competitor.Puzzle.InitialCondition);

int count = wordLength;

for (int i = 0;

i count;

i++){ words = HolderOfKnowledge.GetWordsByParams( wordLength, Competitor.Puzzle.CompulsoryCondition[i]);

if (words == null || words.Count == 0) testResultIsGood = false;

}} if (!testResultIsGood && iterationNumber 10){ iterationNumber++;

testResultIsGood = true;

goto again;

} «VerifyQuestionLogic» extension point:

QuestionVerificationResult result = QuestionVerificationResult.Correct;

if (question.Length Convert.ToInt32( gameManager.Umpire.Competitor.Puzzle.InitialCondition)) return QuestionVerificationResult.Incorrect;

int compLength = Convert.ToInt32( gameManager.Umpire.Competitor.Puzzle.InitialCondition);

for (int i = 0;

i question.Length;

i++){ if (question[i][0] != gameManager.Umpire.Competitor.Puzzle.CompulsoryCondition[i]) return QuestionVerificationResult.Incorrect;

if ((i = 1) && (question[i].Length != question[i - 1].Length) && (question[i].Length != compLength)) return QuestionVerificationResult.Incorrect;

} «GetAnswerLogic» extension point:

if (question.Length == Convert.ToInt32( gameManager.Umpire.Competitor.Puzzle.InitialCondition)) return GamePuzzleState.Completed;

4.4. Сравнение с имеющимися решениями Представленные в работе предметно-ориентированные проект ные решения – комплексная система, которая состоит из: описа ния проблемной и предметной областей, концептуальной и архи тектурной моделей.

Описание предметной области основано на общеизвестных и укрепившихся в сфере образования понятиях электронного обу чения и опирается на модели и схемы (в выборе терминологии), представленные в [44].

Проблемно-ориентированные компоненты представлены та кими подсистемами, как «Безопасность», «Управление пользова телями» и т.д.

С концептуальной точки зрения сравнение может быть про изведено с «Электронными образовательными ресурсами нового поколения» [159]. Здесь учебный материал представлен в форме электронного учебника, или правильнее было бы назвать – элек тронной статьи, которая помимо учебного материала содержит мультимедийные вставки, визуализирующие трудные для понима ния места. В сравнении с таким подходом, автор данной исследо вательской работы предлагает не визуализацию, а предоставле ние «словесного поля», в рамках которого можно описать изучае мую действительность. Вместо наблюдения за анимированной картиной, предлагается обыгрывание ситуации через игру со сло вами. В данной ситуации от преподавателя требуется проявить творческие способности в выборе типа лингвистической задачи и подбора материала.

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

Предлагаемый каркас, реализующий в программной форме эту схему, представлен научному сообществу впервые (в работах ав тора предлагаемой исследовательской работы [19;

20]), был про демонстрирован на различных конференциях и прошл проверку на новизну в фонде «Наука и Образование». Сравнение каркаса с имеющимися решениями (из [97]) в различных предметных облас тях представлено в табл. 4 (последний столбец характеризует предлагаемый каркас).

Табл. Сравнение предлагаемого каркаса с известными решениями Каркас для создания «IP Telephony программ «Insurance «Mobile Phone Название and Call ных компо Products» Applications»

проекта Processing» нентов лин гвистиче ских игр Интернет- Финансирование Клиентские Программ телефония и страхование модули про- ные компо Пред (специфика- (спецификация граммных ненты лин метная ция сервиса продуктов для средств гвистических область обработки вы- web-портала) предприятия игр зовов) Таблица приня- Модель на основе Схема про- Схема тия решений в знаний специали- ведения опе- взаимодей зависимости от стов в предметной раций в мо- ствия субъек Модель, условий области (система бильном тов и объек лежащая правил) цифровом тов в поша в основе устройстве говой лин гвистической игре Инструментальна поддержка (специально созданные инстру менты разработки и генерации) Присутствует Присутствует Присутствует Отсутствует Нотация Основа – мо- Конструкции языка Основа – Основа – дель потока используют нота- сервисы, словарь цию Meta-Object предостав- предметной Язык Facility (MOF) ляемые опе- области лин рационной гвистических системой те- игр лефона и элементы графического интерфейса Стратегия задания семантических правил Правила Правила встроены Правила Примеры встроены в ин- в инструменталь- встроены в использова струменталь- ные средства инструмен- ния языка с ные средства тальные выделением средства его семан тических особенно стей Техническая основа Стандартный Платформа, пре- Смартфоны Программ протокол уста- доставляющая по- компании No- ная библио новления се- ведение (база для kia, операци- тека карка анса SIP, кото- хранения специ- онная систе- са, для кото рый конфигу- фикаций и про- ма Symbian, рой нужно рируется инст- граммный анали- программный произвести рументальны- затор специфи- интерфейс детализа ми средства- каций), с которы- для доступа к цию. Детали ми языка ми работают ин- сервисам. зация произ струментальные Язык работает водится средства языка с программ- вручную но аппаратной частью через Каркас программный интерфейс Концептуальная основа Концепции для Концепции для Концепции: Концепции специфика- спецификации: текстовое со- для специ ции: передача страхование здо- общение, фицирова сигналов, пе- ровья, страховое заметка, ния: задача реключение, покрытие, возме- форма, головолом расположе- щение ущерба, браузер, … ка, условие, ние, … риски, … стратегия проверки, стратегия от вета, … Генерация ко- Генерация кода Генерация Автоматиза да (на языке (на языке Java) на программно- ция – шаб Java) на осно- основе метамо- го приложе- лон (Solution ве метамодели дели (описанной ния на языке Template для (описанной по по стандарту Python среды про спецификации MOF). Результат: граммиро XML Schema). 2000 – 4000 строк вания Visual Инстру- Результат: про- кода детализации Studio) для менты грамма классов предмет- предостав автома- (скрипт), кон- ной области ления точек тизации фигурирую- расширения щая оборудо- (трхступен вание чатая дета лизация кар каса). Язык шаблона – C# MetaEdit+ Java Metadata In- – Visual Studio Техноло terface (в перспек гия соз тиве – рас дания ширение про Microsoft Vi грамм sualization ного ре and Model шения ing Tools) Сокращение Сокращение дли- Сокращение Сокраще длительности тельности разра- длительности ние длитель разработки – в ботки – в 5 раз разработки ности раз 6 раз до 10 раз работки Процесс разра компонентов Улучшение ка- ботки стал легче и в 10 раз и Харак- чества специ- безопасней более * теристи- фикаций ки Сокрытие тех нических под робностей Проверка кор ректности * – десятикратное (и более) сокращение длительности разработки обуслав ливается тем, что размер каркаса – более чем в десять раз превышает раз мер детализирующего кода, а поскольку трудомкость детализации каркаса меньше, чем его создание – скорость разработки компонента увеличивается ещ в разы. Стоит помнить о том, что предлагаемое решение в виде каркаса – в десятки раз меньше представленных для сравнения решений. Цель срав нения – показать общие и отличительные черты в плане выбора основ, техноло гии, прикладного аспекта и реализации предметно-ориентированной архи тектуры язык-генератор-каркас.

4.5. Экономика повторного использования 4.5.1. Требования к качеству элементов повторного ис пользования В зависимости от особенностей функционирования повторно ис пользуемого компонента, могут меняться требования к конечному продукту. Тем самым качество конечного программного продукта не может быть выше качества повторно используемого компонен та (если не внести в последний соответствующие изменения, что потребует дополнительных затрат ресурсов) и зависит от него. Чем выше сложность компонента – тем сложнее его модификация и перенос на новую платформу (аппаратную, операционную или программную). Этим объясняется целесообразность использова ния унифицированных правил структуры и взаимодействия про граммных компонентов. Структурные правила являются фунда ментом для реализации первичных целей компонентов – обеспе чения, в заданных пределах, наджного и эффективного функ ционирования программных средств.

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

Представленные ниже характеристики качества для оценки критериев взяты из стандарта ISO/IEC 9126 «Software Engineering – Product Quality».

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

Корректность. На корректность оказывают влияние правила структурного построения, организация взаимодействия (по управ лению или по информации) и интерфейсов (концептуальная це лостность). Требования: возможность прослеживания реализации требований, степень и стратегия покрытия тестами функций и структуры.

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

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

Для обучающих программных средств, предоставляющих возможность проведения мероприятий по проверке знаний, целе сообразна функция шифрования содержимого файлов с зада чами. Для реализации этого требования, в проекте «CrossMaster»

шифруется содержимое файлов с заданием (выбранный алго ритм – DES: Data Encryption Standard, симметричный алгоритм шифрования, разработанный фирмой «IBM»). Для выработки клю ча шифрования используется специально разработанное для проекта программное средство. Сам ключ встраивается в компо нент, отвечающий за создание/генерацию задания. Таким обра зом, обеспечивается защита информации, но ограничивается со вместимость с другими системами и версиями обучающих про граммных средств (если использовать новый ключ шифрования).

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

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

Эффективность. Характеристики: временная эффектив ность (время отклика и обработки заданий), используемость ре сурсов (процессора, памяти, каналов ввода/вывода).

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

Каркас программных компонентов для повышения устойчи вости функционирования реализует определнную стратегию об работки исключительных ситуаций, предоставляющую разработчи ку программных средств (на основе компонентов, детализирую щих каркас) подсказку («Player must follow the special game rules» – сообщение о ситуации, когда игрок играет не по правилам). В данном случае каркас программных компонентов снимает свою ответственность за обработку некорректных действий (снижая ве роятность возможных негативных последствий в случае их предот вращений) и позволяет разработчику игрового программного средства самому принять решение по этому вопросу. Идея, ле жащая в основе такого подхода – каркас не может знать всех под робностей разрабатываемого на его основе игрового компонен та, для него, в рамках обязанности класса «GameRules», действует закон – либо правильно, либо не правильно, а разработчик про граммного средства уже решает сам – поощрить или наказать игрока.

Для обучающих программных средств в целом, требования к временной эффективности не так существенны. В рамках игрово го процесса возможна маскировка (специальные игровые эф фекты, визуализация событий) операций, требовательных к вре менным ресурсам. Исключение – случай, когда необходима бы страя реакция (ответ или ход) компьютера на действия игрока, требующая обращения к словарной базе. В этом случае, если размер базы невелик, не имеет смысла держать е в рамках сис темы обработки базы данных, а реализовать стратегию прямого доступа к содержимому. В проектах «CrossMaster» и «We Need Your Help», словарные базы невелики и не занимают много памяти (не более 100 Кб), поэтому информационные базы загружаются в оперативную память для повышения скорости обращения к ним.

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

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

Пригодность к сопровождению. Приспособленность к мо дификации (исправление, совершенствование, адаптация) и из менению.

Мобильность. Атрибуты: адаптация, инсталляция, замена компонентов.

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

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

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

Первоначальная идея разработки программных компонен тов предполагала их перенос на различные аппаратные плат формы. Для этого был проведн анализ предлагаемых альтерна тив. Выбор был сделан в пользу технологии «.NET Framework 2.0».

Объясняется это тем, что реализации платформы существуют не только для персональных компьютеров, но и игровых консолей (иг ровая приставка «Microsoft Xbox 360» использует технологию «XNA», работающую на базе «.NET Framework») и портативных устройств (под управлением «Windows Mobile» или «Windows Phone», где ис пользуется технология «.NET Compact Framework»). Упрощение пе ревода с одной реализации платформы на другую объясняется тем, что на каждую из них имеется документация, в которой со держится информация о поддержке, реализации и альтернативах определнных функций платформы.

Явное ограничение на мобильность присутствует в подсис теме «Безопасность», которая разработана для защиты приложе ния в рамках конкретной операционной системы и использует специфический механизм «Hook», обработки сообщений в сис теме «Windows» для перехвата и обработки сообщений от пользо вателя. Таким образом, для переноса данного компонента потре буется изучение особенностей целевой операционной системы.

Условия экономической эффективности применения комп о нентов Для повышения экономической эффективности использования по вторно используемых компонентов необходимы следующие усло вия:

1. Быстрый и лгкий поиск и приобретение компонентов (деле ние элементов по признаку узкой предметной области).

2. Удостоверение предсказуемости и наджности компонентов (апробация на практике).

3. Наличие лаконичной, но в то же время подробной документа ции на конструкцию и эксплуатацию.

Препятствия на пути использования готовых компонентов:

1. Недоступность исходного кода.

2. Недостаточность аргументации для использования компонен тов.

3. Сложность сопровождения библиотеки компонентов.

4.5.2. Оценка затрат на разработку программных средств на основе элементов повторного ис пользования Наиболее предпочтительный путь разработки обучающих про граммных средств на основе повторного использования – выбор и сборка готовых компонентов на конкретной платформе.

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

Задачи:

1. Сохранение инвестиций при возможных модификациях.

2. Упрощение, удешевление и сокращение процесса проекти рования и производства программного средства.

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

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

Для обучающего программного средства самым требова тельным к размеру, компонентом, является подсистема «Взаимо действие человек-машина». Это замечание справедливо для обу чающих программных средств, широко использующих звуковые и графические возможности вычислительных систем. Например, в проекте «We Need Your Help», на долю звукового и графического содержимого приходится около 97% от всей системы. Размер каркаса программных компонентов: приблизительно 20 Кб. Раз мер компонентов на основе каркаса: 6 – 7 Кб. Размер проекта «We Need Your Help» без учта графического и звукового содер жимого: около 246 Кб.

Реализация подсистемы «Безопасность» (как самого боль шого и сложного компонента) занимает примерно 500 Кб. Размер проекта «CrossMaster»: 1,5 Мб (из них – около 500 Кб на систему «Безопасность» и 500 Кб на информационное содержимое).

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

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

4.6. Выводы В четвртой главе были представлены результаты проведнных экс периментов, оценены характеристики проектных решений, прове дено сравнение с имеющимися решениями. Эксперименты про водились на базе авторских проектов «CrossMaster» и «We Need Your Help». Первый построен на основе концептуальной модели предметной области и развивается в е контексте, в документации активно используется язык предметной области, соответствующий концептуальной модели. Второй проект задействует архитектурную модель, активно пользуясь е языком для описания проекта и кар касом для создания компонентов поддержки игрового процесса.

Отдельно иллюстрируется эксплуатация проблемно ориентированного компонента, а именно подсистемы «Безопас ность». Код, представленный в описании подсистемы, функциони рует на втором, операционном уровне архитектуры приложения.


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

Далее даются примеры детализации каркаса и описание процесса задания логики работы компонентов на языке предмет ной области.

В самом конце приводится обобщение и описание харак теристик проектных решений.

В концептуальном плане представленные модели основаны на общеизвестных и укрепившихся в сфере образования понятиях электронного обучения и опирается на модели и схемы (в плане выбора терминологии), представленные в [44]. Предметно ориентированные компоненты представлены средствами (биб лиотеками) поддержки генерации кроссвордов и библиотекой каркаса программных компонентов. Библиотека кроссвордов представлена, как отдельный компонент, который может использо ваться в различных проектах, она может использоваться для пре доставления сервисов компонентам третьего уровня (предметной области) архитектуры. Поскольку библиотека генерации кросс ворда в научном плане не предоставляет интерес в рамках ис следования, то подробной информации о ней и не приводится, тем не менее, отмечается, что она была создана для реализации элемента «Создатель задач» концептуальной модели (подсистема «Обучение»).

Среди качественных характеристик предложенных проект ных решений можно выделить:

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

2. Функциональная полнота проблемно-ориентированных ком понентов. Подсистема «Безопасность», созданная для проекта «CrossMaster», предполагает сво использование в аналогичных обучающих программных средствах и реализует, в пределах заданной наджности, требуемую функциональность. В слу чае с предметно-ориентированными компонентами, эффек тивность функциональной полноты определяется упаковкой реализации требований для определнного класса задач в каркасе и возможностью их расширения.

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

4. Для обучающих программных средств, предоставляющих воз можность проведения мероприятий по проверке знаний, це лесообразна функция шифрования содержимого файлов с задачами. Для реализации этого требования, в проекте «CrossMaster» шифруется содержимое файлов с заданием.

Обеспечивается защита информации.

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

6. Компоненты, реализованные для проекта «CrossMaster», прохо дили испытания в реальных условиях, в рамках проведения учебных занятий (проверка завершнности). Реализованная подсистема «Безопасность» для восстановления работоспо собности вычислительной системы после сбоя содержит спе циальный инструмент, который восстанавливает работоспо собность системы.

7. Каркас программных компонентов для повышения устойчиво сти функционирования реализует определнную стратегию обработки исключительных ситуаций, предоставляющую раз работчику программных средств (на основе компонентов, де тализирующих каркас) подсказку («Player must follow the special game rules» – сообщение о ситуации, когда игрок игра ет не по правилам). В данном случае каркас программных компонентов снимает свою ответственность за обработку не корректных действий (снижая вероятность возможных негатив ных последствий в случае их предотвращения) и позволяет разработчику игрового программного средства самому при нять решение по этому вопросу. Идея, лежащая в основе тако го подхода – каркас не может знать всех подробностей раз рабатываемого на его основе игрового компонента, для него, в рамках обязанности класса «GameRules», действует закон – либо правильно, либо не правильно, а разработчик про граммного средства уже решает сам – поощрить или нака зать игрока.

8. Для обучающих программных средств в целом, требования к временной эффективности не так существенны. В рамках иг рового процесса возможна маскировка (специальные игро вые эффекты, визуализация событий) операций, требователь ных к временным ресурсам. Исключение – случай, когда не обходима быстрая реакция (ответ или ход) компьютера на действия игрока, требующая обращения к словарной базе. В этом случае, если размер базы невелик, не имеет смысла держать е в рамках системы обработки базы данных, а реа лизовать стратегию прямого доступа к содержимому. В проек тах «CrossMaster» и «We Need Your Help», словарные базы неве лики и не занимают много памяти (не более 100 Кб), поэтому информационные базы загружаются в оперативную память для повышения скорости обращения к ним.

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

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

11. Конструкция каркаса предполагает его расширение в случае необходимости. Для этого введн класс «GameManager», от деляющий концептуальную область каркаса от возможных расширений (посредством механизма наследования). Таким образом, самый лгкий способ адаптации каркаса под новые нужды – просто расширить его, не изменяя саму библиотеку.

12. Первоначальная идея разработки программных компонентов предполагала их перенос на различные аппаратные плат формы. Для этого был проведн анализ предлагаемых аль тернатив. Выбор был сделан в пользу технологии «.NET Framework 2.0». Реализации этой платформы существуют не только для персональных компьютеров, но и игровых консолей и портативных устройств.

Оценка затрат на разработку программных средств на ос нове элементов повторного использования делает акцент на раз мер активов и кратность их возможного применения. Что касается размера, то предметно-ориентированная программная состав ляющая составляет малую долю от всего проекта, и при переносе программного средства на другую платформу основные затраты необходимо рассчитывать на перенос и модификацию инфор мационного, графического и звукового содержимого. По кратно сти возможного применения можно сказать, что чем больше ис пользуется и сопровождается компонент в разных системах – тем более наджным и проверенным он становится, способствует бо лее тщательному процессу прогнозирования затрат на разработ ку на его основе. Однако чем больше создано вариантов одного компонента, тем труднее производить их сопровождение. В случае с каркасом программных компонентов для улучшения характери стик компонентов, разработанных на его основе, все изменения можно вносить в сам каркас, не трогая компонентов, реализован ных на его основе. В таком случае, чем больше сопровождаемых компонентов – тем меньше затрат на их улучшение.

ЗАКЛЮЧЕНИЕ В рамках предлагаемого исследования была построена основа для программных проектов, оформленная в виде, рентабельном и эффективном для е многократного использования разработчи ками обучающих программных средств на базе вопрос ответных лингвистических игр. Эта основа представлена архитектурной средой, соответствующей своей архитектурной модели, которая в свою очередь детализирует концептуальную модель предметной области и действует в е границах.

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

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

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


В результате полученные проектные решения обладают сле дующими преимуществами:

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

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

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

Вс это говорит о том, что принятые проектные решения учитывают текущее состояние развития программной инженерии и соответ ствуют современным требованиям.

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

Далее приводится описание (в виде вопросов и ответов) производимых автором дальнейших разработок по созданию производственных решений (на основе предметно-ориентирован ных проектных решений) в виде фабрик разработки программно го обеспечения.

Вопрос №1. Кто будет использовать фабрику разработки программного обеспечения, а кто потреблять продукты, вырабо танные ею?

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

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

Вопрос №2. Каковы необходимые знания разработчиков, ис пользующих фабрику?

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

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

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

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

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

Схема это также шаблон для описания продуктов фабрики. Ме тафора: схема – рецепт, точки зрения – ингредиенты (а также ин струменты и процессы приготовления).

Вопрос №3. Каковы существенные составляющие схемы фабрики разработки в общих чертах?

Ответ. Первая категория составляющих – требования. Спи сок функциональных требований весьма широк. Делится на кате гории систем, из которых состоит обучающее программное средство, получаемое с помощью фабрик разработки. Есть тре бования к функциональности следующих систем: управления пользователями, обучения, обслуживания, взаимодействия человек машина, безопасности, коммуникации, учебного материала. В рамках перечисленных систем происходят определнные про цессы, которые можно конфигурировать. Нефункциональные требования представлены следующими требованиями. Первая группа – требования к удобству, решают вопросы того, насколько быстро обучаемые могут освоить систему, эффективно ли орга низована система взаимодействия с системой, не препятствуют ли определнные элементы организации интерфейса продуктивной работе, и т.д. Вторая группа – требования к наджности систем.

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

Четвртая группа – требования к возможности сопровождения, включают в себя требования к лгкости исправления дефектов, модификации, замены, переносимости на другие платформы.

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

Третья категория – исполняемые артефакты разработки.

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

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

Вопрос №4. Из каких инструментов состоит шаблон фабри ки?

Ответ. Далее перечисляются инструменты и их описание.

Предметно-ориентированный язык и инструменты его поддержки.

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

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

Упакованные вместе, эти активы могут использоваться для разработки продуктов в интегрированной среде разработки.

Шаблон, также как и схему, необходимо сконфигурировать пе ред использованием.

Публикации по теме исследования Основные результаты научного исследования представлены в сле дующих работах:

1. В изданиях из перечня, рекомендуемого ВАК (от 17.06.2011):

[15] («Открытое образование»);

[19] («Прикладная информати ка»);

[21] («Вестник Омского университета»);

[22] («Программ ная инженерия»).

2. В рецензируемых научно-периодических изданиях: [13;

20;

24] («Математические структуры и моделирование»);

[14] («Ин форматика и образование» (журнал, рекомендованный ВАК на время публикации в нм статьи)).

3. В материалах конференций: [1;

7–12;

16–18;

23] (конференции – «Наука. Технологии. Инновации» (Новосибирск, 2007 год), «Но вые технологии и информатизация современного общества»

(Омск, 2008 год), «Технологии Microsoft в теории и практике программирования» (Нижний Новгород, 2010 год), «Объектные системы» (Ростов-на-Дону, 2011 год) и т.д.).

Программные разработки и проекты зарегистрированы в следующих организациях:

1. Объединнный фонд электронных ресурсов «Наука и обра зование» (прежнее название – «Отраслевой фонд алгоритмов и программ»): [29–31;

33–34;

37–38].

2. Федеральное государственное бюджетное учреждение «Фе деральный институт промышленной собственности» (ранее известное, как «Федеральная служба по интеллектуальной собственности, патентам и товарным знакам»): [32, 35–36].

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ Публикации в печатных изданиях Статьи, материалы конференций, описания результатов реги страции разработок программных средств 1. Гусс С.В., Ефимов С.С. Игровые программы лингвистической направленности как средство расширения словарного запа са студента // Инновационные технологии в повышении каче ства образования. Материалы международной научно практической конференции, 15 апреля 2006 г. Часть II. Омск:

Изд-во ОмЭИ, 2006. С. 108–110.

2. Гусс С.В., Ефимов С.С. Игровая программа «Знатоки» // Инно вации в науке и образовании. Телеграф отраслевого фонда алгоритмов и программ. № 6 (17). М: Изд-во ФГНУ, 2006. С. 18.

3. Гусс С.В., Ефимов С.С. Генератор кроссвордов «CrossMaster» // Инновации в науке и образовании. Телеграф отраслевого фонда алгоритмов и программ. № 4 (27). М: Изд-во ФГНУ, 2007.

С. 23.

4. Гусс С.В., Ефимов С.С. Венгерский кроссворд «Филворд» // Инновации в науке и образовании. Телеграф отраслевого фонда алгоритмов и программ. № 5 (28). М: Изд-во ФГНУ, 2007.

С. 31–32.

5. Гусс С.В., Ефимов С.С. Компьютерная лингвистическая игра «Наборщик» // Инновации в науке и образовании. Телеграф отраслевого фонда алгоритмов и программ. № 10 (33). М: Изд во ФГНУ, 2007. С. 14.

6. Гусс С.В., Ефимов С.С. Компьютерная игра лингвистической направленности «Чайнворд» // Инновации в науке и образова нии. Телеграф отраслевого фонда алгоритмов и программ.

№ 10 (33). М: Изд-во ФГНУ, 2007. С. 30.

7. Гусс С.В. Компьютерные игры лингвистической направленно сти // Наука. Технологии. Инновации. Материалы всероссий ской научной конференции молодых ученых. Новосибирск:

Изд-во НГТУ, 2007. Ч.1. С. 172–176.

8. Гусс С.В. Электронные лингвистические игры // Студент и науч но-технический прогресс. Материалы ХLVI Международной научной студенческой конференции. Новосибирск: Изд-во НГУ, 2008. С. 99.

9. Гусс С.В., Комаров В.А. Компьютерные игровые программы в современном мире // Новые технологии и информатизация современного общества: материалы международной научно практической конференции молодых учных. Ч.2. Омск: Изд-во АНО ВПО «Омский экономический институт», 2008. С.26–29.

10. Гусс С.В. Лингвистические компьютерные игры как инструмент самообразования и контроля знаний // Новые технологии и информатизация современного общества: материалы меж дународной научно-практической конференции молодых уч ных. Ч.2. Омск: Изд-во АНО ВПО «Омский экономический ин ститут», 2008. С.30–33.

11. Гусс С.В. Компьютерные лингвистические игры // Молодежь третьего тысячелетия: XXXII региональная научно-практическая конференция: тезисы докладов Омский государственный уни верситет им. Ф. М. Достоевского, 2008. С. 148–151.

12. Гусс С.В. Развивающие компьютерные средства обучения на основе занимательных головоломок // Студент и научно технический прогресс. Материалы ХLVII Международной науч ной студенческой конференции. Новосибирск: Изд-во НГУ, 2009. С. 89.

13. Гусс С.В. Элементы повторного использования для программ ных систем учебного назначения. Концептуальное проектиро вание и анализ // Математические структуры и моделирова ние. 2009. № 20. С. 78–92.

14. Гусс С.В. Обучающие программы на основе игр лингвистиче ской направленности // Информатика и образование. 2009.

№ 11. С. 123–124.

15. Гусс С.В. Использование компьютерных лингвистических игр в процессе обучения // Открытое образование. 2010. № 1. С. 18– 29.

16. Гусс С.В. Применение шаблонов проектирования в разработ ке игровых программ лингвистической направленности // Ма териалы II межвузовской научно-практической конференции ОмГТУ. Омск: Изд-во ОмГТУ, 2010. С.163–165.

17. Гусс С.В. Каркас программных компонентов поддержки заня тий лингвистической направленности в игровой форме // Сту дент и научно-технический прогресс. Материалы ХLVIII Между народной научной конференции. Новосибирск: Изд-во НГУ, 2010. С. 206.

18. Гусс С.В. Фабрика разработки игровых лингвистических про граммных систем учебного назначения // Технологии Microsoft в теории и практике программирования. Материалы конфе ренции [под ред. проф. В.П. Гергеля]. Нижний Новгород: Изд-во Нижегородского госуниверситета, 2010. С. 110–112.

19. Гусс С.В. Модель каркаса программных компонентов под держки занятий лингвистической направленности в игровой форме // Прикладная информатика. 2010. № 3 (27). С. 62–77.

20. Гусс С.В. Высокоуровневая модель семейства программных компонентов для поддержки занятий в игровой форме // Ма тематические структуры и моделирование. 2010. № 21. С. 44– 54.

21. Гусс С.В. Проблема повторного использования в разработке семейства игровых программных систем учебного назначения // Вестник Омского университета. 2010. №4. С. 147–149.

22. Гусс С.В. Пакет вспомогательных средств для построения се мейства программных систем в определнной предметной области // Программная инженерия. 2011. №1. С. 25–33.

23. Гусс С.В. Объектно-ориентированный каркас для предметной области игрового электронного обучения на основе разви вающих «вопрос-ответных» лингвистических задач // Объектные системы – 2011. Материалы III Международной научно практической конференции [gод ред. П.П. Олейника]. Ростов на-Дону, 10–12 мая 2011 г. С. 46–52.

24. Гусс С.В. Язык детализации каркаса программных компонен тов поддержки занятий лингвистической направленности // Ма тематические структуры и моделирование. 2011. № 23. С. 58– 75.

25. Коротеева О.С., Хорева Л.В. Новые образовательные техноло гии в информационном пространстве // Образовательные технологии. 2008. №2. С. 64.

26. Нужнов Е.В. Возможности оценки качества взаимодействия «преподаватель – обучаемый» в образовательном учреждении // Перспективные информационные технологии и интеллекту альные системы. 2005. №3. С. 52–55.

27. Сибирцева Г.А., Самарина Н.Н. Вопросы качества профес сионального образования по заочной форме обучения // Об разовательные технологии. 2008. №2. С.111.

28. Яковлев А.И. Информационно-коммуникационные технологии в образовании // Информационное общество. 2001. № 2. С.

32–37.

Свидетельства о регистрации разработок программных средств 29. Свидетельство об отраслевой регистрации разработки ОФАП Федерального агентства по образованию РФ № 6375. Игровая программа «Знатоки 1.0» / Гусс С.В., Ефимов С.С. (Российская Федерация);

организация-разработчик: ГОУ ВПО Омский госу дарственный университет им. Ф.М. Достоевского;

дата регист рации: 16.06.2006.

30. Свидетельство об отраслевой регистрации разработки ОФАП Федерального агентства по образованию РФ № 8123. Генера тор кроссвордов CrossMaster 1.0 / Гусс С.В., Ефимов С.С. (Рос сийская Федерация);

организация-разработчик: ГОУ ВПО Ом ский государственный университет им. Ф.М. Достоевского;

да та регистрации: 12.04.2007.

31. Свидетельство об отраслевой регистрации разработки ОФАП Федерального агентства по образованию РФ № 8378. Венгер ский кроссворд «Филворд 1.0» / Гусс С.В., Ефимов С.С. (Рос сийская Федерация);

организация-разработчик: ГОУ ВПО Ом ский государственный университет им. Ф.М. Достоевского;

да та регистрации: 24.05.2007.

32. Свидетельство об официальной регистрации программы для ЭВМ № 2007614242 «Филворд» / Гусс С.В., Ефимов С.С. (Рос сийская Федерация);

правообладатель: ГОУ ВПО Омский го сударственный университет им. Ф.М. Достоевского;

заявка № 2007612389;

дата поступления: 13.06.2007;

дата регистрации:

5.10.2007.

33. Свидетельство об отраслевой регистрации разработки ОФАП Федерального агентства по образованию РФ № 9274. Компью терная лингвистическая игра «Наборщик 1.0» / Гусс С.В., Ефи мов С.С. (Российская Федерация);

организация-разработчик:

ГОУ ВПО Омский государственный университет им. Ф.М. Дос тоевского;

дата регистрации: 05.10.2007.

34. Свидетельство об отраслевой регистрации разработки ОФАП Федерального агентства по образованию РФ № 9343. Компью терная игра лингвистической направленности «Чайнворд» / Гусс С.В., Ефимов С.С. (Российская Федерация);

организация разработчик: ГОУ ВПО Омский государственный университет им. Ф.М. Достоевского;

дата регистрации: 24.10.2007.

35. Свидетельство об официальной регистрации программы для ЭВМ № 2008613091 «Конструктор кроссвордов» / Гусс С.В., Ефимов С.С. (Российская Федерация);

правообладатель: ГОУ ВПО Омский государственный университет им. Ф.М. Достоев ского;



Pages:     | 1 | 2 || 4 |
 



Похожие работы:





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.