Курсовое проектирование

по курсу «Системное программирование». Часть 2 ( «Операционные Системы» )

Горин С.В., Рязанова Н.Ю.

Курсовое проектирование выполняется на шестом семестре обучения.

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

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

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

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

2. Техническое задание, которое опpеделяет среду проектирования и основные характеристики, влияющие на реализацию поставленной задачи.

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

Оформление курсового проекта

Курсовой проект оформляется в виде пояснительной записки объёмом 30-35 страниц и презентации.

Пояснительная записка должна содержать:

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

• техническое задание на проект ( бланк кафедры );

• заключение руководителя о проекте (допуск к защите).

Расчетно-пояснительной записки должна содержать следующие разделы:

Введение.

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

Первая глава, аналитический раздел.

В первой главе выполняется анализ поставленной задачи. Анализируются методы или способы ее решения. Проводится сравнительный анализ методов или способов решения и делается их обоснованный выбор.

Например, при выборе задачи разработки драйвера операционной системы семейства Windows необходимо:

- определить цель написания драйвера;

- на основе существующих классификаций WDM или более современной WDF обоснованно выбрать тип драйвера;

В случае выбора модели WDF необходимо проаналазировать и выбрать драйверную инфраструктуру: UMDF и KMDF и выбрать ту инфраструктуру, которая соответствует типу устройства для которого решено написать драйвер.

- определить место выбранного драйвера в системе

В случае выбора модели WDF проанализировать особенности объектной модели WDF и иерархию объектов.

В случае выбора драйвера WDM описать иерархию устройств и драйверов.

При выборе темы «Разработка драйверов для Unix и Unix-подобных систем» следует рассмотреть архитектуру подсистемы ввода/вывода, пространство имен, привести класссификацию типов драйверов и базовую архитектуру драйверов. Обоснованно выбрать тип драйвера и определить, какой драйвер будет разрабатываться: встраиваемый или динамически загружаемый. При необходимости описываются такие спецификации как ВВШ.ВВЛ (Вумшсу-Вкшмук Штеукафсу.Вкшмук-Луктуд Штеукафсу)ю

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

Вторая глава, конструкторский раздел.

Делается обоснованный выбор технологии ( например, объектно-ориентированный подход ) и средств разработки ( например, выбор библиотеки NuMega Driver Studio, которая является объектно-ориентированной надстройкой над «чистым» DDK ). Определяется тип программного обеспечения, например, драйвер и приложение, взаимодействующее с драйвером, или драйвер и сервис и т.п. и описывается взаимодействие модулей разработанного ПО через подсистему ввода/вывода на основе событийной модели. Например, для драйверов болчных устройств Unix рассматриваются особенности обмена с блочным устройством и структура buf.

При разработке драйверов описывается структура выбранного драйвера: точки входа и другие функции. Для WDF описываются объекты, которые представляют абстракции компонент ов драйверов, и методы, свойства, события, посредством которых драйверы взаимодействуют с объектами WDF. Описывается реализуемая драйвером функция или функции и приводится алгоритм/алгоритмы работы в виде схем по ГОСТу.

В конструкторском разделе следует:

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

- описать процесс обработки пакетов запроса ввода/вывода ( I/O Request Packet или IRP ) и выбрать сценарий обработки IRP [Oni]:

- обосновать необходимость применения отложенных процедурных вызовов DPC( для Windows ):

- обосновать метод буферизации, например:

в WDM-драйверах запрос может иметь или буфер ( для буферизованного ввода/вывода ), или список MDL ( для прямого ввода/вывода ); в модели WDF можно абстрагироваться от типа запроса ( буферизованного или прямого ) [орвик]; для драйверов Unix – выбор метода буферизации: используя прерывания, с помощью функции poll(), с помощью специальных структур данных clist.

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

- при необходимости использовать события WMI ( Windows Management Instrumentation ) для оповещения потребителей об интересных или экстренных событиях;

и т.п.

Метод II. “Сплайсинг” “Сплайсинг” – это замена начальных байтов оригинального обработчика на переход на другой обработчик. Описание алгоритма реализации этого метода: - найти адрес функции, вызов которой нужно перехватить; - сохранить несколько первых байтов этой функции в другом участке памяти; - на их место вставить машинную команду JUMP для перехода по адресу подставной функции. - сигнатура подменяющей функции должна быть такой же, как и исходной, т. е. все параметры, возвращаемое значение и правила вызова должны совпадать; - снять ловушку, восстановив ранее сохраненные (в п. 2) байты; Если затем вызвать перехватываемую функцию (таковой больше не являющуюся), то она будет работать так, как работала до установки ловушки. После того как она вернет управление, необходимо выполнить пункты 2 и 3 и тем самым вновь поставить ловушку на эту функцию. На рис. 2 .1 приведен алгоритм работы нового обработчика. EMBED Visio.Drawing.11 рис. 2.2. Метод II. Алгоритм работы нового обработчика Этот метод не рекомендуется использовать в пользовательском режиме в системах с вытесняющей многозадачностью. На замену кода в начале функции уходит какое-то время, а в этот момент перехватываемая функция может понадобиться другому потоку, что приведёт к катастрофическим последствиям. Однако, в режиме ядра, вследствие наивысшего уровня привилегий можно на короткий срок запретить прерывания, тем самым избежав переключения задач. Параграф взят из курсового проекта студента Улихина.

Для патчей описать особенности реализации.

Третья глава, технологический раздел.

Обоснованно выбирается язык программирования и среда программирования ( следует определить основные особенности языка, среды и специализированных библиотек и на этом основании сделать выбор того или другого языка, средства или библиотеки ); для драйверов и сервисов подробно описывается среда разработки; описываются выбранные структуры данных и функции, реализующие поставленную задачу; обосновывается выбор интерфейса пользователя и приводится его описание; описываются действия по установке программного обеспечения, например, установка драйвера в систему с помощью .INF файла^ с указанием необходимого набора файлов или с помощью установочного приложения; при необходимости разрабатываются демонстрационные программы; при необходимости разрабатываются отладочные программы и тестирующие программы или описываются использованные средства отладки и тестирования, например, тестирование средствами DDK c помощью стандартной тестирующей утилиты DriverVerifier; выполняется экспериментальная проверка программного обеспечения ( тестирование ), анализ результатов экспериментальной проверки разработанного программного обеспечения или полученных результатов исследования параметров системы; результаты исследования следует оформлять в виде графиков и/или диаграмм, таблиц.

Заключение или выводы.

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

В выводах кратко по пунктам перечисляются основные результаты работы ( например, 1. Показано .. 2. Исследовано/ны .. 3.Разработана/ны структура .. 4. Определена целесообразность .. 5. Разработано программное обеспечение .. 6. Тестирование показало .. и т.п.)

Список используемых источников.

Пpиложение.

В пpиложении дается кpаткое pуководство пользователя, pуководство системного пpогpаммиста (если это необходимо), pаспечатка полного исходного кода пpогpаммы или программного комплекса (с комментариями). Приложение к проекту может быть сдано в электронном виде.

Замечания

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

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

Защита курсового проекта.

Полностью выполненный и оформленный курсовой проект с положительными заключениями руководителя защищается перед комиссией.

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

Дополнительные указания по выполнению курсового проекта.

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

Требования к заданию по курсовому проектированию:

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

• Для реализации в курсовом проектировании может быть предложена любая тема, которая так или иначе связана с системным программированием. Это могут быть отдельные компоненты гипотетической ОС - планировщик, монитор, файловая система, система подкачки страниц, система управления и распределения ресурсов и т.п., драйверы реальной ОС.