CC BY
122
№ 3 (27) 2010
С. В. Гусс
Модель каркаса программных компонентов поддержки занятий лингвистической направленности в игровой форме
В статье описана архитектура каркаса — одного из элементов повторного использования, рассматриваемая как переносимая модель многократного применения. Реализация предложенной автором модели позволяет ускорить процесс разработки компонентов программного продукта. Приведен пример детализации возможностей каркаса.
Проблема повторного использования дала о себе знать, когда компьютерные программы стали рассматриваться как инженерные творения, и разработчики создавали уже не единичную программу, решающую конкретную задачу, но продукт, принадлежащий особому программному семейству. О необходимости создания семейства программных продуктов, нежели единичных программ, писал еще в 1972 году Давид Парнас [11], борец за придание профессионального статуса «инженерии программного обеспечения» (ему же принадлежат идеи концепции сокрытия информации [10], высокого связывания внутри модуля и низкого сцепления между ними).
Что же касается лингвистических занятий, то на протяжении многих лет они демонстрировали свой успех в обучении не только языку и его особенностям, но и применению его в профессиональной сфере. Об игровой форме таких занятий можно говорить так же, как и о других обучающих занятиях в той же форме. Большая работа в этом направлении проделана Марком Пренским, исследователем в области электронного обучения, в основе которого лежат компьютерные игры. В одной из его публикаций [12] можно найти информацию о том, почему именно игровая форма является привлекательной. Перечислим причины, приведен-
ные в книге и доработанные автором статьи:
1. Игры доставляют удовольствие.
2. Способствуют интенсивному вовлечению в процесс обучения.
3. В них заложены правила, из чего следует упорядоченность и структура процесса.
4. Игры мотивируют, т. к. имеют определенные цели.
5. Они интерактивны, что заставляет действовать.
6. Обязательно присутствует обратная связь, что способствует обучению.
7. Игровому процессу характерно свойство привыкания, что позволяет без труда получать новые знания посредством игры.
8. В игре есть состояния победы, что дает возможность почувствовать свои силы.
9. Они развивают творческие способности, благодаря тому, что заставляют справляться с проблемами, искать способы их решения.
10. Игры способны социализировать благодаря специальным многопользовательским режимам.
11. Воздействуют на эмоции, в случае, если имеют в своем основании определенную историю или повествование.
В этой же публикации есть описание возможных игровых стилей для различных тематических направлений изучаемых дисциплин.
ПРИКЛАДНАЯ ИНФОРМАТИКА /-
' № 3 (27) 2010
Место каркаса в классификации элементов повторного использования
Часто в литературе вместо фразы «элементы повторного использование», можно встретить словосочетание «компоненты многократного применения». Эти термины не являются синонимами, но они суть описания одного и того же явления на разных уровнях представления. В первом случае речь идет об абстрактном уровне представления, в последнем о конкретном, или уровне реализации, когда имеют в виду наличие готового к использованию компонента, а не описывающую его модель.
Элементы повторного использования можно классифицировать по нескольким признакам:
1. По уровню представления:
а) Модели. Представляют собою высокоуровневое описание структуры и поведения.
б) Набор кода. Готовый к применению код на определенном языке программирования.
в) Исполняемые модули. Готовые к запуску, посредством пользователя или внешнего компьютерного приложения, компоненты. В идеальном случае характеризуются отсутствием привязки к языку программирования. Но возможна привязка к определенной программно-аппаратной платформе.
2. По специфике повторно используемого элемента. Классификация похожа на ту, что приведена в [5]. Только в представленной ниже классификации не фигурирует такой элемент, как модель, т. к. она не подходит под данный признак деления, в связи с чем этот элемент был отнесен к другой группе.
а) Функциональные библиотеки (набор подпрограмм под специфические нужды). В отличие от каркасов, здесь повторно используются функции, а написание тела приложения, в котором будут использованы эти функции, остается задачей разработчика.
б) Образцы (соответствуют этапам ^ разработки): оо
• анализа [8], применимы для анализа и предметной области приложения;
• архитектурные [9], для упорядочивания архитектуры;
• проектирования [4], для применения опыта, накопленного и обобщенного другими разработчиками в виде особых проектных решений;
• реализации [2], для обслуживания задач ежедневного программирования, а также для придания программному коду читабельного вида и внесения в него большей ясности.
в) Каркасы. Более специализированы, чем образцы. Важно отметить, что приложение может разрабатываться на основе нескольких каркасов, это часто относится к очень крупным приложениям масштаба предприятия. Особенность состоит в том, что повторно используется тело приложения, к которому добавляются функции и уточнения.
3. По этапу разработки (элементы могут быть представлены и моделями, и набором кода, и в виде исполняемых модулей, и даже просто в виде текстового описания):
а) Предметной области.
б) Сбора и анализа требований.
в) Архитектуры. Чтобы архитектура могла быть многократно используемой, крайне необходимо отделить ее от реализации, а на основании [1] еще и от алгоритмов и представления данных.
г) Проекта.
д) Реализации.
е) Тестирования.
Проблема разработки каркаса
Каркас — это «набор взаимодействующих классов, составляющих повторно используемый дизайн для конкретного класса программ» [4]. Конкретный класс программ или семейство программных продуктов — набор программ, имеющих настолько много общего, что выгоднее изучить их общие
-N ПРИКЛАДНАЯ ИНФОРМАТИКА
№ 3 (27) 2010 ' -
аспекты, прежде чем изучать те, в которых они различны [11].
Влияние каркаса на детализирующую его систему может быть описано следующими принуждающими параметрами [4]:
1. Определенная архитектура.
2. Структура классов и объектов.
3. Основная функциональность, описанная в классах.
4. Методы взаимодействия между объектами.
5. Потоки управления. Навязывание этих параметров обуслов-
<ъ лено тем, что разработчики могут сконцен-^ трироваться на специфике разрабатывае-^ мой программы и не тратить время на поиск | черт, уже описанных и известных. ^ Одна из проблем дизайна любого типа ^ программного обеспечения заключается § в том, что, как отмечается в [4], дизайн дол-| жен соответствовать задаче, но в тоже вре-§ мя быть общим, для того, чтобы была воз-
<5
& можность учесть потенциальные требова-
* ния, которые могут возникнуть в будущем. § Сложность состоит еще и в том, чтобы раз-| ложить систему на объекты. Кроме того, У «вся система должна обладать концепту-| альным единством» [3].
1 1
| Описание модели 3 разработанного каркаса
|| Концепция
| Главным пользователем каркаса являет-
£ ся разработчик программного обеспечения,
■с который использует каркас для достижения
§ своих целей в процессе устранения имею-
8 щегося дискомфорта потребителей, привед-
! шего к необходимости создания будущего
Ц программного продукта.
<4
& Реализация модели каркаса, описывае-
& мая в данной работе, позволяет ускорить
2 процесс разработки компонентов программ-¡1 ного продукта за счет того, что в нем уже
* присутствует программа управления всеми необходимыми операциями, происходящи-
?! ми в игровом процессе, т. е. можно сказать,
что в нем заложена парадигма потока управления. Разработчику, использующему каркас, необходимо лишь уточнить в нем некоторые детали и добавить несколько стратегий для операций, специфичных для решаемой задачи.
Пользователем разработанного на основе каркаса компонента также является разработчик. Чтобы избежать путаницы в определениях, автор далее будет называть такой компонент детализированным каркасом, подчеркнув тем самым роль последнего. А вот пользователем продукта, построенного на основе этого компонента или компонентов, будет уже не разработчик, а конечный пользователь, для которого создавался продукт.
Далее приводится описание архитектуры каркаса, которая будет рассматриваться как переносимая модель многократного применения (такой взгляд был предложен в [1]).
Следует отметить, что хотя конечная реализация каркаса была произведена для платформы (или среды) выполнения Microsoft .NET Framework, лежащая в основе разработанного каркаса модель с легкостью может быть реализована для других платформ, об этих особенностях в описании будет упомянуто отдельно.
Взаимодействие с пользователем
Назовем внешним субъектом каркаса в его детализированном состоянии (т. е. в состоянии, когда каркас подведен под нужды соответствующей задачи) объект Gamer, представляющий собой клиента для системы, реализуемой посредством компонента. Объект Gamer обращается к подсистеме главным образом через вызов операций StartGame() и MakeGameStepQ (для более ясного описания параметры операций в большинстве случаев будут опущены, кроме тех мест, где без них нельзя обойтись), что соответственно указывает системе на необходимость начать игру и сделать игровой ход (см. рис. 1).
№ 3 (27) 2010
Рис. 1. Диаграмма вариантов использования детализированного каркаса
Структура
Диаграмма классов каркаса представлена на рис. 2 и 3. Структура каркаса делится на два уровня:
1. Уровень основных элементов.
2. Уровень управления процессом.
Перечислим элементы уровня основных
элементов:
1. PlayerRole. Представляет собой тип игрока, роль которого может играть посредством системы объект типа Gamer. PlayerRole связан с CompetitorRole и Um-pireRole через атрибуты Competitor и Umpire соответственно.
2. WordPuzzle. Тип, представляющий собой лингвистическую задачу, решаемую во время занятий в игровой форме. Атрибуты (в конечной реализации каркаса могут быть представлены в виде строковых переменных определенного формата):
• CompulsoryCondition — условие, которое необходимо соблюдать, чтобы решить задачу.
• InitialCondition — с этого условия следует начать решение задачи.
• Secret — задача, которую нужно решить.
3. CompetitorRole. Тип роли, исполняемой вычислительной машиной, представляет собой соперника для объекта типа PlayerRole. CompetitorRole связан с PlayerRole и UmpireRole посредством атрибутов Player и Competitor соответственно. Связь с WordPuzzle осуществляется посредством атрибута Puzzle (отсюда видно, что лингвисти-
ческая задача находится в его ведомости). ¿i Еще один важный атрибут, на который следует обратить особое внимание, это Answer- ^ Strategy типа IGetAnswerStrategy, представляющего собой интерфейс. В качестве значения этот атрибут может принимать только те объекты, классы которых реализуют интерфейс типа IGetAnswerStrategy, служащий в рамках игрового каркаса средством реализации шаблона проектирования «Стратегия», описанного в [4].
4. UmpireRole. Также представляет тип роли, исполняемой вычислительной машиной и является судьей игрового процесса. Он связан с PlayerRole и CompetitorRole посредством атрибутов Player и Competitor соответственно. Остальные атрибуты:
• Statistics — статистика игрового процесса. Объект типа StepsStatistics.
• PuzzleState — состояние головоломки. Объект типа GamePuzzleState.
5. StepsStatistics. Тип статистики событий игрового процесса. Атрибуты:
• Questions. Объект типа PlayerQuestions-Catcher, фиксирующий вопросы (игровые ходы), сделанные игроком.
• States. Объект типа GamePuzzleStates-Catcher, фиксирующий состояния решения лингвистической задачи.
• TimeStamps. Объект типа TimeCatcher, фиксирующий время осуществления игровых ходов.
6. GamePuzzleState. Перечисление, состоящее из следующих элементов:
• NotCompleted — означает, что лингвистическая задача еще не решена.
• AlmostCompleted — задача почти решена.
• Completed — задача решена.
Элементы уровня управления процессом:
1. GameCompetent. Тип объекта, представляющего сущность, знакомую с элементами процесса и принципами его организации. Этот тип связан с элементом типа GameRules посредством атрибута Rules. Связь с элементами типов Alphabet, KnowledgeHolder, LanguageOfParticipants осуществляется посредством атрибутов Character-
65
№ 3 (27) 2010
О
о ^
о
Ii
s
Рис. 2. Диаграмма классов каркаса уровня основных элементов
Set, HolderOfKnowledge и Language соответственно. Остальные атрибуты:
а) Competitor. Объект типа Competitor-Role.
б) Player. Объект типа PlayerRole.
в) Umpire. Объект типа UmpireRole. 2. GameManager. Наследник элемента GameCompetent, обладающий всей его функциональностью и присущими ему атрибутами. Он связан с элементом Game-ProcessState посредством приватного атрибута m_GameState и содержит в себе описание события QuestionProcessed, на которое объект типа Gamer должен подписаться посредством стандартного делегата типа EventHandler, с передачей ему в качестве параметра аргументы типа QuestionProcessed-EventArgs. Этот тип (QuestionProcessedEvent-
Args), наследованный от стандартного типа EventArgs, обладает такими атрибутами, как Answer (ответ, который следует передать объекту типа Gamer) и State (объект типа GamePuzzleState). Примечание: типы EventArgs и EventHandler являются стандартными для платформы .NET Framework, поэтому при реализации модели для других платформ следует это учитывать.
3. GameRules. Тип для описания правил игры. Содержит атрибут AllowRepeatQues-tions, уточняющий, дозволено ли игроку повторяться в вопросах (делать игровые ходы).
4. KnowledgeHolder. Тип, описывающий объекты, способные управлять базой знаний. Имеет атрибут Vocabulary, представляющий собой список строковых элементов, и связан с элементом LanguageOfPar-
66 j —
--Инструментальные средства Ш> Технология разработки программного обеспечения
№ 3 (27) 2010
Рис. 3. Диаграмма классов каркаса уровня управления процессом
ticipants посредством приватного атрибута m_Language.
5. Alphabet. Основной атрибут — Characters. Представляет собой алфавит для выбранного языка.
6. GameProcessState. Описывает состояние игрового процесса. Перечисление, включающее в свой состав следующие элементы:
а) Active — процесс в активном состоянии.
б) Inactive — не в активном состоянии. 7. QuestionVerificationResult. Описывает результат проверки игрового хода. Перечисление, включающее в свой состав такие элементы, как:
а) Correct — если сделан корректный с точки зрения правил игры ход.
б) Incorrect — сделан некорректный ход.
в) Repeat — имело место повторение игрового хода.
№ 3 (27) 2010
t
0 OQ
t OQ
S
CO CQ
1
I !
1
I i
I
I
i &
ss
t
Sc §
8. LanguageOfParticipants. Содержит перечисление доступных языков в реализованной версии каркаса и состоит из следующих элементов (сама модель не ограничивает количество языков):
а) English.
б) Russian.
Поток управления
Детализация (или специфицирование под конкретный случай) каркаса происходит следующим образом. Создается новый тип (класс в терминах объектно-ориентированной парадигмы), производится операция наследования этим типом структуры и поведения, присущих классу GameManager. Разрабатываются стратегия проверки игрового хода, сделанного игроком (представленным объектом типа Gamer) и стратегия ответа или иная реакция на ход игрока. Помимо этого, необходимо создать лингвистическую задачу и присвоить ее представление свой-
ству Puzzle атрибута Competitor, доступного благодаря наследованию от GameManager. Диаграмма последовательностей детализации каркаса представлена на рис. 4.
Последовательность взаимодействия с детализированным каркасом (см. рис. 5 и 6) предполагает следующие действия:
1. Создание экземпляра класса (обязанность объекта типа Gamer), наследованного от GameManager, который создает экземпляры следующих типов:
а) PlayerRole. Имя создаваемого экземпляра — Player.
б) CompetitorRole. Создаваемый экземпляр — Competitor.
в) UmpireRole. Создаваемый экземпляр — Umpire.
г) GameRules. Создаваемый экземпляр — Rules.
д) Alphabet. Создаваемый экземпляр — CharacterSet.
е) KnowledgeHolder. Создаваемый экземпляр — HolderOfKnowledge.
Рис. 4. Диаграмма последовательностей детализации игрового каркаса
68
№ 3 (27) 2010
! OQ
Рис. 5. Диаграмма сотрудничества объектов каркаса во время операции «Начать игру»
2. Запуск игры. Происходит посредством выполнения метода StartGame() на объекте типа GameManager, который в свою очередь делегирует эту операцию объекту Umpire типа UmpireRole. Объект Umpire в это время фиксирует начало запуска игры и производит соединение объектов Umpire, Competitor и Player друг с другом.
3. Осуществление игрового хода. Опять же операция проводится на объекте типа GameManager, который выполняет операцию MakeStep() на объекте типа PlayerRole, приводящую к следующей последовательности действий:
а) Операция GetAnswer() на объекте типа CompetitorRole(Competitor).
б) Операция SetPuzzleState() на объекте типа UmpireRole(Umpire).
в) Операция UpdateStatistics() на том же объекте.
После этого происходит событие Ques-tionProcessed(), передающее объекту типа Gamer информацию о проделанном игровом ходе.
Описание методов основных операций
Поскольку, как пишет Майкл Бин в эссе «Подводные камни внешнего подряда» [6], «... каждая написанная строка кода подра-
№ 3 (27) 2010
t
^
0 CQ
t CQ
S
со CQ
1
I !
1
i i
i
I
t &
is
t £
§
Рис. 6. Диаграмма сотрудничества объектов каркаса во время операции «Сделать игровой ход»
зумевает решение относительно архитектуры программы ...», автор каркаса не приводит конкретного кода реализации поведения каркаса, но описывает схемы последовательностей действий, подразумеваемых операциями элементов модели.
При вызове метода GameManager.Make-GameStep() выполняется следующая последовательность действий:
1. Получив в качестве входного параметра список вопросов, выполняется проверка условия «Игра находится в активном состоянии». При положительном ответе на утверждение условия происходит переход на следующий шаг, иначе выход из подпрограммы.
2. Выполняется операция Player.Make-Step(), описание которой приводится ниже.
3. Происходит проверка состояния лингвистической задачи, после чего, если оно изменилось, это изменение фиксируется.
4. После обработки игрового хода происходит событие QuestionProcessed().
При вызове метода PlayerRole.MakeStep() происходит следующая последовательность действий (метод вызывается при выполнении GameManager.MakeGameStep()):
1. Получив в качестве входных параметров список вопросов и правила игры, производится операция CompetitorRole.GetAn-swer() через атрибут Competitor, описание которой дается ниже.
2. Обновляется состояние лингвистической задачи в свойстве PuzzleState атрибута Umpire.
3. Происходит обновление статистики в объекте Umpire.
4. Возвращается состояние лингвистической задачи.
При вызове метода CompetitorRole.GetAns-wer() (вызывается при выполнении Player-Role.MakeStep()) происходит следующая последовательность действий:
1. Получив на вход метода в качестве параметров список вопросов и правила игры (обозначим последний параметр как rules, экземпляр типа GameRules), выполняется операция rules.VerifyPlayerQuestion(), описание которой приводится далее.
2. Проверяется результат предыдущей операции. При удачной проверке происходит возврат метода AnswerStrategy.GetAn-swer(), тело которого должно быть описано тем, кто производил детализацию каркаса. В противном случае вызывается исключе-
70
№ 3 (27) 2010
Л
со
ci
Рис. 7. Диаграмма деятельности, описывающая последовательность операций при вызове метода GameManager.MakeGameStep()
ние WrongPlayerQuestionException(), обработка которого должна предусматриваться внешним по отношению к каркасу объектом типа Gamer.
При вызове метода GameRules.VerifyPlay-erQuestion() происходит последовательность действий, приведенных ниже (метод вызы-
вается посредством исполнения Сотре^ог-Role.GetAnswer()):
1. Получив в качестве входных параметров список вопросов и объект типа итрге-Role(Umpiгe), проверяется условие «Запрещено повторять вопросы (игровые ходы) и список вопросов состоит из одного эле-
№ 3 (27) 2010
I
»¡а
0 со
1
со
£ со
со
I £
15
I
1! 1
I
I
I
I I
з
I £
Л
Рис. 8. Диаграмма деятельности, описывающая последовательность операций при вызове метода PlayerRole.MakeStep()
мента», если условие выполняется, происходит переход на шаг 2, иначе на шаг 4.
2. Происходит получение списка вопросов, заданных в процессе игры.
3. Проверяется наличие текущего вопроса в списке полученных. При условии нахождения запрашиваемого элемента возвращается результат в виде объекта Question-VeгificationResult.Repeat.
4. Происходит возврат метода VeгifyQues-tionStгategy.VeгifyQuestion(), тело которого должно быть описано тем, кто производил детализацию каркаса.
Пример детализации возможной реализации каркаса
Реализация предложенной модели каркаса возможна, более того, она реализована автором статьи (готовятся документы к ее регистрации). Причем на основе реализованного каркаса было создано уже пять компонентов, необходимых для планируемых разработок обучающих программных
продуктов в рамках исследований автора. Ниже приводится программный код уточнения каркаса, откомпилированная версия которого представляет собой готовый к многократному применению компонент. Уточнение проводится с использованием языка С# (при написании кода автор придерживался общепринятых стандартов оформления, собранных в одном месте и перечисленных в [7]) на примере очень простой лингвистической игры «Лесенка». Суть такова. Соперник задает произвольную букву и количество ступеней лестницы. Цель игрока — выстроить из слов, начинающихся на эту букву, лестницу из заданного количества ступеней. Первое слово должно состоять из двух или трех букв, второе на единицу длиннее предыдущего, и так далее по индукции до заданного количества ступеней. Рассмотрим пример. Соперник задал букву «а» и количество ступеней равное 4. Игрок выстроил лестницу: ар, ара, араб, аргон. Победа, лестница высотой в пять ступеней построена (см. листинги 1-4).
72
№ 3 (27) 2010
I
OQ
ci
Рис. 9. Диаграмма деятельности, описывающая последовательность операций при вызове метода CompetitorRole.GetAnswer()
Листинг 1. Уточнение каркаса:
using System;
using System.Collections.Generic; //Подключаем библиотеку каркаса using GSEducation.WordPuzzleGame;
namespace GSEducation.FunnyStairs{
//Производим операцию наследования от класса GameManager public class FunnyStairsManager : GameManager{ public FunnyStairsManager(LanguageOfParticipants language, bool allowRepeatQuestions) : base(language, allowRepeatQuestions){ InitializeGame();
}
private void InitializeGame(){ //Создаем задание, которое нужно решить makePuzzle();
//Устанавливаем стратегию обработки действия игрока Rules.VerifyQuestionStrategy =
new VerifyQuestionStrategy(Umpire);
№ 3 (27) 2010
t
>ss
0
CQ
t CQ
s
CO CQ
1
I
1! 1
I i
I
I
t &
s
t §
Рис. 10. Диаграмма деятельности, описывающая последовательность операций при вызове метода GameRules.VerifyPlayerQuestion()
//Устанавливаем стратегию ответа на действия игрока Competitor.AnswerStrategy = new GetAnswerStrategy(Umpire);
}
private void makePuzzle(){
Random randomizer = new Random();
bool testResultIsGood = true;
List<string> alphabet = CharacterSet.Characters;
again:
if (alphabet != null){
//выбираем случайную букву
int currentIndex = randomizer.Next(0, alphabet.Count - 1); //выбираем случайную длину лестницы int stairsLength = randomizer.Next(4, 8);
74
№ 3 (27) 2010
string compLetter = ""; if (alphabet.Count > currentIndex){ Competitor.Puzzle = new WordPuzzle(); compLetter = alphabet[currentIndex];
//Устанавливаем обязательное условие, без которого невозможно решение задания //В данном случае это буква, с которой должны начинаться слова Competitor.Puzzle.CompulsoryCondition = compLetter; //Устанавливаем еще одно условие: длину лестницы
Competitor.Puzzle.InitialCondition = stairsLength.ToString();
}
//Проверяем, возможно ли решение задачи for (int i = 0; i < stairsLength; i++){
if (HolderOfKnowledge.GetWordsByParams(i + 3, compLetter[0]) == null) testResultIsGood = false;
}
}
//Если решение задачи невозможно, пробуем снова ее сгенерировать if (!testResultIsGood) goto again;
}
}
}
4
ва
to
Листинг 2. Уточнение стратегии ответа на действия со стороны игрока:
using System;
using GSEducation.WordPuzzleGame;
namespace GSEducation.FunnyStairs{
//Производим реализацию интерфейса IGetAnswerStrategy public class GetAnswerStrategy : IGetAnswerStrategy{ public GetAnswerStrategy(UmpireRole umpire){ m_Umpire = umpire;
}
private UmpireRole m_Umpire;
public GamePuzzleState GetAnswer(string[] question, out string answer) { GamePuzzleState puzzleState = GamePuzzleState.NotCompleted; answer = "";
//Проверяем длину полученной лестницы с длиной заданной if (question.Length == Convert.ToInt32(m_Umpire.Competitor.Puzzle.InitialCondition)) return GamePuzzleState.Completed; return puzzleState;
}
}
}
4..... 75
-ч ПРИКЛАДНАЯ ИНФОРМАТИКА
№ 3 (27) 2010 ' -
I
о
со
о &
со
is
U
0 £
1
л
§
Si 8
I
1 £
I
с
£ S
Si
I
л
is
t SS
Листинг 3. Уточнение стратегии проверки действий игрока:
using System;
using GSEducation.WordPuzzleGame;
namespace GSEducation.FunnyStairs{
//Производим реализацию интерфейса IVerifyQuestionStrategy public class VerifyQuestionStrategy : IVerifyQuestionStrategy { public VerifyQuestionStrategy(UmpireRole umpire){ m_Umpire = umpire;
}
private UmpireRole m_Umpire;
public QuestionVerificationResult VerifyQuestion(string[] question){ QuestionVerificationResult result =
QuestionVerificationResult.Correct; //Если длина текущей лестницы больше заданной if (question.Length >
Convert.ToInt32(m_Umpire.Competitor.Puzzle.InitialCondition)) return QuestionVerificationResult.Incorrect; //Производим проверку всех слов в лестнице for (int i = 0; i < question.Length; i++){ //Проверяем обязательное условие
if (question[i][0].ToString() != m_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;
}
}
return result;
}
}
}
Листинг 4. Использование готового компонента:
Объявляем переменные, инициализируем объекты, подписываемся на событие.
//WordGame - "фабрика" создания лингвистических заданий, не предусматривающаяся каркасом WordGame m_WordGame;
//В нашем случае m_ChosenPuzzleGame будет указывать на FunnyStairsManager m_WordGame = new WordGame(m_ChosenPuzzleGame);
//Начинаем игру. Метод вызовет операцию new FunnyStairsManager(language, allowRepeat) m_WordGame.StartCompetition(m_ChosenLanguage, m_AllowRepeatQuestions); //m_WordGame.Manager - объект типа FunnyStairsManager,
№ 3 (27) 2010
//Подписываемся на событие обработки действий игрока m_WordGame.Manager.QuestionProcessed += FS_QuestionProcessed; m_WordGame.Manager.StartGame();
Описываем процедуру обработки события
private void FS_QuestionProcessed(object sender, QuestionProcessedEventArgs e){ if (e.State == GamePuzzleState.NotCompleted){
MessageBox.Show("Продолжайте решение задания!");
}
if (e.State == GamePuzzleState.Completed){ MessageBox.Show("Поздравляем с победой!");
}
}
4
со
to
Обработка события будет происходить всякий раз после выполнения операции MakeGameStep().
//В качестве параметра передаем массив строк, представляющих лестницу m_WoгdGame. Manageг.MakeGameStep(...).
Заключение
В статье была представлена модель каркаса, реализация которой способствует упрощению процесса создания программных компонентов поддержки занятий лингвистической направленности. Приведен конкретный пример реализации детализации каркаса, что способствует более ясному пониманию его сути. Предложена классификация элементов повторного использования, в ней указано место каркаса.
С каждой новой платформенной технологией повышается уровень зрелости разработки программного обеспечения, что приводит к развитию индустриализации, а с ней и автоматизации. Сегодня как раз то самое время, когда повторное использование программных активов не просто возможно, благодаря развитию платформенных технологий и инструментария, поддерживающего перспективные методологии, но и необходимо для поддержания конкурентоспособности компании.
Список литературы
1. Басс Л., Клементс П., Кацман Р. Архитектура программного обеспечения на практике, 2-е издание. СПб.: Питер, 2006.
2. Бек К. Шаблоны реализации корпоративных приложений. М.: ООО «ИД Вильямс», 2008.
3. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. СПб.: Символ-Плюс, 2001.
4. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.: Питер, 2008.
5. Рамбо Д., Блаха М. UML 2.0: объектно-ориентированное моделирование и разработка, 2-е издание. СПб.: Питер, 2007.
6. Спольски Д. Лучшие примеры разработки программного обеспечения. СПб: Питер, 2007.
7. Cwalina K., Abrams B. Framework Design Guidelines. Conventions, Idioms, and Patterns for Reusable. NET Libraries, second edition. U. S. A.: Addi-son-Wesley, 2008.
8. Fowler M. Analysis Patterns: Reusable Object Models. U. S. A.: Addison-Wesley, 1997.
9. Fowler M. Patterns of Enterprise Application Architecture. U. S. A.: Addison-Wesley, 2002.
10. Parnas, D. L. On the Criteria to be Used in Decomposing Systems into Modules // Communications of the ACM. 1972.
11. Parnas, D. L. On the Design and Development of Program Families // IEEE Transactions on Software Engineering. 1976.
12. Prensky M. Digital Game-Based Learning. U. S. A.: McGraw-Hill, 2004.
