РАЗДЕЛ 6
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 378+519.25
О. Н. Лучко
Омский государственный институт сервиса
В. А. Маренко
Омский филиал Института математики им. С. Л. Соболева СО РАН
Моделирование компетентностного подхода
в образовательном процессе
В статье с системной позиции рассмотрен компетентностный подход в образовательном процессе. Приведены результаты анкетирования участников образовательного процесса и работодателей. Использован метод семантического дифференциала.
Ключевые слова: образовательный процесс, компетентностный подход, моделирование, семантический дифференциал, экспертное исследование.
В современных условиях мировым стандартом в образовательном процессе становится двухуровневая структура «бакалавр / магистр», которая является важной составляющей в Болонском процессе. От новой структуры высшего образования ожидается большее по сравнению с традиционной соответствие социально-экономическим реалиям. Это должно выразиться в реализации следующих преимуществ:
-
в большей гибкости образовательных программ;
-
повышении национальной и международной мобильности;
-
повышении эффективности взаимодействия высшего образования и сферы труда;
-
большей адекватности высшего образования индивидуальным потребностям.
При этом в высшем профессиональном образовании идет переход на позиции компетентностного подхода, в котором усиливается акцент на развитие творческих способностей обучаемых [1–3].
Представляет практический интерес вопрос о соответствии современного видения конечного результата обучения коллективом преподавателей вуза и руководителями образовательного процесса требованиям, предъявляемым работодателями к выпускникам (направление «прикладная информатика»). Следует отметить, что прикладная информатика как отрасль деятельности, где эффективно используются мощные программные системы, становится все более распространенной на рынке труда. Так, известна классификация IT-специальностей, согласно которой их общее число превышает 200. В качестве основы содержания подготовки студентов по данному направлению рассматривается Федеральный государственный образовательный стандарт высшего профессионального образования по направлению 230 700 – прикладная информатика [4].
Задачи современного образовательного процесса
Базовое вузовское образование формирует у обучающихся готовность действовать в изменяющейся профессиональной среде, а также позволяет сокращать сроки адаптации к практической деятельности. Доминанта в требованиях к современной сфере высшего образования состоит в том, чтобы выпускник, наряду с базовыми знаниями и соответствующим общим уровнем развития, мог дополнительно обучаться и оперативно перестраиваться. Задача современного образовательного процесса состоит в том, чтобы подготовить максимально адаптивного, мобильного выпускника, который в короткие сроки сможет подстроиться под требования работодателей. Большинство современных молодых специалистов не способно использовать свои знания для решения практических задач и психологически не подготовлено к реальной трудовой деятельности [5].
Компетентностный подход как основа высшего профессионального образования нормативно закрепляется в важнейших законодательных документах. Так, в проекте Федерального закона «Об образовании в Российской Федерации» указывается, что «профессиональное образование – вид образования, направленный на приобретение обучающимися в процессе освоения профессиональных образовательных программ знаний, умений, навыков и компетенций определенного уровня и объема, позволяющих вести профессиональную деятельность в определенной сфере и (или) выполнять работы по конкретной профессии или специальности» [6].
Особенность компетентностного подхода в сегодняшнем высшем образовании состоит в том, чтобы преодолеть оторванность различных дисциплин друг от друга, сосредоточиться на том, для чего получаемые знания могут быть использованы в трудовой сфере. Компетентностная позиция демонстрирует системный подход в образовании, т. к. концентрирует внимание на интегративных характеристиках качества подготовки выпускника как целостной личности. Важно фиксировать не только отдельные проявления потенциала личности, но и все его компоненты, включая возможные в будущем. Целостность рассматриваемому подходу придает позиция, с которой компетенции рассматриваются как своеобразный каркас для всего многообразия результатов обучения. Часто компетентностный подход даже определяют как метод моделирования результатов образования и их представления как норм качества высшего образования.
Наборы компетенций отражают результаты обучения, то, что именно студент будет знать, понимать или способен делать после завершения процесса обучения.
Текстовый вариант системы компетенций, приведенный в Федеральном государственный образовательном стандарте по направлению 230 700 – прикладная информатика, схематически представлена на рис. 1.
Стандарт включает в качестве обязательных 22 профессиональные компетенции, структура которых представлена двумя группами – общепрофессиональные компетенции и деятельности (проектная, организационно-управленческая и производственно-техническая, аналитическая, научно-исследовательская. Комплекс компонентов компетенций позволит реализовать гибкость подготовки специалистов путем сбалансированности общих и профессиональных составляющих. Общие компетенции помогут осуществлять анализ и синтез объекта исследования, принимать решения, адаптироваться, работать как в команде, так и самостоятельно. Эти компетенции связаны с воспитанием гражданина, развитием личности и формированием общественной ответственности у обучаемых. Профессиональные компетенции – навыки, методы и технические приемы, необходимые для деятельности в определенных предметных областях, отражают способности целесообразно действовать в соответствии с требованиями дела, самостоятельно решать проблемы, а также подвергать критической оценке результаты своей деятельности.
Р ис. 1. Система компетенций
Руководители образовательного процесса ставят задачу способствовать сближению общих и профессиональных компетенций. Вузу предоставляется право предусматривать и дополнительные компетенции с учетом направленности своей основной образовательной программы и, что особенно важно, мнения работодателей.
Важным аспектом компетентностной концепции является разрушение профессиональных замкнутостей, что не исключает требования высокого профессионализма в конкретных предметных областях, который предполагает наличие широкого набора навыков, способность переносить их из одной сферы занятости в другие, а также работать в группе, инициативность и другие социальные характеристики личности [7].
Построение обобщенных моделей
Федеральный государственный образовательный стандарт определяет систему компетенций, являющихся обязательными при разработке основных образовательных программ вуза. Вузовская система подготовки студентов должна выстраиваться вокруг проблемы повышения конкурентоспособности выпускников на рынке труда, которая включает разработку образовательных программ согласно требованиям времени, наполнение их разнообразными дисциплинами, соответствующими практиками с применением новых педагогических технологий и методического обеспечения [8].
Компетентностная модель обучения определит и цель, и содержание, и результаты обучения, в числе которых главными являются все же профессиональные компетенции, включающие такие компоненты, как проектная деятельность, организационно-управленческая, производственно-технологическая и аналитическая деятельность.
Разработана анкета в виде таблицы компетенций, предполагающая оценку интервьюируемыми значимости компонентов системы компетенций по методу семантического дифференциала. Например, нужно оценить некоторую компетенцию по непрерывной двухполюсной шкале. Ноль – отсутствие характеристики, 10 – максимальное присутствие характеристики. Опрашиваемый ставит метку на шкале там, где он считает нужным. Таким образом, с учетом психофизиологических особенностей человека, учитывались и понятия репрезентативной теории измерений, служащей основой теории экспертных оценок, прежде всего той ее части, которая связана с анализом заключений относительно качественных признаков объектов исследования.
По результатам обработки анкет, заполнявшихся представителями различных категорий – финансистами, производственниками, предпринимателями, – получен ряд моделей. Так как исследовались качественные характеристики будущих специалистов, то экспертные оценки в баллах считались измеренными в порядковой шкале. Для построения графического материала определялись средние баллы методом медианных рангов.
На рис. 2 представлены графические модели компетенций выпускника с точки зрения: 1) руководителей образовательного процесса, 2) преподавателей и 3) самих студентов.
Рис. 2. Компетентностная модель выпускника с точки зрения:
1) руководителей образовательного процесса, 2) преподавателей,
3) студентов
На графике видно, что на общепрофессиональные компетенции (1, 2, 3) взгляды руководителей и преподавателей не совпадают. Руководители считают, что этим компетенциям, как и научно-исследовательским (21, 22), надо уделять не меньше внимания, чем остальным.
Обеспечение трудоустройства выпускников вузов – один из критериев при оценке качества образования. В новых условиях и работодателю требуются более универсальные работники, и сами работники, чтобы быть востребованными на современном рынке труда, должны быть более универсальными и гибкими. В описываемых исследованиях финансисты отдавали предпочтение проектному и аналитическим компонентам, производственники – проектной, организационно-управленческой и производственно-технологической деятельности, предприниматели – только организационно-управленческой и производственно-технологической деятельности. На рис. 3 представлены графические модели позиции 1) руководителей финансовых структур, 2) производственников и 3) предпринимателей, которые предполагают наличие соответствующих компетенций у тех потенциальных специалистов своих учреждений и организаций, профессиональная деятельность которых будет связана с использованием информационных технологий.
Рис. 3. Компетентностные модели, которым отдают предпочтение
1) руководители финансовых структур, 2) производственники,
3) предприниматели
Компетенции персонализированы, воплощены в реальных способностях выпускников вуза – в их знаниях, умениях, навыках. Чтобы оценка выпускников вуза была реалистичной, необходимо представить рассматриваемый поток выпускников на фоне потоков специалистов такого же профиля, которые продуцируют другие вузы. Исследования будут продолжены в этом направлении.
Абстрактный взгляд на совокупность профессиональных компетенций изменяется вместе с динамикой общественной среды. Он должен корректироваться в соответствии с конечными результатами обучения. Компетентностный подход противостоит традиционному квалификационному подходу в плане формирования стратегии подготовки выпускников вуза с учетом всего многообразия реальных и возможных профессиональных задач. Преимущества компетентностного подхода сформулировала Уте Клемент – руководитель известной немецкой фирмы Holtec: «…если «квалификация» описывает функциональное соответствие между требованиями рабочих мест и целью образования, то компетентность должна включать возможность действовать адекватно ситуации в широких областях» [7].
Компетентностный подход в определенных пределах учитывает и квалификационные характеристики. Об этом свидетельствует различие компетенций в узком и широком смысле. Узкий взгляд означает следование правилам и процедурам, использование технических профессиональных навыков для выполнения типовых задач. А широкий взгляд дает стратегию обучения, направление профессионального совершенствования. В случае разработки общей образовательной программы по направлению «прикладная информатика» существенную помощь могут оказать квалификационные требования, разработанные ведущими специалистами IT-отрасли применительно к основным IT-специальностям (в их числе, например, «Специалист по информационным системам») [8].
Хотя компетенции и не в состоянии охватить все многообразие результатов обучения, но позволяют дать этим результатам, прежде всего качеству подготовки специалистов, интегрированные характеристики, включающие когнитивные, мотивационно-ценностные и эмоционально-волевые компоненты. Они ориентируют на «лучшее», на эффективную работу «в широком формате контекстов с высокой степенью саморегулирования и адаптивной реакцией на динамику обстоятельств и среды» с учетом будущих потребностей экономики.
Интегральный характер компетенций выражается в их междисциплинарной природе. Они являются результатом образовательных технологий, организационных форм обучения и учебной среды. Специалисты советуют при разработке стандартов компетентностного подхода отойти от «жесткого» «закрытого» нормирования содержания образования и осваивать «мягкие» «открытые» формы его проектирования [9].
Компетентностный подход как ориентир образовательного процесса – это мера совпадения образа и успеха молодого специалиста в профессиональной деятельности. Показателями качества результата являются востребованность выпускников на рынке труда и их трудовая мобильность. Очертить границы профессионального профиля сложно из-за широты профессиональных контекстов, в которых придется действовать выпускникам, и бесконечного разнообразия задач, которые ставит перед ними реальная жизнь.
Реализация концепции компетентностного подхода с соответствующими прогнозируемыми результатами позволяет проектировать объем, уровень, содержание теоретических и эмпирических знаний. Построение образовательного процесса в этом случае формирует измеримые результаты, понятные и студенту, и педагогу, и работодателю. Это делает процесс обучения прозрачным и контролируемым.
Библиографический список
-
Зимняя, И. А. Ключевые компетенции – новая парадигма результата образования / И. А. Зимняя // Высшее образование сегодня. – 2003. – № 5. – С. 34-42.
-
Болонский процесс: середина пути / под науч. ред. д-ра пед. наук, проф. В. И. Байденко. – М. : Исслед. центр проблем качества подготовки специалистов, 2005. – 379 с.
-
Байденко, В. И. Компетентностный подход к проектированию государственных образовательных стандартов высшего профессионального образования (методологические и методические вопросы) : методич. пособие. – 2-е изд. / В. И. Байденко. – М. : Исслед. центр проблем качества подготовки специалистов, 2005. – 114 с.
-
Федеральный государственный образовательный стандарт высшего профессионального образования по направлению 230 700 – прикладная информатика [Электронный ресурс]. – Режим доступа: http://www.edu.ru/db/mo/Data/d_09/prm783-1.pdf.
-
Фуколова, Ю. В. Если нужных кандидатов нет, наступает коллапс / Ю. В. Фуколова // Секрет фирмы. – 2008. – № 31(263). – С. 58–60.
-
Проект федерального закона «Об образовании в Российской Федерации» [Электронный ресурс]. – Режим доступа: http://zakonoproekt2010.ru/media/files/41d33d800a1ba82aab 25.pdf.
-
Решение VII Международной конференции «Высшее образование для XXI века», 18–20 ноября 2010 г. – М. : Московский гум. ун-т., 2010.
-
Литвинова, О. А. IT: обзор рынка и примеры классификации специальностей / О. А. Литвинова, А. В. Речинский // Прикладная информатика. – 2007. – № 4(10). – С. 12–39.
-
Квалификационные требования (профессиональный стандарт) в области информационных технологий. «СПЕЦИАЛИСТ ПО ИНФОРМАЦИОННЫМ СИСТЕМАМ» [Электронный ресурс]. – Режим доступа: http://www.apkit.ru/files/spez.doc.
© Лучко О Н., Маренко В. А., 2010
Авторы статьи: Олег Николаевич Лучко, кандидат педагогических наук, профессор, Омский государственный институт сервиса;
Валентина Афанасьевна Маренко, кандидат технических наук, доцент, Омский филиал Института математики им. С. Л. Соболева СО РАН.
Рецензент – Э. Б. Хвецкович, кандидат технических наук, доцент, НОУ ВПО «ОмГА».
УДК 004.94
А. С. Язовский
Омская гуманитарная академия
ПРИМЕНЕНИЕ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ ДЛЯ ТЕСТИРОВАНИЯ WEB-ИНТЕРФЕЙСА ИНФОРМАЦИОННЫХ СИСТЕМ УПРАВЛЕНИЯ
Статья посвящена проблемам тестирования клиентского web-интерфейса информационных систем управления с помощью имитационного моделирования.
Существующие библиотеки имитационного моделирования имеют ограничения в области использования. Рассматриваются особенности применения имитационного моделирования при работе с Java фреймворком Google Web Toolkit. Разработан механизм, использующий пре-генерацию кода для реализации mock-объектов для заданного интерфейса. Отмечены преимущества и недостатки предложенного метода.
Ключевые слова: тестирование, имитационное моделирование, mock-объект, reflection, интерпретатор, генератор, отложенное связывание.
Тестирование информационных систем – процесс исследования с целью получения информации о качестве продукта. К имитационному моделированию прибегают:
-
когда дорого или невозможно экспериментировать на реальном объекте;
-
затруднительно построить аналитическую модель, т. к. в системе имеется большое количество объектов моделирования: время, причинные связи, последствие, нелинейности, стохастические (случайные) переменные;
-
необходимо сымитировать поведение системы во времени.
Одной из реализаций имитационного моделирования в программировании являются mock-объекты.
Mock-объекты – тестировочный паттерн, суть которого состоит в замене объектов, используемых тестируемым кодом, на отладочные эквиваленты [1]. Например, для тестирования кода, обрабатывающего обрыв соединения с базой данных, вместо настоящего соединения можно использовать специальный mock-объект, постоянно выбрасывающий нужное исключение.
Мокирование реальных объектов или интерфейсов позволяет клиенту оставаться в неведении о том, какой объект он использует – реальный или фиктивный. Многие библиотеки для mock-тестирования позволяют программисту указывать, какие и в каком порядке методы будут вызываться и какие параметры будут переданы им, а также какие результаты будут возвращены. Таким образом, моделируется поведение сложных объектов, таких как сетевой сокет, что позволяет программисту выяснить, реагирует ли тестируемый класс должным образом на взаимодействие с другими классами.
Mock-объекты удобно использовать:
-
если заменяемый объект не обладает необходимым быстродействием;
-
заменяемый объект тяжело настраивать;
-
нужное поведение заменяемого объекта сложно смоделировать;
-
для проверки call-back функций;
-
для тестирования GUI.
Например. Есть класс CardChecker, который имеет один публичный метод check, принимающий в качестве параметра класс Card и введенный pin-код, а возвращающий ИСТИНА (в случае, если валидация карты прошла удачно) или ЛОЖЬ (в случае, если pin-код не соответствует данной карте). Внутри данного метода происходит обращение к методу класса CardStore – getPin с параметром Card, который возвращает pin-код данной карты, хранящийся в базе данных (ситуация сознательно упрощена). Схема взаимодействия между классами изображена на рис. 1.
Рис. 1. Схема взаимодействия между объектами без mock
Для того чтобы протестировать, как класс CardChecker обрабатывает положительный и отрицательный исход валидации, необходимо смоделировать две ситуации:
-
класс CardStore возвращает идентичный заданному pin-код,
-
класс CardStore возвращает не равный заданному pin-код.
Можно смоделировать такое поведение, подключившись к реальной (или тестовой) базе данных, и действительно проверять наличие или отсутствие запрашиваемой карты. Но данный подход противоречит основному принципу unit (блочного)-тестирования: тестирование методов какого-то класса программы должно проводиться в изоляции от остальной программы.
Для того чтобы протестировать метод check класса CardChecker изолированно, необходимо заменить CardStore на некую «заглушку», которая будет возвращать необходимый результат вне зависимости от окружения. Примерная схема подобного взаимодействия изображена на рис. 2.
Так называемая «заглушка» CardStore представляет собой пример мокирования объекта. Она заменила реальный CardStore и работает с CardChecker. При данном подходе во время написания тестов появляется возможность управлять «заглушкой» и указывать явно необходимый результат выполнения метода getPin.
Рис. 2. Схема взаимодействия c mock-объектом
На текущий момент существует несколько библиотек, реализующих mock-тестирование. В Java к наиболее популярным из них можно отнести [2]: jMock, SevenMock, EasyMock, Mockito.
В основе лежит одна идея: замена зависимостей реального объекта виртуальными с помощью создания proxy-класса, имплементирующего тот же интерфейс.
Схематично этот принцип изображен на рис. 3.
Рис. 3. Принцип работы mock-библиотеки
Из схемы видно, что mockController имеет доступ к метаданным, описывающим структуру мокируемого объекта. Механизм, который позволяет обращаться к метаданным объектов и динамически их строить, называется reflection. На этом механизме основаны все Java-реализации mock-объектов.
Java Reflection – это механизм, позволяющий осуществлять доступ к коду и динамически менять конструкции кода, используя возможности интерпретатора виртуальной машины, во время выполнения программы [3]. Важнейшими возможностями являются динамическое редактирование и конструирование метаданных классов. То есть в процессе работы программы можно изменять логику работы методов.
Программы, написанные на Java, после компиляции в байт-код исполняются интерпретатором виртуальной машины [3]. Это и позволяет получать необходимую метаинформацию о выполняемом коде и динамически его менять для реализации mock-объектов.
Таким образом, возникает проблема с компилируемыми языками программирования. Нет возможности во время выполнения программы изменять ее код, так как это потребовало бы перекомпиляции.
Еще одной проблемой является снижение производительности. Нагрузка интерпретатора дополнительными инструкциями по модификации кода в процессе выполнения замедляет программу.
Также существует риск возникновения исключительной ситуации, вследствие того что искомый класс может быть просто не найден (в Java это ClassNotFoundException).
Предлагается способ получения и создания метаинформации не во время выполнения, а на этапе компиляции программы – так называемая пре-генерация кода. Это требует описания всего необходимого для объекта, но позволяет полностью освободить интерпретатор от этой работы. По сути, происходит перекладывание полномочий с интерпретатора на компилятор.
Для примера рассмотрим реализацию этого паттерна в Google Web Toolkit (далее – GWT). Перед разработчиками GWT стояла проблема различной реакции web-приложения на конкретные браузеры. Например, браузер Internet Explorer многие вызовы JavaScript (getElementById, getElementsByName и т. д.) обрабатывает не так, как большинство браузеров, придерживающихся принятых web-стандартов.
Для решения данной проблемы используется принцип отложенного связывания.
Отложенное связывание (Deferred Binding) – это метод, используемый компилятором GWT для создания и выбора конкретной реализации класса на основе набора параметров [4].
В сущности, отложенное связывание – это GWT-ответ на Java Reflection, позволяющий GWT-разработчикам производить несколько вариантов приложений для разных браузеров и иметь только один из них действительно загруженный и запущенный в браузере.
Рис. 4. Принцип работы генератора в GWT
При использовании отложенного связывания есть несколько преимуществ:
-
снижается размер сгенерированного JavaScript-кода, таким образом, клиенту будет необходимо скачать только код, необходимый для запуска в определенном браузере,
-
сохраняется время разработчиков, т. к. автоматически генерируется код, реализующий интерфейс или создающий прокси-класс.
Генератор вызывается для получения имплементации класса до того, как произошло преобразование Java к JavaScript.
Принцип работы генератора приведен на рис. 4. На основании данной схемы появляется возможность использовать генератор как замену reflection в реализации mock-объекта.
Часть исходного кода, реализующего mock-объект с помощью пре-генерации, приведена ниже:
public class MockObjectGenerator extends Generator {
@Override
public String generate(
final TreeLogger logger,
final GeneratorContext context,
final String typeName
) throws UnableToCompleteException {
JClassType classType;
try {
classType = context.getTypeOracle().getType(typeName);
SourceWriter src = createSourceWriter(classType, context, logger);
JMethod[] methods = classType.getMethods();
for (JMethod method : methods) {
src.println(getMethodSource(method));
}
src.commit(logger);
return typeName + "Generated";
} catch (NotFoundException e) {
e.printStackTrace();
}
return null;
}
В процессе разработки программного обеспечения остро стоит проблема качества. Наличие ошибок в исходном коде приводит к неожиданным результатам работы программы. И если ошибка в текстовом редакторе не наносит непоправимого вреда, то ошибка в программе, управляющей атомной станцией, грозит обернуться бедствием планетарного масштаба.
Для того чтобы каким-то образом минимизировать количество ошибок, производится многократное тестирование выпускаемого программного обеспечения различными способами.
В данной статье рассмотрены mock-объекты и преимущества, которые дает их использование, а также проблема их реализации в компилируемых языках программирования.
С помощью пре-генерации кода разработан механизм, позволяющий генерировать mock-объекты для заданного интерфейса. Использование генерации вместо ресурсов интерпретатора:
-
позволяет повысить производительность программы, так как результирующий код не требует никакой дополнительной обработки [5],
-
повышает такой параметр, как надежность кода, так как все необходимые данные уже известны на этапе компиляции,
-
решает серьезную проблему реализации mock-объектов в компилируемых языках программирования.
Данный метод можно применять при тестировании:
-
на ранних этапах разработки, когда реализованы только интерфейсы взаимодействия,
-
для ускорения выполнения тестов (изолируя ресурсоемкие компоненты).
Из недостатков предложенного метода можно выделить недостаточную гибкость. Рассмотренная реализация в рамках GWT требует внесения всех мокируемых интерфейсов в конфигурационный файл.
Библиографический список
-
Кент, Бек. Экстремальное программирование: разработка через тестирование / Кент Бек. – СПб. : Питер, 2003. – 224 с. – ISBN 5-8046-0051-6, 0-321-14653-0.
-
Mock Objects [Электронный ресурс] / Сообщество London XP ; ред. Нэт Прайс ; Web-мастер Стив Фримен – Электрон. дан. – Лондон : Великобритания, 2010. – Режим доступа: http://www.mockobjects.com, свободный. – Загл. с экрана. – Яз. англ.
-
Создание корпоративных систем на базе Java 2 Enterprise Edition [Текст] : руководство разработчика : [пер. с англ.] / Поль Дж. Перроун, Венката С. Р. «Кришна», Р. Чаганти [и др.]. – М. : Вильямс, 2001. – 1179 с. ; Перевод изд.: Building Java Enterprise systems with J2EE / Paul J. Perrone, Venkata S. R. (Krishna), R. Chaganti. Indianapolis. – 5000 экз. – ISBN 5-8459-0168-5 (в пер.).
-
Официальное руководство для разработчиков Google Web Toolkit [Электронный ресурс]. – Режим доступа: http://code.google.com/intl/ru-RU/webtoolkit/doc/latest/DevGuide.html.
-
Google Web Toolkit Developer’s Guide [Электронный ресурс] / Документация разработчиков Google Web Toolkit ; Web-мастер Google inc. – Электрон. дан. – Маунтин-Вью : США, 2010. – Режим доступа: http://code.google.com/intl/ru-RU/webtoolkit/doc/latest/DevGuide.html, свободный. – Загл. с экрана. – Яз. англ.
© Язовский А. С., 2010
Автор статьи – Антон Сергеевич Язовский, аспирант, НОУ ВПО «ОмГА», e-mail: yazovsky@gmail.com.
Рецензент – Э. Б. Хвецкович, кандидат технических наук, доцент, НОУ ВПО «ОмГА».
Достарыңызбен бөлісу: |