Использование предметно-ориентированных языков для повышения продуктивности создания программных продуктов
Скачать 356.11 Kb.
|
Использование предметно-ориентированных языков для повышения продуктивности создания программных продуктовЦитирую и пересказываю Теоретический анализ и переход к моим идеям Научная новизна и переход к новому
На основе анализа развития языков программирования делается вывод, что предметно-ориентированный подход может стать следующим шагом эволюции языков программирования и существенно повысить продуктивность и качество разработки программных продуктов. В статье проводится обзор и анализ описанных в литературе методик применения предметно-ориентированного подхода, выявляются их общие черты и на основе анализа их недостатков формулируется новая методика его применения. ВведениеОбзор литературы по предмету исследования с анализом его исторического развития, постановка задачи В статье “Ориентация на язык” (1) проблема формулируется следующим образом: “впечатляющий набор современных инструментов для анализа, проектирования, рефакторинга1 и реинжиниринга2 предназначен, по сути, для сокращения разрыва между проектом системы и ее реализацией в исходном коде”. Проект системы – набор согласованных решений о том, как программная система будет работать, какова будет реакция на различные события, например, на действия пользователя. Классическим способом разработки программных продуктов является составление требований к системе в форме документации и написание программного кода только после фиксации проекта. Проблема состоит в том, что требования к системе не являются неизменными, они уточняются и видоизменяются по мере развития представлений пользователей о работе системы. Изменение требований ведёт к соответствующему изменению проекта, которое влечёт изменение исходного кода, для проверки корректности которого после изменений необходимо повторное тестирование. По мере развития системы стоимость внесения изменений непрерывно растёт. Возможно, решение проблемы в том, чтобы сразу излагать бизнес-требования на формальном языке, доступном компьютеру? Как создать подходящий язык для этого? Автор приходит к выводу, что универсальные языки программирования для этой цели непригодны. Универсальные языки моделирования UML и XML тоже не подходят. XML-конструкции громоздки (обратная сторона самоописательности XML). Для описания всех аспектов проекта в виде UML-диаграмм тоже могут потребоваться слишком громоздкие диаграммы. Получается, что языки с требуемыми свойствами нужно создавать, причём особенный набор языков для каждого типа проектируемых систем, поскольку понятия, на которых основана, например, бухгалтерская программа, сильно отличаются от понятий системы для автоматического управления подводного аппарата. Для таких языков существует устоявшийся термин - DSL (Domain-Specific Language, специализированный язык предметной области, предметно-ориентированный язык) – которым мы и будем пользоваться в дальнейшем. Методику программирования же называют языково-ориентированное программирование. Предметно-ориентированный язык программирования (англ. domain-specific programming language, domain-specific language, DSL) – язык программирования, специально разработанный для решения определённого круга задач, в отличие от языков программирования общего назначения, таких, как С/C++, Java, или языков моделирования общего назначения наподобие UML, Postscript, SQL и др. Проектирование формальных языков “c нуля” - сложная задача. Действительно, при классической схеме разработки любого языка нужно написать много кода для распознавания исходных текстов на этом языке и их погружения в объектную модель, пригодную для дальнейших манипуляций. Кроме того, даже при условии, что эта работа проделана, возникает ряд вопросов: Какова стоимость внесения изменений в разработанный язык? Если для того, чтобы изменить какое-то понятие предметной области, нужно "перекроить" весь код распознавателя, то этот подход слишком затратен. И главное: предположим, объектная модель получена. Что делать дальше? Ведь модель еще нужно связать с языком реализации системы. В (1) автор пишет, что при написании программ существуют две стратегии: записать, что нам нужно сделать (декларативные языки); составить план конкретных действий (императивные языки: C++, Java, C#). Данное разделение является не совсем точным, поскольку на практике и в декларативных языках часто используется описание как что-то сделать, и программу императивном языке можно понимать как последовательность инструкций “что нам нужно сделать”. Значение имеет уровень языка (приближенность его к платформе или к языку предметной области), нежели вид языка (декларативный или императивный). Для декларативных языков характерны более емкие и компактные конструкции. Тем не менее, в настоящее время больше используются императивные языки, а основной серьезной промышленной нишей для декларативных языков являются технологии баз данных (язык SQL). Причина в том, что, несмотря на изящество, компактность и концептуальную простоту декларативных языков их применение оправданно только при условии, что предметная область задачи четко определена. Именно этим обстоятельством и объясняется успех SQL, ведь абстракции, на которых построена работа с реляционными базами данных, давно изучены и хорошо известны. При проектировании DSL актуален следующий вопрос: нужно ли вносить в него императивные конструкции (условные операторы и циклы)? Не потеряем ли мы в результате то, к чему стремимся: получение простого языка, на котором записана лишь самая суть проекта, без утомительных деталей реализации? Можно сказать, что императивные конструкции целесообразно использовать лишь тогда, когда это продиктовано спецификой предметной области задачи (т.е. в предметной области используются списки действий). Например, если в постановке задачи часто употребляется слово «коллекция элементов» и говорится о задачах добавления/удаления/поиска элементов, введение в DSL понятия «цикл для работы с коллекциями» способно существенно упростить решение. Декларативные конструкции проще моделировать (сокращаются затраты на проектирование DSL), к тому же зачастую они легче воспринимаются и несут больше информации о проекте. В статье говорится, что при отборе языковых конструкций для предметно-ориентированного языка следует использовать слова, при помощи которых сформулировано задание. Предлагается следующая последовательность шагов при программировании с использованием предметно-ориентированных языков:
В статье (2) Сергей Дмитриев формулирует проблему традиционного программирования так: большие временные задержки в реализации идей. Наиболее серьезная проблема состоит в том, что между моментом, когда точно известно, как решить задачу, и моментом, когда удаётся "объяснить" это компьютеру, написав программу, проходит огромный промежуток времени. Можно объяснить проблему и решение другому программисту за считанные часы, но кодирование займет на порядок больше времени. Ведь при общении с программистом используется богатый естественный язык, компьютеру же приходится всё «объяснять» на языке программирования общего назначения, который существенно менее выразителен. Современные языки программирования, как правило, позволяют выразить десятки концепций. Естественный язык позволяет лаконично выразить десятки тысяч концепций. Таким образом, объясняя программу программисту, можно излагать общие идеи – а компьютеру приходится растолковывать в деталях каждый шаг. Сейчас большую часть времени, которое тратится на «программирование», занимают попытки выразить естественно-языковые концепции в терминах абстракций языка программирования – процесс сложный, не особо творческий и не эффективный. Например, сегодня значительная часть времени разработки тратится на объектно-ориентированное проектирование. В целом, это весьма творческий процесс составленияклассов, иерархий, отношений и т.п. Цель этого занятия – выразить программу в объектно-ориентированных терминах классов и методов. Процесс проектирования необходим, потому что классы и методы – единственные абстракции, понятные объектно-ориентированным языкам. Казалось бы, процесс необходимый и творческий, но в рамках языково-ориентированного программирования (ЯОП) объектно-ориентированное проектирование не нужно вообще. Рассмотрение существующих точек зрения, критический анализ и сопоставление Авторы упомянутых статей сходятся в мнении, что предметно-ориентированное программирование необходимый дальнейший шаг. Различия в статьях в основном терминологическое, что свидетельствует, что область ещё развивается и единая терминология не устоялась. Методы создания программных продуктов и их недостатки. Чтобы поддерживать систему опытные разработчики и архитекторы рекомендуют: пользуйтесь шаблонами проектирования (при этом снижаются риски, связанные с неудачным выбором архитектуры); периодически проводите ревизии проекта; делайте архитектуру многослойной с минимальной зависимостью между слоями; прототипируйте, выпуская сборки как можно чаще; определяйте возможные направления будущих изменений проекта. Этот список можно продолжить, но подобные рекомендации позволяют лишь снизить риски, обусловленные расхождением проекта и исходного кода. Суть проблемы состоит в том, что высокоуровневые аспекты проекта выражаются и документируются в терминах естественного языка (каким является, например, русский или английский), тогда как код реализации пишется на каком-нибудь формальном языке (C++, Java, C#). И между двумя этими типами языков лежит целая пропасть. (2) Процесс создания программного продукта можно представить какпошаговый переход от абстрактного (общего) представления о программе к всё более конкретному представлению – поэтапная конкретизация. Всё начинается с абстрактной идеи – каким должен быть программный продукт. Затем идея дополняется более конкретными требованиями к выполняемым функциям, удобству интерфейса, надежности, совместимости и т. д. Требования конкретизируют и формализуют в виде текста, схем, диаграмм. На основе требований происходит выбор конкретных технологий, аппаратно-программных платформ и способов реализации. Далее формулируют, какие в системе будут компоненты, модули, классы, алгоритмы. В конце концов, возникает предельно конкретный машинный код. Представление о создании программного продукта как последовательной конкретизации позволяет получить чёткое направление дальнейшего развития продукта. Если неясно, как дальше развивать программный продукт –сформулировать (зафиксировать) вновь появившиеся требования к системе, формализовать их, далее перевести их на более конкретный язык схем и алгоритмов, чтобы потом перевести в ещё более конкретный программный код. Важно то, что на всех этапах конкретизации программа записана на некотором языке (или нескольких языках, текстовых или графических). На этапе идей и требований это естественный язык (русский, английский) и схемы с “произвольными” обозначениями. Далее это первое представление программы переводят на общепринятые языки схем (UML-диаграммы, например). Затем и это представление переводится на различные псевдокоды, а затем, или сразу, на языки программирования. Каждый раз фиксация очередного представления программы на языке позволяет рассматривать, анализировать, критиковать и совершенствовать систему множеству лиц. Предметно-ориентированный подход предлагает выделять сущности языка, чтобы затем можно было на этом языке описывать различные задачи предметной области, а общая исполняющая среда интерпретировала бы задачи (исполняла бы их). При создании языка программирования, на котором составляются программы, описывающие задачи в конкретной предметной области, возникает проблема, которая состоит в том, что если ввести слишком мало элементов языка, то многие задачи будут описываться длинными и неудобными конструкциями, например, сложно выглядят формальные описания теорем для систем автоматического доказательства. [Примеры… вставить примеры описания теорем на языке формальной логики.] Если же, напротив, ввести слишком много синтаксических конструкций, то такой язык будет сложен для реализации. [Ссылки… источники… ссылки на …. Современные концепции языков программирования.] Получается,что при создании языка нужно найти приемлемый баланс количества языковых конструкций. На что же ориентироваться, как узнать какой он должен быть? При поиске необходимого и достаточного набора конструкций языка можно опереться на развитие естественного языка, который постоянно оптимизируется в процессе эксплуатации, для сокращения длинных и чрезмерно сложных понятий вводятся новые короткие слова-понятия, постоянно уточняется смысл существующих слов, отмирают слова, в которых уже отпала необходимость. Современные методики создания программных продуктов. Объектно-ориентированное программирование. Объектно-ориентированное программирование (ООП) — парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием, — прототипов). Класс — это тип, описывающий устройство объектов. Понятие «класс» подразумевает некоторое поведение и способ представления. Понятие «объект» подразумевает нечто, что обладает определённым поведением и способом представления. Говорят, что объект — это экземпляр класса. Класс можно сравнить с чертежом, согласно которому создаются объекты. Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области. Класс является описываемой на языке терминологии (пространства имён) исходного кода моделью ещё не существующей сущности, т. н. объекта. Объект — сущность в адресном пространстве вычислительной системы, появляющаяся при создании экземпляра класса (например, после запуска результатов компиляции (и линковки) исходного кода на выполнение). Прототип — это объект-образец, по образу и подобию которого создаются другие объекты. Появление в ООП отдельного понятия класса закономерно вытекает из желания иметь множество объектов со сходным поведением. Класс в ООП — это в чистом виде абстрактный тип данных, создаваемый программистом. С этой точки зрения объекты являются значениями данного абстрактного типа, а определение класса задаёт внутреннюю структуру значений и набор операций, которые над этими значениями могут быть выполнены. Желательность иерархии классов (а значит, наследования) вытекает из требований к повторному использованию кода — если несколько классов имеют сходное поведение, нет смысла дублировать их описание, лучше выделить общую часть в общий родительский класс, а в описании самих этих классов оставить только различающиеся элементы. Необходимость совместного использования объектов разных классов, способных обрабатывать однотипные сообщения, требует поддержки полиморфизма — возможности записывать разные объекты в переменные одного и того же типа. В таких условиях объект, отправляя сообщение, может не знать в точности, к какому классу относится адресат, и одни и те же сообщения, отправленные переменным одного типа, содержащим объекты разных классов, вызовут различную реакцию. Отдельного пояснения требует понятие обмена сообщениями. Первоначально (например, в том же Smalltalk) взаимодействие объектов представлялось как «настоящий» обмен сообщениями, то есть пересылка от одного объекта другому специального объекта-сообщения. Такая модель является чрезвычайно общей. Она прекрасно подходит, например, для описания параллельных вычислений с помощью активных объектов, каждый из которых имеет собственный поток исполнения и работает одновременно с прочими. Такие объекты могут вести себя как отдельные, абсолютно автономные вычислительные единицы. Посылка сообщений естественным образом решает вопрос обработки сообщений объектами, присвоенными полиморфным переменным — независимо от того, как объявляется переменная, сообщение обрабатывает код класса, к которому относится присвоенный переменной объект. Однако общность механизма обмена сообщениями имеет и другую сторону — «полноценная» передача сообщений требует дополнительных накладных расходов, что не всегда приемлемо. Поэтому в большинстве ныне существующих объектно-ориентированных языков программирования используется концепция «отправка сообщения как вызов метода» — объекты имеют доступные извне методы, вызовами которых и обеспечивается взаимодействие объектов. Данный подход реализован в огромном количестве языков программирования, в том числе C++, ObjectPascal, Java, Oberon-2. В настоящий момент именно он является наиболее распространённым в объектно-ориентированных языках. Концепция виртуальных методов, поддерживаемая этими и другими современными языками, появилась как средство обеспечить выполнение нужных методов при использовании полиморфных переменных, то есть, по сути, как попытка расширить возможности вызова методов для реализации части функциональности, обеспечиваемой механизмом обработки сообщений. Описание онтологический инжиниринг. Онтологический инжиниринг – это процесс проектирования и разработки онтологий. При отсутствии общепринятой методологии и технологии этот процесс не является тривиальной задачей. Он требует от разработчиков профессионального владения технологиями инженерии знаний – от методов извлечения знаний до структурирования и формализации [Гаврилова, Хорошевский, 2000]. Онтологический инжиниринг подразумевает глубокий структурный анализ предметной области. Такую работу для интеллектуальных систем обычно выполняют инженеры по знаниям (knowledge engineers). Порождающее программирование. Краткая характеристика, отличия… Формулировка результатов, теория, практика Какие методы раньше использовались для создания программных продуктов. К типичным задачам программиста относится создание автономных программных продуктов, сайтов, документации и обучающих материалов для пользователей. Какие проблемы встречает программист при создании сайта, которые мешают быстро и качественно закончить работу? Каковы причины возникновения в программном коде ошибок и несоответствий? Привязка к конкретным технологиям. После того, как уже выбрана какая-то конкретная технология реализации, и на основе этого выбора написано большое количество исходного кода, становится очень трудно перейти на другую технологию. Существенный момент состоит в том, что легко внести ошибкув существующий программный код, не обратив внимания на тонкие различия в работе на различных технологических платформах. Например, если сайт создаётся наPHP, и при проектировании было принято решение об использовании базы данных MySQL, авпоследствии принято решение о переходе на другую базу данных, например на PostgresSQL или на MSSQL, то придется изменять многие SQL-запросы и при этом велика вероятность допустить ошибку. Существенно в этой ситуации может помочь покрытие кода автоматическими тестами, которые при каждом запуске будут указывать на следующую ошибку –и можно будет быстро найти и исправить соответствующий SQL-запрос. Но, перевод SQL-запросов с одного диалекта SQL на другой – это, механическая работа, для автоматизации которой можно описать правила перевода в виде отдельной программы, которая будет протестирована при создании большого числа конкретных программных продуктов и поэтому будет обладать высокой надёжностью. Корректность работы программы во всех ситуациях не может быть автоматически проверена при помощи любой другой программы. Лемма: не существует компьютерной программы CORRECT(P), которая по исходному коду программы P может сказать, завершится ли программа P без ошибок или нет. Доказательство: Пусть имеется программа X, которая заносит свой исходный текст в переменную T, после чего вычисляет CORRECT(T). Если результат “X завершается без ошибок” завершается с ошибкой. Если результат “X завершится с ошибкой”, то корректно завершается. Теперь что бы ни вернула процедура CORRECT – её результат в любом случае будет неверен. Это утверждение равносильно STOP-проблеме (что не существует алгоритма, который позволяет определить остановится или зациклится любой другой алгоритм). На олимпиадах по программированию, например, корректным считается решение, которое прошло все тесты придуманные жюри. Какие проблемы возникают при программной реализации сайтов? Программисту нужно оперировать сразу с большимчислом различных языков программирования (разбираться как в синтаксисе, так и в библиотеках), например, для создания стандартного интерактивного сайта на PHPиспользуетсяHTML, CSS и JavaScript – для описания клиентской стороны сайта, PHP – для описания серверной стороны сайта, MySQL диалект языка SQL для описания структуры и запросов к базе данных, а, кроме того, часто требуется понимание механизма работы и возможностей защиты от стандартных методов атак: SQL-Injection, Cross-sitescripting и т. д. При HTML-вёрстке, создании CSS и программировании на JavaScript приходится ещё учитывать различное понимание браузерами одних и тех же конструкций, или нужно использовать библиотеки, которые частично скрывают отличия различных браузеров, например, JavaScript-библиотека jQuery. С одной стороны, то, что используется так много языков, хорошо (особенно с позиций предметно-ориентированного подхода), потому что каждый язык, наиболее приспособлен для решения задач, а, с другой стороны – плохо, потому что от программиста требуется знать несколько языков одновременно, и, к тому же, дублировать код, описывая, по сути, одни и те же структуры и алгоритмы на нескольких языках. Ситуация постепенно улучшается: появляются новые интегрированные среды и библиотеки (frameworks) для обеспечения целостности и принципа DRY при создании сайтов. Одной из таких библиотек является GWT. Например, программное обеспечение для проведения олимпиады КИО: Когда-то была проблема.. В первых версиях конкурса проверку решения участника нужно было описывать два раза:
Сейчас же серверную проверяющую часть реализовать на серверной Java, а клиентское программное обеспечение выполнить на том же языке Java в виде апплета или при помощи библиотеки GWT3. В случае апплета требуется, чтобы у пользователя была установлена Java-машина, которая в настоящее время по умолчанию не входит в дистрибутив Windows и её обычно загружают и устанавливают из Интернета. При этом дистрибутив Java-машины занимает около 20 Мб, что бывает неприемлемым для пользователей с медленным выходом в интернет. Если программа-клиент будет написанас использованием библиотеки GWT, то тот же самый Java код будет переведён на JavaScript, после чего будет исполняться практическилюбым браузером. При этом необходимые структуры данных и алгоритмы проверки решения нужно лишь один раз описать языке Java. При внесении исправлений в исходные коды на Java будут автоматически исправляться. Отличия от существующих работ: в изученной литературе не сформулирована конкретная методика и последовательность действий, результаты, проверка (апробация) методики на конкретных различных практических программных проектах. Модель: создание программы проходит ряд последовательных этапов, на каждом из которых можно возвращаться и уточнять предыдущий этап. На каждом этапе программа записана на некотором языке (комбинации языков). Языки могут быть текстовыми и графическими (схемы и диаграммы). В процессе создания системы происходит переход от естественных языков к всё более формальным машинно-ориентированным языкам. Общее направление: разделить процесс программирования на “Что?” и “Как?” Детализация процесса создания программных систем на основе предметно-ориентированного подхода. Общая схема предметно-ориентированного подхода:
При создании (выделении) элементов языка проходят последовательно следующие этапы:
Пример (создание сайта Кенгуру).Приняли решение, что нужен объект – поле ввода с маской, которое позволяет вводить только строку, состоящую только из определённых символов, определённой длины, причём символы разбиты на группы по заранее заданной схеме. Написали me = new MaskEdit(‘ДН’, 20). Me.ignoreCase = true;. Далее, если мы не знаем, как вообще создавать MaskEdit. Понятно, что все MaskEdit будут создаваться примерно одинаковым кодом. А потому нам нужен пример какого-нибудь готового поля ввода с маской. Он будет создавать не ровно такой же объект как нам. Смотрим какой при этом получается (с пользовательской точки зрения) MaskEdit и пишем Unit-тест инициализирующий создание MaskEdit’а именно с такими параметрами. Добиваемся, чтобы unit-тест работал и обобщаем код (устраняем зависимости между кодом генератора и конкретными параметрами – входными данными unit-теста). Таким образом, мы легко получим код генератора. Если что-то называется в программе одинаково, то оно представляет одну и ту же сущность есть одно и то же и при, например, рефакторинге нужно переименовывать всё сразу (чтобы не оказалось, что до рефакторинга имелся в виду один и тот же обьект, а после – 2 разных). Проблема осложняется тем, что в программах бывают “связанные” идентификаторы. Например, элементы управления в правой части формы называются: кнопка – rightButton, а поле редактирования rightEdit, причём при редактировании содержимого поля меняется состояние кнопки, название которой получается отбрасыванием последней части идентификатора - “Edit” и добавлением “Button”. Логично, что при рефакторинге “переименование” если один переименовывается (мы придумали более говорящее название, чем просто правый), нужно переименовать и другой, но как об этом может догадаться компьютер? Как указать на взаимосвязь между различными сущностями на форме? Хорошее средство для этого – атрибуты. При помощи атрибутов мы можем к англоязычным полям прикрепить русскоязычные имена колонок (что, конечно, не очень хорошо с точки зрения последующего перевода на различные языки). Без поддержки автоматическими тестами очень легко нарушить “работу” программы. Понятие автоматического теста здесь понимается предельно широко. Например, при компиляции существенную поддержку по поиску ошибок оказывает сам компилятор. Например, чтобы провести рефакторинг “переименования” в версиях Delphi до 2005 (2007?) удобно было переименовать нужную сущность при инициализации и потом многократно нажимать F9 – запуская тем самым процесс компиляции и смотреть где останавливается компиляция, компилятор каждый раз будет останавливаться ровно на той строчке, где нужно исправить и выделять тот идентификатор, который нужно исправить. Существенной проблемой (задачей) при создание ПОЯ на основе существующего языка (путём создания библиотеки) является то как спроецировать понятия предметной области на базовые элементы языка. Сделать каждое понятие своим классом (получив таким образом максимальную гибкость, возможности наследования понятий и т. д.) или не писать так длинно и громоздко и сделать отдельны атрибуты полями. Не вводить новые типы данных. Нужно найти баланс между универсальностью и простой. Постановка задачи: Повысить продуктивность процесса программирования на основе предметно-ориентированного подходаза счёт разработки методов и апробации на реальных проектах. Создать основную часть библиотеки, позволяющей генерировать программы для большого круга задач. Сформулировать теорию создания программ на основе предметно-ориентированного подхода, что означает предложить одну или несколько (для сравнения) моделей и методов перехода между моделями. Теория оправдывает своё возникновение и может претендовать на научность только если она описывает все те же опытные данные (позволяет делать те же вещи) что и предыдущие, и при этом красивее и проще, компактнее, чем все предыдущие, либо объясняет те опытные данные, которые не укладываются в предыдущие теории. В терминах практического программирования это означает, что программа лучше или при исполняет то же при более компактном или понятном исходном коде, либо удовлетворяет большему числу тестов. Корректная программа, это программа выдающая правильный ответ на все придуманные нами тесты. При этом неясно, как (и возможно ли вообще), гарантировать 100% (полную) корректность программы, ведь всегда остаётся возможность, что мы что-то упустили. Что делать? Придумывать-искать всё новые и новые тесты. Это относится к любым теориям, к любым моделям, построениям. Альтернативный предметно-ориентированному подход (с которым можно предметно-ориентированный сравнивать). Вообразили (представили) программу. Нарисовали интерфейс. Написали требования к алгоритмам. Представили алгоритмы. Запрограммировали код. Тестируем, убеждаемся в корректности программы или находим ошибки и исправляем программный код. При этом мы пытаемся перейти сразу же от представления о системе на естественном языке и на языке схем “в вольной форме” рисунок интерфейса и программный код, конкретным компонентам и их настройкам. В данной работе предлагается новые метод разработки программ, имеющей существенное значение для повышения эффективности создания программы. Научная новизна состоит в том, что в этой работе предлагается целостная пошаговая методика проектирования, реализации, тестирования и практического применения предметно-ориентированных языков, чего в настоящее время не опубликовано в изученных автором работ по теме. |
Добавить документ в свой блог или на сайт
Похожие:
 | Компьютерное тестирование На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... | | Тест «Компьютерная грамотность» На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... |
| Образовательная программа «Школьный университет» На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... |  | Тема: Алюминий и его соединения На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... |
| Руководство пользователя стр. Содержание На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... | | С. В. Ахмадуллиной (должность, Ф. И. О., ученая степень, звание автора(ов) программы) На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... |
| Задание к лабораторной работе №1 по дисциплине «Специальные разделы информатики» Выбор На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... | | Особенности хранения и шифрования данных в web-системах обработки информации На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... |
| Московский государственный университет экономики, статистики и информатики... На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... | | Тесты по предметам школьной программы, вузовским дисциплинам, тесты... На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... |
| Проектирование подсистемы «Тестовые задания» учебного ресурса по... На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... | | Количество заданий в тест-билете – 9 Количество вариантов тест-билетов... На данный момент существует достаточно большое количество программных продуктов для создания тестовых и контролирующих заданий. Обзор... |
| План проведения мероприятий на Предметной неделе мо учителей естественных... Мо учителей естественных наук и мо учителей предметно – ориентированных дисциплин | | Использование спо на уроках информатики Что, впрочем, и понятно: пока есть возможность использования привычных программных продуктов переход к другой ос, другим пакетам... |
| Содержание Введение 6 Положения, выносимые на защиту 13 Глава Обзор... Структура и объем диссертации. Диссертация состоит из 120 страниц текста, содержит введение, четыре главы, заключение, список литературы... | | Конспект урока по биологии с мультимедийной поддержкой Тема урока... Тема урока: «Искусственные системы. Агроценозы, факторы повышения их продуктивности» |
