CC BY
36
• Безболезненная замена и изменение каждого из элементов системы (другие алгоритмы расчета, способы хранения данных, визуальные представления и т.д.);
• Скорость разработки;
• Легкость поддержки кода.
В современном мире нет ничего статичного, и, пожалуй, в наибольшей степени это касается программного обеспечения. Объемы и сложность современных приложений (как среди «настольного» ПО, так и среди серверного и веб-сервисов) растут с пугающей скоростью. Любое приложение профессионального уровня представляет собой сложную, комплексную систему, которую невозможно воплотить в жизнь, не введя в процесс разработки определённый уровень абстракции. MVC позволяет легко превратить тысячи строк кода в стройную и логично устроенную систему, которую легко можно объять взглядом одного разработчика, и лишает разработку и последующее развитие кода множества проблем по интеграции нового кода со старым.
В настоящее время паттерн Model-View-Controller широко используется в php-фреймворках (Symfony, CodeIgniter, Kohana, Yii и тд), а также в ASP.NET, Django, Ruby On Rails и множестве других разработок. Сегодня MVC можно назвать стандартом де-факто в веб-разработке, как, например, использование реляционных баз данных - они подходят не для всех задач, но для большинства; а в случаях, когда они не подходят, использование нестандартных решений порой вызывает больше проблем (например, с обучением специалистов), нежели не совсем подходящие, но более привычные средства.
Литература
1. http://ru.wikipedia.org/wiki/Шаблон_проектирования
2. http://msdn.microsoft.com/en-us/library/ff649643.aspx
3. http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
4. http://www.math.rsu.ru/smalltalk/gui/mvc-rus.pdf
УДК 004.75
РАСПРЕДЕЛЕННЫЙ ТЕСТИРУЮЩИЙ КЛИЕНТ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ПРОВЕДЕНИЯ СОРЕВНОВАНИЙ ПО ПРОГРАММИРОВАНИЮ1
Визовитин Николай Валерьевич, магистрант, Новосибирский Государственный Университет,
Россия, Новосибирск, vizovitin@gmail. com
Введение
Многие современные соревнования по программированию (например, ACM ICPC) для оценки решений участников используют ту или иную специализированную тестирующую систему. Как правило, такие системы позволяют исполнять программу, написанную участником, в автоматическом режиме на заранее определенном наборе сценариев. В простейшем случае программа запускается на серии предварительно подготовленных тестов. Кроме того, осуществляется контроль над используемыми программой ресурсами, а также обеспечивается изоляция и равноправие при исполнении различных решений. Примером таких систем могут служить ejudge, PCMS2, PC2, NSUts [1].
Большинство автоматических систем тестирования имеют клиент-серверную архитектуру. В рамках такого разделения сервер отвечает за взаимодействие с пользователями и принятие решений участников на проверку. Но непосредственно проверка корректности решений осуществляется на нескольких тестирующих клиентах. Участники не имеют прямого доступа к тестирующим клиентам. Как правило, тестирующие клиенты запускаются на отдельных физических машинах, равно как и сервер. Основная причина
1 Работа выполнена при проведении НИР в рамках реализации ФЦП «Научные и научно-педагогические кадры инновационной России» на 2009 - 2013 годы, ГК № П262 от 23.07.2009.
102
такого разделения - ресурсоемкость задачи тестирования. Такая архитектура также понижает связность компонентов системы и позволяет изолировать сбои отдельных клиентов. В случае, если один из клиентов вышел из строя, остальные продолжат свою работу и имеющиеся работы по проверке будут перераспределены на оставшиеся клиенты.
Обычно сеанс проверки тестирующим клиентом одного решения включает в себя получение исходного текста решения с сервера, его компиляцию, запуск на серии тестов, сверку результатов с эталонными и отправку результатов проверки на сервер. Запуск скомпилированного решения (как и некоторые другие задачи) производится в специализированной изолирующей среде, гарантирующей безопасное исполнение произвольного кода и накладывающей определенные решаемой участником задачей ограничения на доступные ресурсы.
Большинство тестирующих систем используют свою собственную реализацию тестирующего клиента, удовлетворяющую нуждам проведения отдельных соревнований и тренировок. Несмотря на то, что наблюдается движение в сторону свободного программного обеспечения, многие соревнования по программированию по-прежнему проводятся на платформе Microsoft Windows. Настоящая работа описывает особенности дизайна и реализации нового тестирующего клиента, обладающего рядом уникальных свойств и архитектурой, ориентированной на высокую отказоустойчивость, расширяемость и независимость от используемого сервера.
1. Причины создания распределенного тестирующего клиента
Многие из используемых ныне тестирующих клиентов устроены достаточно просто. Каждый клиент не зависит от других и общается напрямую с сервером, последовательно выполняя получаемые задачи. Изолирующая среда [2], как правило, использует лишь средства операционной системы для ограничения ресурсов, доступных изолируемому процессу. Такие клиенты обычно запускаются на отдельных физических машинах одинаковой конфигурации. При этом решается одна достаточно узкая задача - проверка решений участников в рамках одной или небольшого количества моделей запуска и оценки. При возникновении необходимости сильного изменения модели запуска решений (например, для обеспечения поддержки интерактивных или игровых задач с несколькими участниками), модели оценки суммарного результата или другого аспекта тестирующего клиента, необходимо соответствующим образом модифицировать сам тестирующий клиент и заново развернуть его на целевых машинах. В случае отказа какого-либо из тестирующих клиентов серверу необходимо будет опознать эту ситуацию и перераспределить задачи этого клиента на другие тестирующие клиенты. К сожалению, обычно нет возможности восстановить работу тестирующего клиента в автоматическом режиме, поэтому часто это делают вручную. Перечисленные особенности и недостатки характерны для многих тестирующих клиентов, в том числе и для тестирующего клиента, используемого в качестве основного, в олимпиадной тестирующей системе Новосибирского государственного университета NSUts.
Для решения этих и других проблем ведется разработка нового тестирующего клиента. Новый клиент является распределенным - он также может содержать несколько тестирующих узлов, но они являются подчиненными другим узлам или основному узлу. Основной узел фактически является единственным, непосредственно взаимодействующим с сервером. Он получает задачи и распределяет их между подконтрольными ему узлами, а также следит за их работоспособностью. Это позволяет, с одной стороны, полностью сосредоточить логику, относящуюся к тестированию, в тестирующем клиенте. Серверу при этом достаточно знать лишь то, каким образом послать задачу на проверку и как передать тестирующему клиенту данные. С другой стороны, такой подход дает возможность централизованно управлять и следить за процессом тестирования, вне зависимости от используемой тестирующей системы. Также такая архитектура позволяет ввести единую систему мониторинга работоспособности отдельных узлов, не зависящую от тестирующей
103
системы. Отметим, что независимость от тестирующей системы не означает невозможность интеграции соответствующих данных и управляющих элементов в ее интерфейс.
2. Изолирующие среды
Одной из основных задач, решаемых новым тестирующим клиентом, является поддержка нескольких изолирующих сред. Классический подход к построению изолирующей среды посредством использования стандартных средств ОС для ограничения доступа к ресурсам показал свою уязвимость к ряду целенаправленных атак [3]. К таким атакам, в частности, относятся атаки, направленные на ядро ОС [4]. Поэтому в ходе работы была создана изолирующая среда на основе технологий виртуализации. В этой изолирующей среде используется виртуальная машина Oracle VirtualBox [5] с оптимизированным настройками и специальным образом подготовленный минимальный образ гостевой ОС на основе Windows XP. В образе гостевой ОС были оставлены лишь самые необходимые для проведения на нем тестирования компоненты. В результате была получена изолирующая среда с приемлемыми ресурсными издержками, обеспечивающая высокий уровень безопасности и изоляции. Использование изолирующей среды на основе технологий виртуализации имеет и другие существенные преимущества, например, возможность запуска более одного экземпляра изолирующей среды на одной машине.
Новый тестирующий клиент поддерживает использование нескольких изолирующих сред, а также, в некоторых случаях, вложенное их исполнение. Так, поддерживается и изолирующая среда на основе технологий виртуализации, и реализация классической изолирующей среды для Windows [2]. Отметим, что первая использует облегченную версию второй для более точного контроля за доступными приложению ресурсами. Новые типы изолирующих сред могут быть добавлены к тестирующему клиенту в виде модулей. Поддержка нескольких изолирующих сред и изолирующая среда на основе технологий виртуализации являются уникальными особенностями среди публично доступных тестирующих клиентов.
Дополнительные модели запуска решений и их оценки также могут быть добавлены в виде модулей тестирующего клиента. Так, например, может быть задана «игровая» модель запуска, в которой одновременно запускаются два или более решений различных участников и связываются между собой и управляющей программой для организации игры. На данный момент реализовано две модели оценки решений - по системе ACM и по школьной системе. Первая подразумевает исполнение решения до первой ошибки. В рамках второй каждому тесту сопоставляется некоторое количество баллов, баллы за правильно пройденные тесты суммируются.
3. Организация взаимодействия между компонентами системы
Протокол взаимодействия клиента и сервера версионирован и расширяем. Единица передачи данных в рамках этого протокола - сообщение. Сообщения, за небольшим количеством исключений, являются документами XML. В качестве транспортного протокола используется HTTP, однако транспортный уровень может быть заменен. Так, его легко заменить протоколом TCP или HTTPS (например, с целью обеспечения безопасной передачи данных). Несмотря на использование на транспортном уровне протокола, подразумевающего взаимодействие типа запрос-ответ, передача и обработка сообщений асинхронна - после передачи сообщения источник не дожидается ответа приемника. Протокол имеет декларативный характер, в отличие от более распространенных протоколов вида «удаленный вызов процедур» (RPC) [6]. Таким образом, он ориентирован в первую очередь на передачу данных и исполнение запросов, а не на выполнение команд. Для передачи и описания данных в сообщениях используются так называемые артефакты. Артефакт имеет тип, идентификатор, полезную нагрузку в виде интерпретируемых данных, набор зависимостей от других артефактов (отражающих зависимости по данным), и метаданные, указывающие, как следует интерпретировать переносимые артефактом данные.
104
Для организации взаимодействия между узлами тестирующего клиента используется аналогичный протокол. В качестве транспортного протокола в этом случае используется TCP для оптимизации быстродействия посредством исключения многократных установок соединения, присущих HTTP. Тестирующие узлы взаимодействуют друг с другом в соответствии со своими положениями в общей иерархии, однако при посредничестве родительского узла может быть установлена прямая связь между двумя узлами из различных поддеревьев. Это позволяет уменьшить издержки во время передачи больших объемов данных, например в случае, если результаты работы решения участника должны быть отправлены на другой узел с целью проверки. Такая ситуация может иметь место при специализации узлов по выполняемым задачам (например, компиляция, исполнение и проверка), что также возможно только при использовании распределенного тестирующего клиента.
4. Особенности реализации тестирующего клиента
В качестве основного языка для реализации тестирующего клиента был выбран Python, а именно его диалект, реализуемый интерпретатором Stackless Python [7]. Python является достаточно простым и элегантным языком с богатой стандартной библиотекой. Он также является мультиплатформенным, и его использование облегчает одновременную разработку под операционные системы семейства Windows и Linux. Так как в некоторых сценариях тестирующий клиент должен асинхронно обрабатывать большие объемы данных, выбор пал на Stackless Python, как реализацию, предоставляющую эффективные средства выполнения этой задачи. Основная особенность этого интерпретатора заключается в улучшенной поддержке многопоточности.
Развертывание типовой сборки тестирующего узла уже сейчас является достаточно простой задачей, для выполнения которой не нужен специалист. Однако при изменении кода тестирующих узлов по-прежнему необходимо их повторное развертывание. Планируется заменить установку полноценного тестирующего узла установкой лишь базового агента, который, получив необходимые компоненты от основного узла, сможет стать полноценным тестирующим узлом без вмешательства пользователя. Аналогичным образом обновления программного обеспечения узлов могут быть применены централизованно с основного узла.
Новый тестирующий клиент включает систему мониторинга работоспособности и загруженности тестирующих узлов. Эта подсистема является внешней по отношению к тестирующим узлам и состоит из агентов на физических машинах, где работают контролируемые объекты, и системы опроса состояния узлов. При существенном отклонении от штатного режима функционирования (например, тестирующий узел не отвечает на запросы) система мониторинга посылает сигнал соответствующему агенту, который завершает все процессы, порожденные тестирующим узлом, и перезапускает его. Администратор тестирующей системы при этом уведомляется об отклонениях в работе.
Выводы
В результате работы над новым тестирующим клиентом была создана изолирующая среда на основе технологий виртуализации и прототип клиента. Прототип использовался как вторичный тестирующий клиент в системе NSUts, а также подвергался синтетическим тестам. Новый клиент показал хорошие результаты, как по производительности, так и по стабильности работы. Планируется его апробация на нескольких соревнованиях по программированию.
После достижения необходимого уровня качества разрабатываемый тестирующий клиент будет опубликован и доступен для использования в других тестирующих системах. Использование такого клиента позволит разработчикам тестирующих систем, с одной стороны, сфокусироваться на реализации необходимой функциональности и бизнес-логики системы. И, с другой стороны, даст платформу для создания тестирующего клиента, удовлетворяющего определенным нуждам. Кроме того, несмотря на достаточно узкую решаемую задачу - запуск недоверенного кода, исполняющегося короткое время, с
105
последующей оценкой результатов - разрабатываемый тестирующий клиент может быть использован не только на соревнованиях по программированию, но и, например, для организации сетевого сервиса по удаленному исполнению кода.
Литература
1. Боженкова Е.Н., Иртегов Д.В., Киров А.В., Нестеренко Т.В., Чурина Т.Г. Автоматизированная система тестирования NSUts: Требования и разработка прототипа // Вестник НГУ, серия: Информационные технологии. -N4, Т.8, 2010. - С. 46-53.
2. Киров А.В. Изолирующая среда для запуска тестовых прикладных программ // Материалы VII Всероссийской научно-практической конференции студентов, аспирантов и молодых ученых «Студент и современные информационные технологии». - Томск: Томский политехн. ун-т. 2009. - С. 285-286.
3. David Maynor. Metasploit Toolkit for Penetration Testing, Exploit Development, and Vulnerability Research - Syngress, 2007 - 350 p.
4. Greg Hoglund, Jamie Butler. Rootkits: Subverting the Windows Kernel - 1st Edition - Addison Wesley, 2005 - 352 p.
5. Официальный сайт виртуализирующего ПО Oracle VirtualBox. [Электронный ресурс]. URL: http://virtualbox.org/
6. Joe Johnston, Edd Dumbill, Simon St.Laurent, John Posner. Programming Web Services with XML-RPC - 1st Edition - O’Reilly Media, 2001 - 230 p.
7. Официальный сайт интерпретатора Stackless Python. [Электронный ресурс]. URL: http://www.stackless.com/
УДК 519.682.4+ 371.32
ОБУЧЕНИЕ СТАНДАРТНОЙ БИБЛИОТЕКЕ ШАБЛОНОВ STL ЯЗЫКА С++
НА ПРИМЕРЕ РАЗРАБОТКИ КОМПРЕССОРА ПО МЕТОДУ ХАФФМАНА
Штанюк Антон Александрович, к.т.н., доцент, Нижегородский коммерческий институт, Россия,
Нижний Новгород, shtan@land.ru
Стандартная библиотека шаблонов языка C++ является мощным средством обобщённого и объектно-ориентированного программирования, значительно упрощающим процесс разработки крупных программных систем. Обучение данному средству очень важно в современных курсах подготовки специалистов в области информационных систем. Однако часто преподаватели испытывают недостаток в реальных примерах, на которых бы иллюстрировалось использование элементов STL. В рамках настоящей работы предлагается такой пример, имеющий практическое значение: программа-компрессор, сжимающая отдельные файлы.
Компрессор по методу Хаффмана [1] относится к классу программ, сжимающих файлы за счёт уменьшения избыточности, вызванной использованием равномерного ASCII-кодирования при наличии разных вероятностей появления элементов алфавита. Несмотря на то, что строковое сжатие более эффективно в практическом отношении, символьное сжатие хорошо иллюстрирует идеи теории информации, а также требует использования множества конструкций языка программирования при реализации, позволяя достичь целей обучения. В настоящей работе речь пойдёт об использовании стандартной библиотеки шаблонов при разработке компрессора. Данный пример хорошо подходит для иллюстрации возможностей объектного подхода при решении задач с привлечением контейнеров и алгоритмов STL [2] и может быть рекомендован в качестве учебного примера в рамках курсов по объектноориентированному программированию на С++.
Компрессор принимает на вход обрабатываемый файл (1) и анализирует его. Результатом анализа выступает частотная таблица символов (байт) исходного файла (2). На основе этой таблицы генератор кода строит бинарное дерево Хафманна, необходимое для получения префиксного кода (3), который наилучшим образом подходит для представления
106
