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

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

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


Pages:     | 1 || 3 | 4 |

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

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

104], возможно наличие инструментов для ра боты с моделями в определнной программной среде раз работки.

2. Шаблоны (анализа, архитектурные, проектирования и т.д.) [42;

50].

3. Предметно-ориентированные языки [53;

84;

87;

103].

4. Компоненты [101;

105;

111;

113;

115].

5. Рекомендации, макросы и скрипты [53;

98] для автоматизации определнных частей процесса разработки программного обеспечения.

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

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

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

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

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

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

Первый класс – работы, описывающие идеи для создания методов разработки программного обеспечения, второй класс – работы, предлагающие непосредственно методы разработки, на основе идей первого класса и их практическое применение. В качестве примера первого класса, можно привести [104], в качестве при мера второго класса – [58]. В работе [104] излагается так назы ваемая теория предметной области (Domain Theory) для разработ ки программного обеспечения, а в работе [58] – применение примов различных парадигм разработки, в том числе связанных с теорией предметной области, на практике.

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

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

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

Семейства программных средств и линейки программных про дуктов Характерной особенностью семейства программных средств яв ляется наличие обобщнной архитектуры, описывающей вс мно жество членов конкретного семейства;

при этом указываются так называемые точки изменчивости (расширения), т.е. те места, в ко торых имеют место различия между членами семейства [114].

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

сюда также относятся требования к бюджету и планиро ванию [96;

116].

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

Решение задачи № 1 «Анализ конъюнктуры в области разра ботки обучающих программных средств» привело к следующим выводам:

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

2. В корпоративном секторе затраты на электронное обучение, в том числе и обучающие программные средства, составляют в среднем 12% от бюджета компании. Здесь рынок в опреде лнной степени сформирован, имеются свои производители.

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

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

5. Препятствия для распространения электронного обучения в академическом секторе: непонимание реальной цены про дукта и его разработки;

проблема финансирования;

выбор организации, которая будет заниматься разработкой;

затраты на эксплуатацию и сопровождение готового продукта.

6. В перспективе – политические заказы на игровые решения.

Предполагаемые исполнители заказов – отечественные раз работчики.

7. Серьзные игры имеют государственную поддержку в развитых странах (Германии, Франции, Англии, Соединнных Штатах Америки и т.д.). Их опыт говорит о том, что на разработку таких программных средств оказывают влияние следующие факто ры: бюджет, время разработки, инструменты разработки, рис ки, предсказуемость успеха игры у целевой аудитории.

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

9. На рынке есть спрос на авторские средства для разработки курсов неспециалистами. Требования – возможность менять содержимое и самим разрабатывать учебные курсы.

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

Решение задачи №2 «Обзор принципов и подходов к созда нию программного обеспечения, предоставляющих возможность накопления и повторного использования полученных в прошлом знаний и опыта» привело к следующим выводам:

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

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

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

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

5. Требования, предъявляемые заинтересованными в повторном использовании лицами к программным компонентам: дос тупность, понятность, возможность сопровождения, документи рованность, степень сложности компонентной интеграции.

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

Решение задачи № 3 «Выбор подходов, их адаптация и обос нование целесообразности и рентабельности их применения для разработки программного обеспечения в предметной области обучающих программных средств» привело к следующим выво дам:

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

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

3. Каркас – сосредоточение экспертных знаний. Язык – средство управления экспертными знаниями. Каркас и язык инкапсули руют знания об архитектурных правилах построения приложе ний и модели программирования.

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

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

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

ГЛАВА 2. КОНЦЕПТУАЛЬНОЕ МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ Разработчики программного обеспечения создают модели для описания определнного аспекта действительности и выражения идей. Модели представляют собой упрощнную интерпретацию реальности, из которой извлекаются существенные аспекты, а лишние детали, не имеющие отношения к решаемым задачам, игнорируются.

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

Модель предметной области представляет собой тщательно отобранный и сознательно упрощнный набор знаний в форме, способствующей дальнейшему развитию этих знаний и сбору до полнительной информации.

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

Модель осуществляет передачу информации посредством схем, диаграмм, программного кода или человеческого языка. В рамках проекта модель может играть одну из трх ролей [86]: а) модель и архитектура артефакта (продукта проекта) взаимно оп ределяют друг друга;

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

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

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

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

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

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

Типичные требования, предъявляемые к обучающим программным средствам:

1. Способность решать педагогические задачи.

2. Наличие материала по определнным учебным дисциплинам.

Главные элементы систем обучающих программных средств:

1. Графическая оболочка.

2. Содержание (текстовые, аудиовизуальные и другие ресурсы).

3. Система управления содержанием.

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

1. Преподаватель.

2. Обучающийся.

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

Попытки ответить на основные вопросы [75], возникающие на ста дии концептуального проектирования, дают следующее:

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

2. Какую задачу решают обучающие программные средства?

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

3. Где планируется использовать обучающие программные средства (имеется в виду тип оборудования и коммуникации)?

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

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

2.1.1. Решаемые педагогические задачи Основные педагогические задачи, решаемые с помощью обу чающих программных средств [44] (рис. 1):

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

2. Подготовка по различным разделам дисциплины с опреде лнным уровнем глубины и детализации.

3. Развитие способностей к специфичным видам деятельности.

4. Восстановление знаний и умений, приобретнных в прошлом.

5. Контроль успеваемости, проведение тестов. Можно выделить следующие виды контроля (названия видов взяты из [25]):

входной: для определения уровня знаний перед изучением дисциплины;

текущий: для определения количества усвоенной инфор мации после ознакомления с отдельными разделами кон кретной дисциплины;

промежуточный: определяет качество усвоения отдельного раздела;

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

проверка остаточных знаний.

2.1.2. Эксплуатация обучающих программных средств Обязанности системного администратора при работе с обучаю щим программным средством (рис. 2):

Рис. 2. Обязанности системного администратора в рамках обу чающего программного средства 1. Настройка, конфигурирование системы.

2. Проверка функциональности.

Типичные случаи взаимодействия преподавателя с обучающим программным средством (рис. 3):

1. Создание заданий: составление и регистрация в системе.

2. Настройка системы: назначение заданий обучающимся и от крытие доступа к учебному материалу и заданиям.

3. Анализ работы обучающихся: просмотр протокола работы обучающихся (результаты выполнения заданий, затраты вре мени на изучение и проверку знаний, действия, совершнные за период общения с системой), просмотр моделей обу чающихся, т.е. результатов интеллектуальной работы системы, а именно выводов, сделанных из протоколов работы обучаю щихся [44].

Рис. 3. Типичные случаи взаимодействия преподавателя с обучаю щим программным средством Если преподаватель не является живым человеком, а пред ставляет собой систему, внешнюю по отношению к рассматри ваемой, или является е частью, ответственной за работу с учеб ным материалом и заданиями, то обучающее программное средство может предоставлять возможности по самообразова нию. Это является весьма полезным дополнением к обучающему программному средству [27;

44].

2.2. Статическая модель обучающего средства Типичные подсистемы обучающих программных средств [44]:

1. Обучение.

2. Учебный материал.

3. Управление пользователями.

4. Обслуживание.

5. Безопасность.

6. Коммуникации.

7. Взаимодействие человек-машина.

Возможные подсистемы:

1. Интеллект.

2. Психофизиологическое сопровождение.

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

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

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

На рис. 4 представлена обобщнная структура обучающих программных средств.

2.2.1. Подсистема «Обучение»

Элементы подсистемы (рис. 5):

Рис. 4. Обобщнная структура обучающих программных средств 1. Задача. Способствование практической деятельности обу чающегося. Состоит из следующих элементов. Тема. Название раздела дисциплины, по которой выдатся задача. Условие.

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

Степень сложности задачи: уровень сложности;

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

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

3. Тестовая единица. Минимальная составляющая теста, имею щая отношение к теме теста. Состоит из следующих элемен тов. Вопрос. То на что нужно дать ответ. Варианты ответа. Воз можные варианты ответов. Стоимость ответа. Цена ответа:

насколько оценивается ответ.

4. Создатель задач. Элемент позволяющий составлять или гене рировать задачу, предполагает различные типы составителей задач и включает следующих кандидатов. Человек. Задачи соз даются вручную, благодаря интеллектуальным усилиям препо давателя. Компьютер. Задачу генерирует компьютер. Человек – Компьютер. Человек с помощью специальной программы для компьютера составляет задачу.

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

6. Решение задачи. То, как обучающийся решил задачу. Содер жит следующие элементы. Ход решения. Последовательность действий решения задачи. Ответ. Ответ полученный обучаю щимся.

Рис. 5. Подсистема «Обучение»

7. Временной отчт. Отчт о затраченном на работу времени.

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

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

9. Оценка. Оценивание результата работы обучающегося. Оце нивание может вестись по определнной шкале. Шкала оцен ки (взята из [26]), типы представлены далее. Пятибалльная.

Оценки в измерении от 1 до 5. Децимальная. Оценки от 1 до 10. Стобалльная. Оценки от 1 до 100.

10. Программа учебного курса. Устанавливает соответствие меж ду задачами и процессом обучения.

11. Процесс обучения (Занятие). Ход обучения. Характеризуется следующим. Сценарий обучения. План проведения мероприя тия, связанного с обучением. Виды следующие. Жсткий. Стро го задан. Гибкий. Приспособлен к переходам в плане. Пред ставление обучения. То, как проходит обучение. Виды пред ставлены далее. Игровая форма. В игровой форме. Привле каются игровые технологии. Традиционная форма. Характер ная форма проведения обучения для целевой среды. Ориен тация обучения. Направленность на количественную и качест венную сторону обучения. Виды следующие. Самостоятельная.

Предполагает самостоятельную работу обучающегося. Груп повая. Предполагается работа в группе обучающихся. С уча стием преподавателя. Предполагает работу преподавателя с одним или группой обучающихся.

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

13. Мониторинг. Отвечает за наблюдение над работой обучающе гося.

14. Консультирование. Оказание помощи обучающемуся в за труднительных вопросах.

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

16. Контроль за обучающимся. Осуществление контроля за обу чающимся. Включает следующие элементы. Тип контроля. Ви ды контроля соответствуют описанным выше, в разделе «Ре шаемые педагогические задачи».

17. Контролер времени. Таймер, фиксирующий и ограничиваю щий время работы обучающегося.

2.2.2. Подсистема «Управление пользователями»

Элементы подсистемы (рис. 6):

1. Регистратор пользователя. Производит регистрацию пользова теля в системе.

2. Пользователь. Тот, кто регистрируется с помощью регистрато ра.

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

Преподаватель. Тот, кто производит обучение обучающегося.

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

Рис. 6. Подсистема «Управление пользователями»

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

5. Идентификационные данные. Фамилия. Имя. Отчество. До полнительная информация (представляет собой отдельный элемент, который может содержать адрес пользователя, те лефон и прочую подобную информацию).

Задачи:

1. Регистрация пользователей в системе.

2. Составление профилей пользователей.

3. Ведение статистики пользования системой.

2.2.3. Подсистема «Учебный материал»

Область ответственности:

1. Содержание материала по предусмотренным дисциплинам.

2. Словарь терминов.

Функции (рис. 7): внесение, хранение, извлечение нужной информации с возможностью е фильтрации по различным при знакам. Может содержать информацию описательного и иллюст ративного характера. Возможно содержание учебных задач, сге нерированных системой или составленных преподавателем.

2.2.4. Подсистема «Безопасность»

Область ответственности (рис. 8):

1. Аутентификация (проверка соответствия пользователя учтной записи).

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

3. Целостность (для того, чтобы быть уверенным в том, что опре делнные части системы не подменены и не модифицирова ны злоумышленником).

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

Рис. 7. Подсистема «Учебный материал»

Рис. 8. Подсистема «Безопасность»

2.2.5. Подсистема «Коммуникации»

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

Элементы подсистемы (рис. 9):

1. Коммуникация. Осуществляет взаимодействие пользователей.

Типы взаимодействия пользователей представлены далее.

Преподаватель – обучаемый. Предполагает работу препода вателя с обучаемым или с группой обучаемых. Обучаемый – обучаемый. Предполагает работу обучающихся друг с дру гом.

2. Автономная система. Локальный компьютер пользователя.

3. Сеть. Совокупность компьютерных систем.

4. Локальная сеть. Объединение компьютеров в пределах пред приятия, организации, учреждения.

5. Глобальная сеть. Объединение компьютеров по всему миру.

Рис. 9. Подсистема «Коммуникации»

2.2.6. Подсистема «Обслуживание»

Функции (рис. 10):

1. Логирование. Фиксирование событий происходящих в систе ме.

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

3. История работы системы. История работы системы, необхо димая системному администратору.

Рис. 10. Подсистема «Обслуживание»

2.2.7. Подсистема «Взаимодействие человек-машина»

Обеспечивает коммуникацию пользователя с системой.

2.2.8. Подсистема «Интеллект»

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

2.2.9. Подсистема «Психофизиологическое сопровож дение»

Функции:

1. Проверка психофизиологических особенностей обучающего ся.

2. Проверка профессиональной пригодности.

3. Учт психофизиологических качеств, в процессе обучения.

2.3. Выводы Как и отмечалось во введении, в главе представлена модель предметной области для описания определнного аспекта дейст вительности и выражения идей. В данном конкретном случае ас пектом действительности является электронное игровое обучение, а выраженные в модели идеи базируются на восприятии автором предлагаемой исследовательской работы реальной ситуации в сфере обучения и опорой на имеющиеся исследования в этой области, в частности [25;

26;

27;

44].

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

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

Было выделено семь основных подсистем: «Обучение», «Учебный материал», «Управление пользователями», «Обслужива ние», «Безопасность», «Коммуникации», «Взаимодействие человек машина».

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

ГЛАВА 3. КАРКАС ПРОГРАММНЫХ КОМПОНЕНТОВ Привязка программного кода к модели, лежащей в основе сис темы, придат коду смысл, а модель приобретает практическую ценность. Преимущества модели: переработка знаний, коммуни кация в группе. Аналитическая концептуальная модель (представ ленная в предыдущей главе) – результат анализа и систематиза ции прикладной предметной области. Аналитическая модель не учитывает той роли, которую модель играет в программной сис теме. Это средство для понимания и знакомства с предметной областью. Настоятельно советуется не примешивать к ней вопросы реализации, внося тем самым путаницу [86]. После того, как раз работана аналитическая модель, разрабатывается архитектурная модель, имеющая отдалнное сходство с концептуальной моде лью.

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

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

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

3.1. Место каркаса программных компонентов в классификации элементов повторного использо вания Элементы повторного использования можно классифицировать по нескольким признакам:

1. По уровню представления. Модели. Представляют собой вы сокоуровневое описание структуры и поведения. Набор кода.

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

2. По специфике повторно используемого элемента. Класси фикация похожа на ту, что приведена в [75]. Только в представ ленной ниже классификации не фигурирует такой элемент, как модель, т.к. она не подходит под данный признак деления, в связи, с чем этот элемент был отнесн к другой группе. Функ циональные библиотеки (набор подпрограмм под специфи ческие нужды). В отличие от каркасов, здесь повторно исполь зуются функции, а написание тела приложения, в котором бу дут использованы эти функции, остатся задачей разработчи ка. Образцы, соответствуют следующим этапам разработки.

Анализа [93]: применимы для анализа предметной области приложения. Архитектурные [42], [94] для упорядочивания и структурирования компонентов системы. Проектирования [50]:

для применения опыта, накопленного и обобщнного другими разработчиками в виде особых проектных решений. Реализа ции [45]: для обслуживания задач ежедневного программиро вания, а также для придания программному коду читабельного вида и внесения в него большей ясности. Каркасы. Более спе циализированны, чем образцы. Важно отметить, что приложе ние может разрабатываться на основе нескольких каркасов.

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

3. По этапу разработки (элементы могут быть представлены мо делями, набором кода, в виде исполняемых модулей, а также в виде текстового описания). Предметной области. Обычно это высокоуровневое описание характеристик определнной предметной области в виде диаграмм. Сбора и анализа тре бований. Могут быть представлены таблицами сопоставления предложений предметной области возможным предложениям со стороны заинтересованных в разрабатываемом проекте лиц. Архитектуры. Чтобы архитектура могла быть многократно используемой, крайне необходимо отделить е от реализа ции, а на основании [42] ещ и от алгоритмов и представления данных. Поэтому чаще всего используется высокоуровневое представление такой структуры проекта, которая могла бы удовлетворить требованиям заказчика и поддерживала воз можность изменений в пределах заданной предметной об ласти. Проекта. Это могут быть описания проектных решений, рекомендаций по реализации, а также готовые компоненты, требующие сборки и конфигурирования. Сюда также входят схемы-шаблоны проектных документов и документация на го товые программные библиотеки компонентов. Реализации.

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

3.2. Проблема разработки каркаса Каркас – это «набор взаимодействующих классов, составляющих повторно используемый дизайн для конкретного класса про грамм» [50]. Конкретный класс программ – это не что иное, как семейство программных средств, описанное в [114].

Свойства, навязываемые проекту каркасом [50]:

1. Определнная архитектура.

2. Структура классов и объектов.

3. Основная функциональность, описанная в классах.

4. Методы взаимодействия между объектами.

5. Потоки управления.

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

Одна из проблем дизайна любого типа программного обеспечения заключается в том, что как отмечается в [50] дизайн должен соответствовать задаче, но в тоже время быть общим, для того чтобы была возможность учесть требования, возникновение ко торых возможно в будущем. Сложность состоит ещ и в том, чтобы разложить систему на объекты. Кроме того, «вся система должна обладать концептуальным единством» [49], т.е. работа с похожими элементами системы должна происходить по аналогии. Тем са мым изучив работу с одним аспектом, легче освоить работу с дру гим.

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

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

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

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

Четырхуровневая архитектура разработки программного средст ва:

1. Уровень графического интерфейса пользователя. Уровень, на котором реализуется подсистема «Взаимодействие человек машина».

2. Уровень приложения. Здесь происходит объединение компо нентов лежащих ниже уровней и управление ими.

3. Уровень компонентов предметной области. Здесь располо жены компоненты предметно-ориентированного решения.

4. Уровень инфраструктуры. Включает так называемые «движки»

(англ. engines) и каркасы компонентов.

3.3.2. Взаимодействие с каркасом Назовм внешним субъектом каркаса в его детализированном состоянии, т.е. в состоянии, когда каркас подведн под нужды со ответствующей задачи, объект «Gamer» (Клиент), представляющий собой клиента для системы, реализуемой посредством компо нента. Объект «Gamer» обращается к подсистеме, главным обра зом, через вызов операций «StartGame» (Начать игру) и «MakeGameStep» (Сделать игровой ход), что соответственно указы вает системе на необходимость начать игру и сделать игровой ход.

На рис. 11 представлен сценарий использования детализи рованного каркаса. В данном случае общение происходит через элемент каркаса «GameManager» (Управляющий процессом).

3.3.3. Структура Обобщнная структура каркаса представлена на рис. 12.

Архитектура каркаса:

1. Уровень основных элементов.

2. Уровень управления процессом.

Составляющие уровня основных элементов (рис. 13):

1. «PlayerRole» (Игрок). Представляет собой тип игрока, роль ко торого может играть посредством системы, объект типа «Gamer». Связан с «CompetitorRole» и «UmpireRole» через атри буты «Competitor» и «Umpire» соответственно.

2. «CompetitorRole» (Соперник). Тип роли, исполняемой вычисли тельной машиной, представляет собой соперника для объекта типа «PlayerRole». Связан с «PlayerRole» и «UmpireRole» посред ством атрибутов «Player» и «Competitor» соответственно. Связь с «WordPuzzle» осуществляется посредством атрибута «Puzzle»

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

Рис. 11. Взаимодействие с детализированным каркасом Рис. 12. Обобщнная структура каркаса 3. «UmpireRole» (Судья). Так же представляет тип роли, исполняе мой вычислительной машиной и является судьй игрового про цесса. Он связан с «PlayerRole» и «CompetitorRole» посредст вом атрибутов «Player» и «Competitor» соответственно. Осталь ные атрибуты перечислены далее. «Statistics» – статистика иг рового процесса. Объект типа «StepsStatistics». «PuzzleState» – состояние головоломки. Объект типа «GamePuzzleState».

4. «WordPuzzle» (Задача). Тип, представляющий собой головолом ку лингвистической игры, решаемую во время занятий в игро вой форме. Атрибуты (в конечной реализации каркаса могут быть представлены в виде строковых переменных определн ного формата). «CompulsoryCondition» – условие, которое не обходимо соблюсти, чтобы решить задачу. «InitialCondition» – условие, с которого следует начать решение задачи. «Secret» – задача, которую нужно решить.

Рис. 13. Диаграмма классов уровня основных элементов 5. «StepsStatistics» (Статистика ходов). Тип статистики событий иг рового процесса. Атрибуты следующие. «Questions». Объект типа «PlayerQuestionsCatcher», фиксирующий вопросы (игро вые ходы), сделанные игроком. «States». Объект типа «GamePuzzleStatesCatcher», фиксирующий состояния решения задачи. «TimeStamps». Объект типа «TimeCatcher», фиксирую щий время осуществления игровых ходов.

6. «GamePuzzleState» (Состояние ситуации). Перечисление, со стоящее из следующих элементов. «NotCompleted» – означает, что задача ещ не решена. «AlmostCompleted» – задача почти решена. «Completed» – задача решена.

Элементы уровня управления процессом (рис. 14):

1. «GameCompetent» (Осведомлнный в игровом процессе). Тип объекта, представляющего сущность, знакомую с элемента ми процесса и принципами его организации. Этот тип связан с элементом типа «GameRules» посредством атрибута «Rules».

Связь с элементами типов «Alphabet», «KnowledgeHolder», «LanguageOfParticipants» осуществляется посредством атри бутов «CharacterSet», «HolderOfKnowledge» и «Language» соот ветственно. Остальные атрибуты перечисляются далее.

«Competitor». Объект типа «CompetitorRole». «Player». Объект ти па «PlayerRole». «Umpire». Объект типа «UmpireRole».

2. «GameManager» (Управляющий процессом). Наследник эле мента «GameCompetent», обладающий всей его функцио нальностью и присущими ему атрибутами. Содержит в себе описание события «QuestionProcessed», на которое объект типа «Gamer» должен подписаться.

3. «GameRules» (Правила). Тип для описания правил игры. Содер жит атрибут «AllowRepeatQuestions», уточняющий, дозволено ли игроку, повторяться в вопросах (делать повторные игровые хо ды).

4. «KnowledgeHolder» (База знаний). Тип, описывающий объекты, способные взаимодействовать с базой знаний. Имеет атрибут «Vocabulary», который может быть представлен в виде списка строковых элементов.

5. «Alphabet» (Алфавит). Основной атрибут – «Characters». Пред ставляет собой алфавит для выбранного языка.

6. «GameProcessState» (Состояние процесса). Описывает со стояние игрового процесса. Перечисление, включающее в свой состав следующие элементы. «Active» – процесс в актив ном состоянии. «Inactive» – не в активном состоянии.

Рис. 14. Диаграмма классов уровня управления процессом 7. «QuestionVerificationResult» (Результат проверки хода). Описы вает результат проверки игрового хода. Перечисление, вклю чающее в свой состав следующие элементы. «Correct» – когда сделан корректный с точки зрения правил игры ход. «Incorrect»

– когда сделан некорректный ход. «Repeat» – когда было повто рение игрового хода.

8. «LanguageOfParticipants» (Язык игроков). Содержит перечисле ние доступных языков.

3.3.4. Поток управления Детализация (или специфицирование под конкретный случай) каркаса происходит следующим образом (рис. 15):

1. Создатся новый класс, производится операция наследования этим классом структуры и поведения, присущих классу «GameManager».

2. Разрабатываются стратегия проверки игрового хода, сделан ного игроком (по отношению к системе, представленным объектом типа «Gamer») и стратегия ответа или иначе реакция на ход игрока.

3. Помимо этого необходимо создать головоломку и присвоить е представление свойству «Puzzle» атрибута «Competitor», доступного благодаря наследованию от «GameManager».

Обобщнные диаграммы взаимодействия объектов каркаса во время выполнения основных операций представлены на рис. – 17.

Последовательность взаимодействия объектов каркаса:

1. Создание экземпляра класса (обязанность объекта типа «Gamer»), наследованного от «GameManager», который созда т экземпляры следующих типов. «PlayerRole». Имя создавае мого экземпляра – «Player». «CompetitorRole». Создаваемый эк земпляр – «Competitor». «UmpireRole». Создаваемый экземпляр – «Umpire». «GameRules». Создаваемый экземпляр – «Rules».

«Alphabet». Создаваемый экземпляр – «CharacterSet».

«KnowledgeHolder». Создаваемый экземпляр – «HolderOfKnow ledge».

Рис. 15. Обобщнная диаграмма последовательности детали зации каркаса 2. Запуск игры. Происходит посредством выполнения метода «StartGame» на объекте типа «GameManager», который в свою очередь делегирует эту операцию объекту «Umpire» типа «UmpireRole». Объект «Umpire» в это время фиксирует начало запуска игры и производит соединение объектов «Umpire», «Competitor» и «Player» друг с другом.

3. Осуществление игрового хода. Операция проводится на объ екте типа «GameManager», который выполняет операцию «MakeStep» на объекте типа «PlayerRole», приводящую к сле дующей последовательности действий. Операция «GetAnswer»

(Получить ответ) на объекте типа «CompetitorRole»

(«Competitor»). Операция «SetPuzzleState» (Установить состоя ние ситуации) на объекте типа «UmpireRole» («Umpire»). Опера ция «UpdateStatistics» (Обновить статистику) на том же объекте.


После этого происходит событие «QuestionProcessed» (Собы тие обработки хода), передающее объекту типа «Gamer» ин формацию о проделанном игровом ходе.

Рис. 16. Взаимодействие объектов во время операции «Начать процесс»

Рис. 17. Взаимодействие объектов во время операции «Сде лать игровой ход»

Описание действий, производимых в рамках основных опера ций При выполнении операции «Сделать игровой ход» (метод «GameManager.MakeGameStep»), выполняется следующая после довательность действий (рис. 18):

1. Получив в качестве входного параметра список вопросов, вы полняется проверка условия «Игра находится в активном со стоянии» («GameProcessState.Active»). При положительном от вете на утверждение условия происходит переход на следую щий шаг, иначе – завершение операции.

2. Выполняется операция «Сообщение игроку: сделать ход» (ме тод «PlayerRole.MakeStep»).

3. Происходит проверка состояния ситуации («GamePuzzleState»), после чего, если состояние изменилось, происходит фикса ция этого изменения.

4. После обработки игрового хода происходит событие завер шения обработки вопроса («QuestionProcessed»).

Рис. 18. Последовательность действий при выполнении операции «Сделать игровой ход»

При выполнении операции «Совершить ход» на объекте ти па «Игрок» (метод «PlayerRole.MakeStep») происходит следующая последовательность действий (рис. 19):

1. Получив в качестве входных параметров список вопросов и правила игры, производится операция «Получить ответ» на объ екте «Соперник» (метод «CompetitorRole. GetAnswer»).

2. Обновляется состояние ситуации в объекте «Судья»

(«PuzzleState» в «Umpire»).

3. Происходит обновление статистики в объекте «Судья»

(«Statistics» в «Umpire»).

4. Возвращается состояние ситуации («GamePuzzleState»).

Рис. 19. Последовательность действий при выполнении операции «Сделать ход» на объекте типа «Игрок»

При выполнении операции «Получить ответ от соперника»

(метод «CompetitorRole.GetAnswer»), происходит следующая по следовательность действий (рис. 20):

1. Получив на вход в качестве параметров список вопросов и правила игры (обозначим последний параметр как «rules», эк земпляр типа «GameRules»), выполняется операция «Проверить ход игрока» (метод «rules.VerifyPlayerQuestion»).

2. Происходит проверка результата предыдущей операции. При удачной проверке происходит операция «Получить ответ со гласно заданной стратегии» (метод «AnswerStrategy.Get Answer»), тело которой должно быть описано тем, кто произво дил детализацию каркаса. В противном случае вызывается операция «Сообщить о некорректности хода» (исключение «WrongPlayerQuestionException», обработка которого должна предусматриваться внешним по отношению к каркасу объек том типа «Gamer»).

Рис. 20. Последовательность действий при выполнении операции «Получить ответ от соперника»

При выполнении операции «Получить результат проверки»

(метод «GameRules.VerifyPlayerQuestion»), происходит следующая последовательность действий (рис. 21):

1. Получив в качестве входных параметров список вопросов и объект «Судья» («Umpire»), происходит проверка условия «По вторы запрещены» (проверка условия «GameRules.Allow RepeatQuestions»), если условие выполняется, происходит пе реход на шаг 2, иначе на шаг 4. Примечание: проверка рабо тает только в том случае, когда длина списка вопросов равна единицы.

2. Происходит получение списка вопросов, заданных в процессе игры.

3. Проверяется наличие текущего вопроса в списке полученных.

При условии нахождения запрашиваемого элемента, возвра щается результат в виде сообщения «Повторение» («Question VerificationResult.Repeat»).

4. Происходит выполнение операции «Проверить вопросы со гласно заданной стратегии» («VerifyQuestionStrategy.Verify Question»), тело которой должно быть описано тем, кто произ водил детализацию каркаса.

3.4. Программный интерфейс каркаса Классы каркаса (табл. 3) спроектированы на основе следующих принципов. Принцип единственной обязанности (в таблице – SRP:

Single-Responsibility Principle) – разделение обязанностей между классами таким образом, чтобы у каждого класса была только одна причина для изменения [90]. Принцип открытости/закрытости (в таблице – OCP: Open/Closed Principle) – классы внутри про граммных компонентов должны быть открыты для расширения, но закрыты для модификации [73]. Принцип инверсии зависимости (в таблице – DIP: Dependency-Inversion Principle) – изоляция абстрак ций от деталей [71], например – классы каркаса (абстракции) не должны зависеть от деталей программного кода, использующего каркас.

Рис. 21. Последовательность действий при выполнении операции «Получить результат проверки»

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

Табл. Описание классов каркаса и их членов Пространство имн GSEducation.AQLPGFramework Принципы проек Тип Составляющие тирования public class Alpha- public Alphabet (LanguageOfParti- SRP (единствен bet – работа с ал- cipants language, bool useUpper- ная обязанность фавитом заданного Case) – конструктор, необходимо – предоставить языка задать требуемый язык и указать доступ к знакам тип выдачи литер, в верхнем или алфавита) нижнем регистре;

public Liststring Characters {get;

} – элемент доступа к литерам языка public class Compe- public GamePuzzleState GetAnswer SRP (от соперни titorRole – работа с (string[] question, out string answer, ка ожидается ролью соперника GameRules gameRules) – получить только ответ, от ответ от соперника, хранящего за- носительно хода дачу-головоломку на вопрос игро- игрока);

ка. Выполняется логикой каркаса OCP (присутст во время вызова метода Player- вие переменной Role.MakeStep();

интерфейса IGe public IGetAnswerStrategy Answer- tAnswerStrategy Strategy {set;

get;

} – интерфейс гарантирует воз класса, реализующего стратегию можность рас получения ответа на вопрос;

ширения, класса путм инстанци public PlayerRole Player {set;

get;

} – рования этой пе игрок, ассоциированный с сопер ременной за ником;

пределами ком public WordPuzzle Puzzle {set;

get;

} – понента) лингвистическая задача головоломка;

public UmpireRole Umpire {set;

get;

} – судья, ассоциированный с со перником public class Game- public GameCompetent (Langua Competent –класс geOfParticipants language) – конст объектов, имеющих руктор, требует задания языка;

доступ к управле- publiс Alphabet CharacterSet {set;

нию элементами get;

} – набор литер алфавита;

процесса решения public CompetitorRole Competitor задачи- {set;

get;

} – доступ к сопернику;

головоломки public KnowledgeHolder HolderOfK nowledge {set;

get;

} – доступ к лек семам языка;

public LanguageOfParticipants Lan guage {set;

get;

} – язык текущего процесса;

public PlayerRole Player {set;

get;

} – игрок процесса решения;

public GameRules Rules {set;

get;

} – правила процесса решения;

public UmpireRole Umpire {set;

get;

} – судья процесса решения public class Game- public void StartGame() – начать SRP (обязанность Manager : Game- процесс;

управляющего Competent – класс процессом – public bool MakeGameStep(string[] объектов, управ- управлять про question) – сделать шаг (задать во ляющих процессом цессом, т.е. на прос) в процессе решения зада решения чать сам про чи-головоломки;

цесс и продви public event EventHandler Ques- гать его);

tionProcessedEventArgs Question DIP (переменная Processed – событие, на которое события «Ques необходимо подписаться, чтобы tionProcessed»

получать ответы на вопросы.

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

между абстрак цией и конкрет ной реализаци ей) public enum Game- Active – процесс активен (уже на ProcessState – со- чался, но ещ не завершн);

стояние процесса решения задачи- Inactive – процесс не активен (ли головоломки бо ещ не начался, либо уже за вершн) public enum Game- AlmostCompleted – задача почти PuzzleState – со- решена;

стояние решения Completed – задача решена пол задачи. Имеет ме- ностью;

сто в контексте ме NotCompleted – задача не решена тода GetAnswerLog (возможно ещ и не решалась) ic класса Customi zableGetAnswerStra tegy (листинг 2, да лее по тексту) public enum Langu- English – английский язык;

ageOfParticipants – Russian – русский язык заданный язык public enum Ques- Correct – вопрос-утверждение уча tionVerificationResult стника соответствует правилам – результат обра- задачи, действующим в рамках ботки вопроса. процесса;

Имеет место в кон- Incorrect – не соответствует прави тексте метода Veri- лам либо повторяется в то время, fyQuestionLogic когда повторы запрещены;

класса Customizab Repeat – соответствует правилам leVerifyQuestionStra задачи, но в данном случае – по tegy (листинг 2, да втор в рамках процесса.

лее по тексту) Примечание: при инициализации класса «GameManager» можно указать – разрешены «повторения вопросов» со стороны главного участника или запрещены public class Game- public void Add(GamePuzzleState SRP (единствен PuzzleStatesCatcher state) – добавить состояние (вы- ная задача хра – хранение всех полняется автоматически логикой нителя – хранить) состояний решения каркаса);


задачи, полученных public ListGamePuzzleState Items за процесс ( дос {get;

} – элементы всех состояний тупны через Game- решения задачи, учитываются ав Compe tent.Umpire.Statistics. томатически логикой каркаса States) public class Game- public QuestionVerificationResult Ve- SRP (единствен Rules – правила за- rifyPlayerQuestion(string[] question, ная задача пра дачи-головоломки, UmpireRole umpire) – проверить во- вил – применять которые действуют прос игрока;

ся, в данном слу во время процесса чае обязанность – public bool AllowRepeatQuestions {set;

get;

} – разрешение или запрет проверка соот ветствия действий на повторные вопросы со стороны игрока заданным игрока;

правилам);

public IVerifyQuestionStrategy Veri fyQuestionStrategy {set;

get;

} – стра- OCP (та же идея, что и в классе тегия проверки утверждений со «CompetitorRole») стороны игрока public class Know- public KnowledgeHolder (Langua- SRP (обязанность ledgeHolder – база geOfParticipants language) – конст- базы знаний – знаний, содержа- руктор, требует указания языка для предоставление щая словарные работы;

знаний и их по лексемы языка полнение) public void AddWord(string word) – добавить лексему в базу знаний на период процесса решения;

public bool FindWord(string word) – проверить наличие конкретной лексемы в базе;

public Liststring GetWordsByPa rams (int length) – найти все лек семы в базе заданной длины;

public Liststring GetWordsByPa rams (int length, char firstLetter) – найти все лексемы в базе задан ной длины, начинающиеся с опре делнной литеры;

public Liststring Vocabulary {get;

} – доступ к словарю, содержаще му лексемы текущего языка public class Player- public void Add(string[] question) – QuestionsCatcher – добавить вопрос, вопросы учиты хранитель вопро- ваются автоматически логикой сов, поступающих каркаса;

от игрока public Liststring Items {get;

} – по лучить список вопросов public class Player- public GamePuzzleState MakeStep SRP (обязанность Role – работа с ро- (string[] question, out string answer, игрока – совер лью игрока GameRules gameRules) – сделать шать игровые ша ход – задать вопрос (выполняется ги) логикой каркаса во время вызова метода GameManag er.MakeGameStep(..));

public CompetitorRole Competitor { set;

get;

} – соперник ассоцииро ванный с игроком;

public UmpireRole Umpire {set;

get;

} – судья, ассоциированный с игро ком public class Ques- public QuestionProcessedEventArgs tionProcessedEven- (GamePuzzleState state, string an tArgs : Sys- swer) – конструктор, требует ука tem.EventArgs – ар- зания состояния решения задачи и гументы, переда- ответ на вопрос со стороны игро ваемые обработчи- ка (выполняется автоматически ло ку событий типа гикой каркаса во время вызова QuestionProcessed метода GameManag er.MakeGameStep(..));

public string Answer {get;

} – ответ на вопрос;

public GamePuzzleState State {get;

} – состояние решения задачи public class public PlayerQuestionsCatcher StepsStatistics – ста- Questions {set;

get;

} – вопросы, за тистика совершн- данные игроком в процессе ре ных ходов шения задачи-головоломки;

public GamePuzzleStatesCatcher States {set;

get;

} – состояния реше ния задачи;

public TimeCatcher TimeStamps {set;

get;

} – временные отметки, со вершнных игроком ходов public class Time- public void Add() – добавить вре- SRP (задача хра Catcher – времен- менную отметку, временные от- нителя – хранить) ные отметки со- метки фиксируются логикой кар вершения ходов каса;

public ListDateTime Items {get;

} – набор временных отметок совер шения ходов public class Umpire- public void StartGame(PlayerRole SRP (главная за Role – работа с ро- player, CompetitorRole competitor) – дача судьи – на лью судьи начать процесс решения (выпол- чать процесс) няется автоматически при вызове метода GameManager.StartGame());

public CompetitorRole Competitor {set;

get;

} – ассоциированы с судьй соперник;

public PlayerRole Player {set;

get;

} – ассоциированный с судьй игрок;

public GamePuzzleState PuzzleState {set;

get;

} – текущее состояние решения задачи;

public StepsStatistics Statistics { set;

get;

} – статистика шагов public class Word- public string CompulsoryCondition Puzzle – работа с {set;

get;

} – обязательное условие задачей- для решения задачи;

головоломкой public string InitialCondition {set;

get;

} – начальное условие для ре шения задачи;

public string Secret {set;

get;

} – сек рет задачи public class Конструкторы:

WrongPlayerQues public WrongPlayerQuestionExcep tionException : Sys- tion();

tem.Exception – ис- public WrongPlayerQuestionExcep ключения, вызван- tion (string message);

ные некорректным public WrongPlayerQuestionExcep составлением во tion (string message, Sys просов tem.Exception innerException);

protected WrongPlayerQuestionEx ception (SerializationInfo info, Strea mingContext context);

Шаблон детализации Листинг 1. Код шаблона проекта:

using System;

using GSEducation.AQLPGFramework;

namespace GSEducation.AQLPGFramework.DetalizationTemplate{ public class TemplateGameManager : GameManager{ public TemplateGameManager() : base(LanguageOfParticipants.Russian, true){ InitializeGame();

} public TemplateGameManager( LanguageOfParticipants language, bool allowRepeat) : base(language, allowRepeat){ InitializeGame();

} private void InitializeGame(){ MakePuzzle();

} protected virtual void MakePuzzle(){ throw new NotImplementedException();

}} public class TemplateGetAnswerStrategy : IGetAnswerStrategy{ public TemplateGetAnswerStrategy(GameManager manager){ gameManager = manager;

} public GamePuzzleState GetAnswer( string[] question, out string answer){ GamePuzzleState puzzleState = GamePuzzleState.NotCompleted;

answer = “”;

puzzleState = GetAnswerLogic(question, out answer);

return puzzleState;

} protected virtual GamePuzzleState GetAnswerLogic( string[] question, out string answer){ throw new NotImplementedException();

} protected GameManager gameManager;

} public class TemplateVerifyQuestionStrategy : IVerifyQuestionStrategy{ public TemplateVerifyQuestionStrategy(GameManager manager){ gameManager = manager;

} public QuestionVerificationResult VerifyQuestion(string[] question){ QuestionVerificationResult result = QuestionVerificationResult.Correct;

VerifyQuestionLogic(question, out result);

return result;

} protected virtual void VerifyQuestionLogic( string[] question, out result){ throw new NotImplementedException();

} protected GameManager gameManager;

}} Листинг 2. Предоставление точек расширения:

using System;

using GSEducation.AQLPGFramework;

namespace GSEducation.AQLPGFramework.DetalizationTemplate{ public class CustomizedGameManager:

TemplateGameManager{ public CustomizedGameManager( LanguageOfParticipants language, bool allowRepeat) : base(language, allowRepeat){} public CustomizedGameManager() : base(){} protected override void MakePuzzle(){ Rules.VerifyQuestionStrategy = new CustomizableVerifyQuestionStrategy(this);

Competitor.AnswerStrategy = new CustomizableGetAnswerStrategy(this);

// TODO:

// VARIABLE PART – EXTENSION POINT // =============================== // =============================== } private class CustomizableVerifyQuestionStrategy:

TemplateVerifyQuestionStrategy{ public CustomizableVerifyQuestionStrategy( GameManager manager) : base(manager){} protected override void VerifyQuestionLogic( string[] question, out QuestionVerificationResult verificationResult){ verificationResult = QuestionVerificationResult.Incorrect;

// TODO:

// VARIABLE PART - EXTENSION POINT // =============================== // =============================== }} private class CustomizableGetAnswerStrategy:

TemplateGetAnswerStrategy{ public CustomizableGetAnswerStrategy( GameManager manager) : base(manager){} protected override GamePuzzleState GetAnswerLogic(string[] question, out string answer){ GamePuzzleState puzzleState = GamePuzzleState.NotCompleted;

answer = “”;

// TODO:

// VARIABLE PART - EXTENSION POINT // =============================== // =============================== return puzzleState;

}}}} Места в листингах, обозначенные как «VARIABLE PART» пред ставляют собой точки расширения, в которые разработчик может вставлять изменяемый код (активно пользуясь элементами карка са). Листинг 1 – содержит код шаблона проекта, который абсо лютно не требует изменений, он не содержит точек расширений и служит своеобразным проектным решением, способствующим более комфортной работе по созданию конечного компонента на основе каркаса. В листинге 2 следует изменить название клас са «CustomizedGameManager» на более подходящее в конкрет ном контексте имя. Для предметно-ориентированного языка, кар кас и шаблон его детализации (представленный листингами 1 – 2) представляют фиксированную часть.

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

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

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

Третий уровень – уровень компонентов предметной области.

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

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

Место каркасу, представленному в этой главе – на четвр том, инфраструктурном уровне архитектуры обучающего про граммного средства. Место компонеyтам, которые создаются на базе каркаса – на третьем уровне. В рамках авторского проекта одного обучающего программного средства «We Need Your Help»

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

ГЛАВА 4. ПРОВЕРКА И ИСПЫТАНИЕ ПРОЕКТНЫХ РЕ ШЕНИЙ В этой главе решаются задачи №5 и №6, поставленные во введении и частично решнные в предыдущей главе. Здесь представлены результаты проведнных экспериментов с моделями, определе ние качества проектных решений, сравнение с имеющимися ре шениями.

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

4.1.1. Проект «CrossMaster»

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

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

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

1. Идентификация студента.

2. Генерация задания системой (под наблюдением преподава теля и в соответствии с заданными критериями).

3. Выдача студенту задания.

4. Проведение тестирования (проверочного мероприятия).

5. Выдача результата проверки.

6. Оповещение студента (и преподавателя) о допуске к лабора торной работе.

Дополнительные требования:

1. Разрешить обучение студента терминологии заданной дисци плины.

2. Удержать студента от соблазна «списать» во время теста, т.е.

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

Технические требования к запуску обучающего программного средства:

1. Компьютеры под управлением операционной системы «Windows» (не ниже XP).

2. Предустановленная среда выполнения «.NET Framework» вер сии 2.0 или выше.

Причины выбора платформы запуска/разработки «.NET Frame work»:

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

2. В рамках платформы собрана большая библиотека компо нентов, позволяющая быстрее разработать программное средство.

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

4. Платформа «.NET Framework» бесплатна для установки и рас пространения, а в операционных системах, начиная с «Windows Vista» – среда «.NET Framework» уже предустановлен на.

Причина выбора операционной системы «Windows» – эта система установлена практически на любом персональном ком пьютере различных учебных заведений (одна из причин – содейст вие компании «Microsoft» в поддержке учебного процесса в выс ших учебных заведениях и включении операционных систем в бес платные комплекты «Первая Помощь 1.0» для школ по инициативе государства Российской Федерации (это было актуально на мо мент разработки программного средства)).

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

Игра будет функционировать в рамках подсистемы «Обу чение», которая будет проводить контроль (в виде теста) или тре нировку (в виде упражнения) студента в зависимости от выбранно го режима. Один из необходимых элементов – контролер време ни, цель – ограничить время тестирования в случае необходимости.

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

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

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

Суть такова, что во время запуска приложения на тестирование, компьютерная система должна быть заблокирована таким обра зом, чтобы тестирующийся не смог вести поиск нужной инфор мации на заблокированном компьютере. Решение – заблокиро вать «Диспетчер задач» операционной системы, меню «Пуск» и комбинацию таких клавиш, как «Alt + Tab» (переключение между окнами), «Alt + F4» (закрытие активного окна приложения), «Alt + Esc» (активация другого выполняющегося приложения), «Alt + Ctrl + Del» (вызов «Диспетчера задач»).

Также необходима подсистема «Управление пользователя ми». Интересующая информация – фамилия, имя, отчество сту дента.

Программирование приложения проводилось с использо ванием инструментария «Microsoft Visual C# Express Edition 2008», язык программирования – «C#». Выбор языка обусловлен тем, что он является родным (англ. native в технической документации к язы ку) для платформы «.NET Framework».

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

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

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

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



Pages:     | 1 || 3 | 4 |
 





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

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