Реферат: Формирование целей и требований, предъявленных к проекту 8 Описание технологий, применяемых в проекте 9

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Институт математики и компьютерных наук

Кафедра информационной безопасности


Допустить к защите в ГАК
Заведующий кафедрой
информационной безопасности,
д.т.н., профессор А.А. Захаров

“____” _________ 2010 г.


Гусев Виталий Константинович

Разработка системы автоматической генерации заданий и решений

(выпускная квалификационная работа)


Научный руководитель:

к.ф.- м.н., доцент кафедры информационной безопасности

__________ Ниссенбаум О. В.

Автор работы:

__________ Гусев В. К.


Тюмень 2010
Оглавление
Оглавление 3

ВВЕДЕНИЕ 4

^ ГЛАВА 1. АНАЛИТИЧЕСКАЯ ЧАСТЬ 7

1.1. Описание предметной области 7

1.2. Краткий обзор альтернативных решении 8

1.3. Формирование целей и требований, предъявленных к проекту 8

1.4. Описание технологий, применяемых в проекте 9

1.4.1. Модульная архитектура 9

1.4.2. DLL 17

1.4.3. XML 22

Результаты и выводы 31

^ ГЛАВА 2. РЕАЛИЗАЦИЯ ГЕНЕРАТОРА КОНТРОЛЬНЫХ РАБОТ С РЕШЕНИЯМИ 32

2.1. Структура программного комплекса 32

2.2. Краткое описание работы пользователя с системой 34

2.3. Разработка XML схемы построения интерфейса модуля 36

2.4. Разработка модуля DLL библиотеки 42

2.5. Безопасность системы 43

2.6. Организация справочной системы 44

2.7. Апробация 46

ЗАКЛЮЧЕНИЕ 47

^ СПИСОК ЛИТЕРАТУРЫ 48

ПРИЛОЖЕНИЕ 1. Пример контрольной работы с решением 50

ПРИЛОЖЕНИЕ 2. Справочная система 51



ВВЕДЕНИЕ

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

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

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

Один из способов обеспечения объективной оценки знаний – использование индивидуальных вариантов контрольных и домашних заданий для каждого студента. Такой подход снижает вероятность списывания и помогает в раннем выявлении неуспевающих студентов. Существенным препятствием для внедрения такого подхода является большой объем подготовительной работы и время, затрачиваемое преподавателем для проверки работ студентов. Например, в курсе «Теоретико-числовые методы в криптографии» ТюмГУ общий объем домашних и контрольных работ составляет около 150 задач на студента, а число студентов на курсе - от 30 до 45 человек. Таким образом, для обучения одного потока студентов необходимо составить и решить более 4500 различных задач. Преподавателю приходится самому разрабатывать задания и прорешивать их.

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

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

В ходе написания дипломной работы были поставлены следующие задачи:

исследовать проблемную область и сформировать требования к программному комплексу, к структуре программы, протоколам, языку программирования;

исследовать разнообразие подходящих для решения задачи технологий;

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

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

сгенерировать большое число контрольных работ по предмету «ТЧМК» и протестировать на студентах ТюмГУ.

Мой проект будет являться прикладной системой для преподавателя, позволяющей ему без труда создать достаточное количество проверочных контрольных работ и решений к ним. То есть ему не придется самому придумывать и прорешивать задания, за него это сделает система. Программа может использоваться дома и в университете, в любом учебном заведении. С помощью этих сгенерированных заданий преподаватель сможет проводить классные контрольные работы, домашние проверочные работы без значительной затраты усилий со своей стороны. После чего, сверив с выданными системой решениями, он сможет выставить соответствующие баллы студентам. Также программа может применяться для самопроверки студентов: на руки выдаются задания, учащийся их прорешивает, и через некоторое время выдаются решения к этим заданиям для самостоятельного контроля уровня своих знаний.
^ ГЛАВА 1. АНАЛИТИЧЕСКАЯ ЧАСТЬ


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

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

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

достаточно малое количество тестовых заданий. Задания довольно часто повторяются в различных вариантах контрольных работ;

массовая заготовка шпаргалок студентами;

взлом компьютерных программ с целью получения правильных ответов;

заготовка заданий преподавателем заранее, что требует большой затраты времени и усилий;

возможные опечатки и ошибки в заданиях.

Системы могут быть реализованы очень хорошо. Но они не свободны от всех вышеперечисленных недостатков.
^ 1.3. Формирование целей и требований, предъявленных к проекту
Основательно изучив предметную область, было решено разработать программное обеспечение, так называемый генератор заданий, для автоматизации процесса создания вариантов работ с заданиями и решенями к ним. В частности был выбран предмет «Теоретико-числовые методы в криптографии» по следующим причинам:

задачи легко поддаются алгоритмизации и автоматизации;

предмет преподается на кафедре;

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

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

возможность создания неограниченного числа вариантов контрольных работ;

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

расширяемость программного комплекса, добавление новых типов заданий;

защищенность программы от всякого рода информационных атак.
^ 1.4. Описание технологий, применяемых в проекте 1.4.1. Модульная архитектура
Архитектура – базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы. Определение взято из стандарта IEEE 1472000. 2000.

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

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

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

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

Модульный метод проектирования должен удовлетворять пяти основным требованиям:

декомпозиции;

композиции;

понятности;

непрерывности;

защищенности.

Метод проектирования удовлетворяет критерию Декомпозиции, если он помогает разделить задачу на несколько менее сложных подзадач, объединяемых простой структурой, и настолько независимых, что в дальнейшем можно отдельно продолжить работу над каждой из них. Такой процесс часто будет циклическим, поскольку каждая подзадача может оказаться достаточно сложной и потребует дальнейшего разложения. Следствием требования декомпозиции является разделение труда: как только система будет разложена на подсистемы, работу над ними следует распределить между разработчиками или группами разработчиков. Это трудная задача, так как необходимо ограничить возможные взаимозависимости между подсистемами. Необходимо свести такие взаимозависимости к минимуму; в противном случае разработка каждой из подсистем будет ограничиваться темпами работы над другими подсистемами. Эти взаимозависимости должны быть известны: если не удастся составить перечень всех связей между подсистемами, то после завершения разработки проекта будет получен набор элементов программы, которые, возможно, будут работать каждая в отдельности, но не смогут быть собраны вместе в завершенную систему, удовлетворяющую общим требованиям к исходной задаче. Наиболее очевидным примером обсуждаемого метода, удовлетворяющим критерию декомпозиции, является метод нисходящего проектирования. В соответствии с этим методом разработчик должен начать с наиболее абстрактного описания функции, выполняемой системой. Затем последовательными шагами детализировать это представление, разбивая на каждом шаге каждую подсистему на небольшое число более простых подсистем до тех пор, пока не будут получены элементы с настолько низким уровнем абстракции, что становится возможной их непосредственная реализация.

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

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

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

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

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

Из рассмотренных критериев следуют пять правил, которые должны соблюдаться, чтобы обеспечить модульность:

прямое отображение;

минимум интерфейсов;

слабая связность интерфейсов;

явные интерфейсы;

скрытие информации (инкапсуляция).

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

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

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

Эта рекомендация следует, в частности, из двух критериев модульности:

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

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

Правило Минимума Интерфейсов ограничивает общее число информационных каналов, связывающих модули системы:

^ Каждый модуль должен поддерживать связь с возможно меньшим числом других модулей.

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

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

Правило Слабой связности интерфейсов относится к размеру передаваемой информации, а не к числу связей:

^ Если два модуля общаются между собой, то они должны обмениваться как можно меньшим объемом информации.

Требование Слабой связности интерфейсов следует, в частности, из критериев непрерывности и защищенности.

Четвертое правило Явных интерфейсов является еще одним шагом к укреплению тоталитарного режима в обществе модулей: требуется не только, чтобы любые переговоры ограничивались лишь несколькими участниками и были немногословными; необходимо, чтобы такие переговоры были публичными и гласными!

^ Всякое общение двух модулей A и B между собой должно быть очевидным и отражаться в тексте A и/или B.

За этим правилом стоят критерии:

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

непрерывности. Должно быть очевидно, какие элементы могут быть затронуты возможным изменением;

понятности.

Одной из проблем, возникающих при применении правила Явных Интерфейсов, является то, что межмодульная связь может осуществляться не только через вызов процедуры; источником косвенной связи может быть, например, совместное использование данных (data sharing): предположим, что модуль A изменяет данные, а модуль B использует тот же элемент данных x. Тогда A и B оказываются фактически связанными через x, хотя между ними может и не быть явной взаимосвязи, например, вызова процедуры.

Правило Скрытия Информации можно сформулировать следующим образом:

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

Применение этого правила означает, что каждый модуль известен всем остальным (то есть разработчикам других модулей) через некоторое официальное описание, или так называемые общедоступные свойства. Конечно, таким описанием может быть весь текст модуля (текст программы, текст проекта): он и обеспечивает правильное представление о модуле, поскольку это и есть модуль! Но правило Скрытия Информации устанавливает, что в общем случае это не обязательно: описание должно включать лишь некоторые из свойств модуля. Остальные свойства должны оставаться не общедоступными, или закрытыми (секретные). В основе правила Скрытия Информации лежит критерий непрерывности. Предположим, что в некотором модуле происходят изменения, касающиеся лишь его скрытых элементов и не затрагивающие общедоступных свойств; тогда на другие обращающиеся к нему модули, называемые его клиентами, эти изменения не подействуют. Чем меньше общедоступная часть, тем больше шансов на то, что изменения в модуле будут содержаться в его скрытой части. Можно изобразить модуль, поддерживающий правило Скрытия Информации, в виде айсберга; лишь его верхушка - интерфейс - видна клиентам.

Правило скрытия информации придает особое значение отделению описания функции от ее реализации, - что делает функция и как она это делает - разные вещи. Помимо критерия непрерывности, это правило связано также с критериями декомпозиции, композиции и понятности. Нельзя независимо разрабатывать модули системы, комбинировать существующие модули или понимать действие отдельных модулей, если неизвестно в точности, что каждый из них может (или не может) ожидать от других модулей. Как правило, в общедоступную часть следует включать функциональность, заданную спецификацией модуля, а все, что связано с реализацией этих функциональных возможностей, должно быть скрыто, предохраняя другие модули от последующих изменений реализации программы.
1.4.2. DLL
DLL - это сокращение от Dynamic Link Library (динамически загружаемая библиотека). С формальной точки зрения DLL - особым образом оформленный относительно независимый блок исполняемого кода.

История DLL начинается с средины 60-х годов прошлого столетия, однако широкое распространение динамически линкуемые библиотеки получили после появления операционной системы Windows. По крайней мере, доподлинно известно, что операционные системы Windows 3.1/3.11 уже содержали программы, использующие DLL. В связи с тем, что в те времена емкости оперативной памяти и жесткого диска были значительно меньше, чем сейчас, использование DLL предоставляло ряд преимуществ:

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

экономия физической памяти (RAM) за счет загрузки в нее единственного экземпляра DLL. Именно тогда появились счетчики ссылок пользователей DLL - при каждом вызове функции ОС проверяет наличие загруженного в память экземпляра библиотеки. В случае положительного ответа счетчик ссылок пользователей данной DLL увеличивается на единицу. Если же экземпляр данной DLL в памяти не обнаружен, то операционная система загружает файл в память и присваивает счетчику значение "1". При выгрузке DLL из памяти уменьшается значение счетчика числа пользователей, в случае равенства его нулю DLL немедленно выгружается;

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

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

Особый способ оформления предполагает наличие в DLL так называемых секций импорта и экспорта. Секция экспорта указывает те идентификаторы объектов (функций, классов, переменных), доступ к которым предоставляет данная DLL. В этом случае мы говорим об экспортировании идентификаторов из DLL. В общем случае, именно секция экспорта предоставляет особый интерес для разработчиков. Хотя ничто не мешает реализовать DLL, которая не имеет данной секции, но, тем не менее, выполняет полезную работу. Относительная независимость связана с наличием/отсутствием секции импорта у DLL (т.е. секции, в которой описываются внешние зависимости данной DLL от других). Подавляющее большинство DLL (за исключением, быть может, DLL ресурсов) импортирует функции из системных DLL (kernel32.dll, user32.dll, gdi32.dll и др.).

"Исполняемый" код в DLL не предполагает автономного использования. Перед тем, как можно будет приступить к использованию, необходимо загрузить DLL в область памяти вызывающего процесса (т.е. DLL не может выполняться сама по себе - ей обязательно нужен клиент). Это явление носит название "проецирование DLL на адресное пространство процесса". И это не удивительно, если вспомнить тот факт, что процессор работает не только с регистрами, но и с адресами памяти. Поэтому каждому объекту DLL требуется свое место "под солнцем", чтобы иметь возможность быть выполненным при вызове. В конечном коде exe-файла, который генерирует компилятор, не будет инструкций процессора, соответствующих коду данной функции. Вместо этого будет сгенерирована инструкция вызова соответствующей функции (call). Так как DLL отображена на адресное пространство процесса, то код DLL будет легко доступен по call-вызову.

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

Что же касается физического представления на диске, то разница между dll- и exe-файлами небольшая. Как динамически линкуемые библиотеки, так и исполняемые модули приложений в Windows имеют формат Portable Executable (PE-файл), однако нельзя "запустить" DLL-библиотеку на выполнение, как обычное приложение.

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

Основные направления использования DLL:

всевозможные модули расширения функциональности приложений - так называемые plug-in (пример с MatLab, Far и пр.);

локализация приложения;

разделение объектов абстракции (функций, классов и пр.) между приложениями;

независимость модификации кода - DLL может быть в любой момент переписана с сохранением экспортируемых интерфейсов;

реализация определенных действий, которые можно совершить только при помощи DLL (к примеру, перехват API-вызовов);

хранилище ресурсов с возможностью независимого изменения этих ресурсов.

DLL широко используются в технологии COM (а до этого в OLE 1.0) - в качестве основы при построении так называемых inproc-серверов (внутрипроцессных серверов) используются DLL. Это позволяет упростить взаимодействие с приложением, благодаря загрузке используемых ActiveX объектов в адресное пространство клиента. В этом случае накладные расходы, связанные с преодолением границ адресных пространств при передаче данных (параметров функций и т.д.) - так называемый marshalling, сводятся к нулю. Все те абстракции повседневной программистской жизни, могут быть внедрены в DLL - классы, объекты, таймеры, потоки, функции и пр. Другое дело, что не всегда удобно и правильно работать с этими объектами вне DLL. Связано это с тем, что не всегда логическое представление того или иного объекта может быть однозначно представлено (переведено) в физическое. Использование DLL не налагает ограничений на используемый язык. Более того, как правило, DLL разрабатывается на другом языке программирования, нежели тот, который используется при ее загрузке. Пример: разрабатывался математический проект, код которого реализовывался на M-языке среды MatLab (Matrix Laboratory). M-язык по своей природе является интерпретируемым языком программирования. После этого полученные алгоритмы были реализованы при помощи языка C++ и скомпилированы в DLL, которая также использовалась средой MatLab.

У динамических библиотек сплошные преимущества и ни одного существенного недостатка. Поэтому они получили такое широкое распространение:

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

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

хранилища ресурсов. В DLL можно хранить ресурсы, такие как рисунки, формы, иконки меню, и т.д.;

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

совместное использование. Если библиотека загружена, то её могут использовать и другие приложения;

экономия ресурсов. Библиотеку можно загрузить и выгрузить тогда, когда это действительно необходимо. Например, программа в нужный момент загрузила DLL, вызвала функцию, сделала работу и выгрузила библиотеку до следующего раза. Налицо экономия памяти.
1.4.3. XML
История XML начинается с 1996 год, в конце которого появился черновой вариант спецификации языка. В 1998 году эта спецификация была утверждена. А началось всё с появления в 1986 году языка SGML.

SGML (англ. Standard Generalized Markup Language — стандартный обобщённый язык разметки) заявил о себе как гибкий, комплексный и всеохватывающий метаязык для создания языков разметки.

Наиболее широко SGML применяется для создания других языков разметки, именно с его помощью был создан язык разметки гипертекстовых документов — HTML, спецификация которого была утверждена в 1992 году. Его появление было связано с необходимостью организации стремительно увеличивающегося массива документов в сети Интернет. Бурный рост количества подключений к Интернету и, соответственно, Web-серверов повлек за собой такую потребность в кодировке электронных документов, с которой не мог справиться SGML вследствие высокой трудности освоения. Появление HTML — очень простого языка разметки — быстро решило эту проблему: лёгкость в изучении и богатство средств оформления документов сделали его самым популярным языком для пользователей Интернет. Но, по мере роста количества и изменения качества документов в Сети, росли и предъявляемые к ним требования, и простота HTML превратилась в его главный недостаток. Ограниченность количества тегов и полное безразличие к структуре документа побудили разработчиков в лице консорциума W3C к созданию такого языка разметки, который был бы не столь сложен, как SGML, и не настолько примитивен, как HTML. В результате, сочетая в себе простоту HTML, логику разметки SGML и удовлетворяя требованиям Интернет, появился на свет язык XML.

XML (англ. eXtensible Markup Language — расширяемый язык разметки;— рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями. Целью создания XML было обеспечение совместимости при передаче структурированных данных между разными системами обработки информации, особенно при передаче таких данных через Интернет. Словари, основанные на XML (например, RDF, RSS), сами по себе формально описаны, что позволяет программно изменять и проверять документы на основе этих словарей, не зная их семантики, то есть, не зная смыслового значения элементов. Важной особенностью XML также является применение так называемых пространств имён (англ. namespace). Правильно построенные и действительные документы XML

Стандартом определены два уровня правильности документа XML: правильно построенный и действительный.

Правильно построенный (Well-formed). Правильно построенный документ соответствует всем общим правилам синтаксиса XML, применимым к любому XML-документу. И если, например, начальный тег не имеет соответствующего ему конечного тега, то это неправильно построенный документ XML. Документ, который неправильно построен, не может считаться документом XML; XML-процессор (парсер) не должен обрабатывать его обычным образом и обязан классифицировать ситуацию как фатальная ошибка.

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