Некоммерческое акционерное общество
АЛМАТИНСКИЙ УНИВЕРСИТЕТ ЭНЕРГЕТИКИ И СВЯЗИ
Кафедра компьютерных технологий
СИСТЕМНОЕ ПРОГРАММИРОВАНИЕ 1
Методические
указания к выполнению курсовой работы
для студентов специальности 5В070400 –
Вычислительная техника и программное обеспечение
Алматы 2013
СОСТАВИТЕЛИ: Мусатаева Г.Т., Конуспаева А.Т., Байжанова Д.О. Системное программирование 1. Методические указания к выполнению курсовой работы для студентов специальности 5В070400 – Вычислительная техника и программное обеспечение. - Алматы: АУЭС, 2013. - 34 с.
Методические указания к выполнению курсовой работы предназначены для студентов специальности 5В070400 – Вычислительная техника и программное обеспечение.
Таблица – 5, библиография – 6 названий.
Рецензент: канд. техн. наук, доцент Ни А.Г.
Печатается по плану издания некоммерческого акционерного общества «Алматинский университет энергетики и связи» на 2012 г.
© НАО «Алматинский университет энергетики и связи», 2013 г.
Введение
Настоящие методические указания предназначены для студентов специальности 5В070400 – «Вычислительная техника и программное обеспечение», выполняющих курсовую работу по дисциплине «Системное программирование 1».
1 Цели и задачи курсовой работы
1.1 Цель курсовой работы
Целью выполнения курсовой работы по дисциплине «Системное программирование 1» является формирование у студентов опыта создания программ с использованием способов программирования основных системных функций.
Назначение указаний – определить цель, тематику, содержание, объем, порядок выполнения работы, направить деятельность студентов по нужному руслу и пояснить основные этапы проектирования. Предлагаемые задания разработаны с использованием методических материалов по курсовому проектированию и специальной литературы по системному программированию.
1.2 Задачи курсовой работы
Задачами курсовой работы являются:
- закрепление, углубление и обобщение знаний, полученных студентами во время их обучения по дисциплине «Системное программирование 1»;
- применение полученных знаний к системному решению типовой задачи по программированию системных функций IBM PC;
- получение навыков работы со специальной литературой и навыков программирования;
- приобретение опыта аналитической работы и формирование соответствующих умений;
- формирование умений формулировать логически обоснованные предложения, рекомендации и выводы по результатам работы;
- формирование умений выступать перед аудиторией с докладом при защите работы, компетентно отвечать на вопросы, вести дискуссию и убеждать оппонентов в правильности принятых решений.
2 Краткая теоретическая часть
2.1 Оконное приложение
Любое оконное приложение, написанное под операционной системой, должно содержать в себе следующие элементы:
- Функцию регистрации класса окна.
- Функцию создания окна.
- Оконную процедуру.
- Цикл обработки сообщений.
Регистрация окна проводится в два этапа. Во-первых, заполняется структура WNDCLASSEX (поля которой как раз и содержат общую информацию), после чего выполняется функция RegisterClassEx, в которую передается указатель на заполненную структуру. Ниже приведен фрагмент программы с комментариями к полям заполняемой структуры:
WNDCLASSEX wcex; // объявление переменной типа структура оконного класса;
wcex.cbSize = sizeof(WNDCLASSEX); // размер структуры в байтах;
wcex.style = CS_HREDRAW | CS_VREDRAW; // стиль окна;
wcex.lpfnWndProc = (WNDPROC)WndProc; //адрес оконной процедуры;
wcex.cbClsExtra = 0;
wcex.cbWndExtra = 0;
wcex.hInstance = hInstance; // описатель приложения;
wcex.hIcon = MyIcon1; // определение иконки;
wcex.hCursor = LoadCursor(NULL, IDC_ARROW); // определение курсора;
wcex.hbrBackground = GetSysColorBrush(COLOR_BTNFACE); // установка фона;
wcex.lpszMenuName = NULL; // определение меню;
wcex.lpszClassName = "MyWindow"; // имя класса;
wcex.hIconSm = NULL; // опр еделение маленькой иконки;
RegisterClassEx(&wcex); // регистрация класса окна.
После того как класс окна зарегистрирован, можно создавать окна, что выполняется следующим образом:
hWnd=CreateWindow( "MyWindow", // имя класса окна "Строка заголовка", // имя приложения;
WS_OVERLAPPEDWINDOW, // стиль окна;
CW_USEDEFAULT, // положение по Х;
CW_USEDEFAULT, // положение по Y;
CW_USEDEFAULT, // размер по Х;
CW_USEDEFAULT, // размер по Y;
NULL, // описатель родительского окна;
NULL, // описатель меню окна;
hInstance, // указатель приложения;
NULL); // параметры создания.
Функция CreateWindow возвращает описатель вновь созданного окна. Если возвращаемое значение равно NULL, это значит, что окно не было создано по какой-либо причине.
Чтобы созданное окно появилось на экране, необходимо выполнить последовательно две функции:
ShowWindow(hWnd, nCmdShow); // Показать окно;
UpdateWindow(hWnd); // Обновить окно.
Когда в системе происходит какое-либо событие, на которое должна отреагировать исполняемая программа (например, нажата клавиша на клавиатуре, перемещена мышь или истекло время ожидания), операционная система посылает программе сообщение об этом событии. Программа получает сообщение и выполняет код (часть программы), реагирующий на это событие.
Стандартный цикл обработки сообщений имеет вид:
MSG msg;
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
Функция GetMessage выбирает очередное сообщение из программной очереди. Результатом выполнения функции является заполнение структуры msg, которая содержит всю необходимую информацию о полученном сообщении: описатель окна, которому предназначено сообщение, тип сообщения, параметры сообщения (зависящие от типа сообщения) и время возникновения сообщения. Функция также возвращает некоторое число, которое отлично от нуля для всех сообщений, кроме сообщения о закрытии программы. В последнем случае цикл обработки сообщений прерывается и программа завершается.
Функция TranslateMessage преобразует сообщение в соответствии с системными настройками (например, преобразовывает код нажатой клавиши клавиатуры, согласно выбранному в настоящее время языку).
Функция DispatchMessage определяет, какому окну приложения послано сообщение, и вызывает соответствующую оконную процедуру.
Оконная процедура является центральной частью программы. Оконная процедура соответствует одному (или более) окну программы и содержит в себе программную реализацию поведения окна. Подпрограммы рисования элементов окна, реакция на действия мыши, клавиатуры, закрытия окна – все это заключено внутри оконной процедуры.
Оконная процедура имеет стандартный вид:
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
. . . . .
switch (message)
{
case WM_CREATE: // Сообщение приходит при создании окна
. . . . . . .
break;
case WM_PAINT: // Перерисовать окно
. . . . . . .
break;
case WM_DESTROY: // Завершение работы
. . . . . . .
break;
default:
// Обработка сообщений, которые не обработаны пользователем
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
Оконная процедура вызывается только тогда, когда пришло какое-либо сообщение, предназначенное соответствующему окну. Обратите внимание, что оконная процедура задается в классе регистрации окна, то есть для нескольких окон существует только один экземпляр оконной процедуры. Какому именно окну послано сообщение, определят первый параметр функции WndProc – описатель окна hWnd.
Второй параметр функции - message - определяет тип сообщения и принимает одно значение из множества WM _<сообщение>. Например, когда message равно WM_CREATE, это означает, что пришло сообщение о создании окна (данное сообщение является первым сообщением, приходящим в оконную процедуру после создания окна и приходит только один раз).
Третий и четвертый параметры - wParam и lParam сопутствуют сообщению и зависит от его типа. Например, если приходит сообщение о нажатии мыши, в этих параметрах содержится информация о координатах мыши в момент нажатия и состоянии управляющих клавиш.
Программист сам выбирает, какие сообщения обрабатывать, а какие нет. Всего существует несколько сотен сообщений, поэтому обработка всех из них вызвало бы затруднение. Для ликвидации этого неудобства существует функция DefWindowProc, которая, по умолчанию, обрабатывает все возможные сообщения.
Контекст – структура данных, формируемая операционной системой, хранящая информацию о параметрах и характеристиках устройства вывода, посредством которого программа осуществляет графический вывод информации.
В программе контекст представлен своим описателем и объявляется следующим образом:
HDC hdc;
Для того чтобы начать работу с контекстом, необходимо его получить у операционной системы. Следует отметить, что контекст лучше запрашивать только в момент графического вывода (так как на поддержание контекста требуется оперативная память и время работы ОС), и сразу же закрывать его после завершения рисования. Существует два способа получения контекста, отличающихся функциями АРI , которые для этого используются.
Первый способ
hdc = BeginPaint(hWnd, &ps); // Начать графический вывод;
// графический вывод;
. . . . . . . . . . .
EndPaint(hWnd, &ps); // Закончить графический вывод;
Второй способ
hdc = GetDC (hWnd); // Начать графический вывод;
// графический вывод;
. . . . . . . . . . .
ReleaseDC (hWnd, hdc ); // Закончить графический вывод.
Разница между первым и вторым способом будет пояснена ниже.
Параметр hWnd – описатель того окна, в котором требуется перерисовка. Описатель контекста позволяет программе рисовать только в пределах клиентской области окна, описатель которого использовался при его создании. В каждом окне выделяют несколько областей:
1) рабочая область – вся область, занимаемая окном на экране;
2) неклиентская область включает стандартные элементы окна, которые, в общем случае, отрисовываются операционной системой: рамка, строка заголовка, кнопки закрытия, минимизации и т.п., меню;
3) клиентская область – вся оставшаяся от неклиентской рабочая область окна.
Для управления действительными и недействительными областями существуют две функции:
1) InvalidateRect(hWnd, &rect, FALSE); // сделать недействительной область, ограниченную прямоугольником rect ( при этом фон окна обновится, если третий параметр функции будет TRUE);
2) ValidateRect(hWnd, &rect); позволяет сделать любую прямоугольную область окна действительной.
2.3 Порядок обработки сообщений, цикл обработки сообщений
Мышь – это графическое устройство ввода информации с одной или более кнопками. Windows поддерживает однокнопочную, двухкнопочную или трехкнопочную мышь. Фактически стандартом, используемым большинством приложений Windows, стала двухкнопочная мышь. Программа может определить наличие мыши и количество кнопок мыши с помощью системных установок:
1) bool fMouse = GetSystemMetrics(SM_MOUSEPRESENT);
2) int cButtons = GetSystemMetrics(SM_CMOUSEBUTTONS);
Если мышь установлена, fMouse будет установлена в TRUE , количество кнопок при этом будет равняться cButtons .
Когда пользователь перемещает мышь, операционная система перемещает по экрану растровую картинку (обычно стрелку), которая называется "курсор мыши" ( mouse cursor ). Курсор мыши имеет "вершину" картинки ( hot spot ), размером в один пиксель, определяющую положение мыши на экране.
Ранее, при регистрации класса окна, мы уже сталкивались с необходимостью выбора типа курсора мыши, который устанавливается в приложении, по умолчанию (см. тему "Регистрация окна"):
wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
Тип IDC _ ARROW является наиболее часто используемым курсором, представляющим собой стрелку и имеющим вершину в левой верхней части. Приведем несколько примеров предопределенного курсора мыши:
IDC _ APPSTARTING Стандартная стрелка с песочными часами.
IDC _ ARROW Стандартная стрелка.
IDC _ CROSS Крест.
IDC _ IBEAM Текстовый курсор (в виде символа I).
IDC _ ICON Пустая иконка для Windows NT.
IDC _ NO Перечеркнутая окружность.
IDC _ SIZE Четыренаправленная стрелка для Windows NT.
IDC _ SIZENESW.
IDC _ SIZENS Различные стрелки изменения размера.
IDC_SIZENWSE.
IDC_SIZEWE.
IDC_UPARROW.
IDC _ WAIT Песочные часы ожидания.
В отличие от клавиатуры, сообщения от мыши приходят в окно в любом случае, если мышь находится над окном (даже если окно не активно и не имеет фокуса ввода) и совершается какое-либо действие с мышью (перемещение мыши или нажатие клавиш). В таблице 1 приведены основные сообщения от мыши, которые могут быть обработаны оконной процедурой.
Таблица 1 – Типы сообщений, поступающих в приложение от мыши
|
Сообщение |
Назначение |
Значение параметра lParam |
Значение параметра wParam |
|
WM_MOUSEMOVE |
Мышь перемещается над окном |
Координаты мыши в координатах клиентской области окна: x= LOWORD(lParam) y= HIWORD(lParam) |
Битовая маска, определяющая состояние управляющих клавиш и других кнопок мыши: MK _ LBUTT О N левая кнопка нажата MK _ RBUTT О N правая кнопка нажата MK _М BUTTUN средняя кнопка нажата MK_SHIFT <Shift> нажат MK_CONTROL <Ctrl> нажат |
|
WM_LBUTTONDOWN |
Левая клавиша нажата |
|
|
|
WM_MBUTTONDOWN |
Средняя клавиша нажата |
|
|
|
WM_RBUTTONDOWN |
Правая клавиша нажата |
|
|
|
WM_LBUTTONUP |
Левая клавиша отпущена |
|
|
|
WM_MBUTTONUP |
Средняя клавиша отпущена |
|
|
|
WM_RBUTTONUP |
Правая клавиша отпущена |
|
|
|
WM_LBUTTONDBLCLK |
Левая клавиша дважды нажата |
|
|
|
WM_MBUTTONDBLCLK |
Средняя клавиша дважды нажата |
|
|
|
WM_RBUTTONDBLCLK |
Правая клавиша дважды нажата |
|
|
Приложения Windows обязаны поддерживать пользовательский ввод с клавиатуры, так как данный вид ввода информации является основным (совместно с мышью). Windows полностью поддерживает для клавиатуры идеологию сообщений, то есть любая программа узнает о нажатии той или иной клавиши посредством сообщений, которые посылаются оконной процедуре.
Сообщение от клавиатуры проходит две очереди, прежде чем попадет в вашу программу – системную очередь сообщений и очередь сообщений приложения. Из системной очереди Windows выбирает сообщения, предназначенные исключительно ей (например, что нажата перегрузка машины < Ctrl + Alt + Del > или переключение между приложениями < Alt + Tab >). Таким образом, программа получает только адресованные ей сообщения от клавиатуры.
Когда любое окно получает от системы сообщение WM _ SETFOCUS , это означает, что окно получает фокус ввода. Теперь все сообщения от клавиатуры будут посылаться в данное окно. Окно теряет фокус ввода, когда его оконная процедура получает сообщение WM _ KILLFOCUS .
Вашей программе не нужно реагировать на все сообщения от клавиатуры, так как операционная система сама обрабатывает многие клавиатурные сообщения (например, начинающиеся с префикса < Alt + >). Эти сообщения будут обработаны Windows, и ваша программа получит сообщение, являющееся обработкой системного сообщения (например, сообщит вам, что окно закрывается, либо окно теряет фокус ввода).
Сообщения, которые приложение (ваша программа) получает от клавиатуры, различаются на аппаратные (keystrokes) и символьные (characters). Любое нажатие на клавиатуре генерирует аппаратное сообщение. Нажатие клавиши с каким-либо символом (буквой, цифрой, значком) должно привести к тому, что Windows , кроме аппаратного сообщения, пошлет в вашу программу символьное сообщение.
Операционная система выделяет в потоке аппаратных сообщений системные и несистемные сообщения. Системные сообщения обычно вырабатываются при нажатии клавиш в сочетании с клавишей < Alt >. Эти сообщения вызывают опции меню программы или системного меню (< Alt +функциональная клавиша>, < Alt + Esc >), или используются для системных функций таких, как смена активного окна (< Alt + Tab >). Обычно программа игнорирует системные сообщения, однако иногда возникает необходимость в их обработке.
Типы сообщений, поступающих в приложение от клавиатуры, приведены в таблице 2.
Обычно сообщения о нажатии и отпускании клавиши появляются парами. Исключение составляет тот случай, когда пользователь не отпускает клавишу и включается автоповтор. В последнем случае в программу направляется поток сообщений о нажатии клавиши.
Таблица 2 - Типы сообщений, поступающих в приложение от клавиатуры
|
Типы сообщений |
Клавиша нажата |
Клавиша отпущена |
|
Несистемные аппаратные сообщения |
WM_KEYDOWN |
WM_KEYUP |
|
Системные аппаратные сообщения |
WM_SYSKEYDOWN |
WM_SYSKEYUP |
При знакомстве с поддержкой MDI (Multiple Document Interface) в Windows требуется новая терминология. Окно приложения в целом называется главным окном (frame window). Так же, как в традиционной программе для Windows, это окно имеет стиль WS_OVERLAPPEDWINDOW.
Приложение MDI так же, создает окно - (client window) - на основе предопределенного класса окна MDICLIENT. Окно создается с помощью вызова функции CreateWindow с использованием этого класса окна и стиля WS_CHILD. Последним параметром функции CreateWindow является указатель на небольшую структуру типа CLIENTCREATESTRUCT. Это окно охватывает всю рабочую область главного окна и обеспечивает основную поддержку MDI. Цветом окна является системный цвет COLOR_APPWORKSPACE.
Окна документов называются дочерними окнами (child windows). Эти окна создаются путем инициализации структуры типа MDICREATESTRUCT и посылки окну - сообщения WM_MDICREATE с указателем на эту структуру.
Окна документов являются дочерними окнами окна-клиента, которое, в свою очередь, является дочерним окном главного окна. Для главного окна и для каждого типа дочерних окон, которые поддерживаются в приложении, необходим класс окна (оконная процедура). Для окна администратора - оконная процедура не нужна, поскольку ее класс окна предварительно зарегистрирован в системе.
Для поддержки MDI в Windows имеется один класс окна, пять функций, две структуры данных и двенадцать сообщений. О классе окна MDICLIENT и структурах данных CLIENTCREATESTRUCT и MDICREATESTRUCT уже упоминалось. Две из пяти функций заменяют в приложениях MDI функцию DefWindowPro c: вместо вызова функции DefWindowProc для всех необрабатываемых сообщений, оконная процедура главного окна вызывает функцию DefFramePro c, а оконная процедура дочернего окна вызывает функцию DefMDIChildPro c. Другая характерная функция MDI TranslateMDISysAccel используется так же, как функция TranslateAccelerator.
Если в дочерних окнах MDI выполняются протяженные во времени операции, рассмотрите возможность их запуска в отдельных потоках. Это позволит пользователю покинуть дочернее окно и продолжить работу в другом окне, пока первое дочернее окно решает свою задачу в фоновом режиме. В Windows специально для этой цели имеется новая функция CreateMDIWindo w. Поток вызывает функцию CreateMDIWindow для создания дочернего окна MDI; таким образом, окно действует исключительно внутри контекста потока. В программе, имеющей один поток, для создания дочернего окна функция CreateMDIWindow не требуется, поскольку то же самое выполняет сообщение WM_MDICREATE.
Программа MDIDEMO поддерживает два типа предельно простых окон документов: в одном в центре рабочей области выводится фраза: "Hello, World!", а во втором отображается прямоугольник. С каждым из этих двух типов окон документов связано свое меню.
Часть FrameWndProc связана с обработкой сообщений WM_COMMAND, которые информируют о выборе какого – либо пункта меню. Как обычно, параметр wParam сообщения в FrameWndProc содержит идентификатор меню.
При значениях параметра wParam IDM_NEWHELLO и IDM_NEWRECT, FrameWndProc должна создать новое окно документа. Это требует инициализации полей структуры MDICREATESTRUCT (часть которых соответствует параметрам функции CreateWindo w) и отправки окну – сообщения WM_MDICREATE с параметром lPara m, равным указателю на эту структуру. Затем окно создает дочернее окно документа. FrameWndPro c, вызывая функцию CreateMDIWindo w, могла бы сама создать это дочернее окно. Для программы, имеющей один поток, такой, как MDIDEMO, можно выбрать любой из этих методов.
Как правило, поле szTitle структуры MDICREATESTRUCT является именем файла, соответствующего документу. В поле style могут быть заданы стили окна WS_HSCROLL, или WS_VSCROLL, или оба вместе, что позволяет включить в окно документа полосы прокрутки. (ShowScrollBar для вывода полос прокрутки на экран вызывать не обязательно). В поле style могут быть также указаны стили WS_MINIMIZE или WS_MAXIMIZE для первого появления окна документа в свернутом или развернутом состоянии.
Поле lParam структуры MDICREATESTRUCT дает возможность главному и дочернему окну использовать некоторые общие переменные. Этому полю можно присвоить значение описателя памяти, соответствующего блоку памяти, содержащему структуру. При обработке сообщения WM_CREATE в дочернем окне документа , параметр lParam - это указатель на структуру CREATESTRUCT, а поле lpCreateParams этой структуры - это указатель на структуру MDICREATESTRUCT, используемую для создания окна.
При получении сообщения WS_MDICREATE окно создает дочернее окно документа и добавляет заголовок окна к нижней части подменю, заданного в структуре MDICREATESTRUCT, которая используется для создания окна. Когда программа MDIDEMO создает свое первое окно документа, этим подменю является подменю File меню MdiMenuInit. Позже мы увидим, как этот список документов переносится в подменю Windows меню MdiMenuHello и MdiMenuRect.
В меню может быть перечислено до девяти документов, перед каждым из которых ставится номер от 1 до 9. Номер подчеркивается. Если создается более девяти окон документов, то за этим списком появляется пункт меню "More windows". Выбор этого пункта вызывает появление окна диалога содержащего список, в котором перечислены все окна документов. Поддержка такого списка документов — это одно из самых лучших характеристик поддержки MDI в Windows.
2.5 Динамически подключаемые библиотеки
До сих пор мы использовали множество функций API для создания окон и оконных процедур, рисования, работы с клавиатурой и мышью, ввода-вывода. Все эти функции работали исправно, и вы не задумывались над вопросом: где расположены эти функции и каким образом они подключаются к вашей программе. Все, что вам необходимо было сделать, это подключить соответствующий заголовочный файл (чаще всего это был < windows.h >) и вызвать необходимую функцию. Все остальные действия по включению функции в вашу программу среда программирования делала автоматически. Теперь пришла пора рассмотреть механизмы, обеспечивающие возможность использования функций.
Начнем с рассмотрения самого обыкновенного механизма использования функции, определенной в вашей программе. Например, вы создаете программу вычисления факториала и определяете внутри программы функцию, которая непосредственно этот факториал вычисляет:
#include "iostream.h"
// Функция вычисления факториала
int NFactorial(int N)
{
if (N==1) return 1
else return NFactorial(N-1) * N;
}
// Основная программа
int main()
{
cout<<NFactorial(3)<<endl;
return 0;
}
Таким образом, ваша функция расположена прямо в тексте программы.
Статическое связывание второго вида подразумевает использование в вашей программе функций, определенных в других файлах (библиотеках). Файлы-библиотеки, как правило, имеют расширение *.lib и подключаются к вашему исполняемому файлу (*.exe) только на этапе компиляции и связывания. Таким образом, они не компилируются заново, их объектный код (аналог файла *.obj) уже существует, и прикомпилируется к вашему файлу (*.obj) во время компиляции. Единственное, что необходимо сделать, это подключить нужный файл –заголовок (*.h) в текст программы.
И, наконец, вы имеете возможность использовать динамически подключаемые библиотеки (*.dll). Функции, находящиеся в них, подключаются к вашему исполняемому файлу (*.exe) только в момент вызова, то есть в тот момент, когда программа выполняется и идет обращение к указанной функции. Таким образом, функция не компилируется вместе с вашей программой, не участвует в процессе связывания и не содержится в вашем *. exe файле. Такой подход имеет неоспоримые преимущества:
1) Часто используемые функции хранятся в отдельных файлах. Например, все функции API реализованы в DLL и поставляются вместе с операционной системой. Таким образом, все программы под Windows имеют возможность использовать одни и те же функции.
2) Нет необходимости помещать все функции программы в *. exe файл. Их можно подгружать по мере надобности.
3) Возможность использования новых версий функций ( dll -файлов) без перекомпиляции исполняемых модулей (exe -файлов).
Процесс создания динамической библиотеки проходит в два этапа. Первый из них заключается в создании файла-заголовка (*. h), который определяет основные свойства проекта.
С помощью "визарда" среды Microsoft Visual C++ создайте новый проект, выбрав в качестве типа проекта Dinamic Linked Library , после чего определите "пустой проект" (empty project). Теперь вам предстоит самостоятельно создать файлы проекта. Пусть имя вашего проекта будет funlib .
Создайте файл заголовка – funlib.h (при помощи меню File\New..., выбрав файл-заголовок). В этом файле наберите следующий текст:
// File funlib.h
#define EXPORT extern "C" __declspec(dllexport)
EXPORT BOOL CALLBACK return333();
EXPORT int CALLBACK MyInc(int i);
Первая строка файла определяет некоторую директиву EXPORT , которая будет использоваться для подключения сервисов, необходимых для создания ссылок на экспортируемые функции (то есть функции, которые могут быть использованы или импортированы другими программами). Следующие две строки являются предварительным объявлением функций, директива EXPORT и делает их динамическими функциями.
Теперь осталось написать обычный текст программы *.cpp , который мало чем отличается от обычного:
//funlib.cpp
#include <windows.h>
#include <string.h>
#include "fulib.h"
int WINAPI DllMain(HINSTANCE hInstance, DWORD fdwReason, PVOID pvReserved)
{
return TRUE;
}
EXPORT BOOL CALLBACK EdrCenterText()
{
return 333;
}
EXPORT int CALLBACK MyInc(int i)
{
return ++i;
}
Незнакомой здесь является только функция DllMain, которая является аналогом функции main для консольных приложений и функции WinMain для приложений, написанный под Windows. Эта функция автоматически вызывается при загрузке любой dll. Возвращаемое значение TRUE свидетельствует об успешной загрузке и инициализации внутренних ресурсов. Остальные две функции являются обычными функциями пользователя, а директива EXPORT уже нам знакома. Все. Компилируем проект, и dll готова!
Настала пора ее использования. Для этого создадим обычное консольное приложение Win32 и назовем его usedll. Для использования funlib.dll необходимо выполнить следующие: поместить в каталог проекта файлы funlib.h и funlib.lib. Второй файл является результатом компиляции предыдущего проекта, и его можно найти в каталоге Debug. Кроме этого, в меню Project\Settings\Link. Категория General, поле Object\library modules необходимо вписать имя файла-библиотеки для организации настроек связывания. Текст программы usedll.cpp приведен ниже.
// usedll.cpp : Defines the entry point for the console application.
#include "stdafx.h"
#include "iostream.h"
#include "funlib.h"
int main(int argc, char* argv[])
{
cout<<return333()<<endl;
cout<<MyInc(5)<<endl;
return 0;
}
Данная программа выполнится, если в каталоге, где располагается файл usedll.exe, расположен файл динамической библиотеки funlib.dll.
В заключение следует отметить, что, используя механизмы динамического связывания, можно определять не только функции, но переменные и даже классы.
Второй способ использования DLL.
Рассмотренный выше способ написания программы, использующей динамически подключаемые библиотеки, пригоден только в том случае, когда вы сами создали библиотеки, или, по крайней мере, вы имеете в наличии файл библиотеки *.lib. Однако очень часто случается так, что есть только *.dll (или она только планируется). В этом случае можно использовать другой способ, который не требует для компиляции проекта наличия файлов, связанных с вызываемой *.dll. Применение данного способа заключается в следующем:
1) Создаются прототипы функций, имеющие те же параметры, что и необходимые функции внутри *. dll . Для нашего примера это будет выглядеть так:
typedef BOOL (WINAPI * Inc)(int i);
2) Объявляется переменная типа указателя на данную функцию:
Inc pI;
3) В программе осуществляется загрузка библиотеки:
HINSTANCE hL;
hL=LoadLibrary("funlib.dll");
4) объявленному указателю на функцию присваивается адрес функции из *.dll:
pI=(Inc)GetProcAddress(hL,(LPCSTR)2);
5) Функция используется по назначению:
cout<<pI(6);
6) После использования выгружается из памяти:
FreeLibrary(hL);
Целиком рассмотренный пример выглядит следующим образом:
#include "stdafx.h"
#include "iostream.h"
#include "windows.h"
HINSTANCE hL;
typedef int (CALLBACK * Inc)(int i);
Inc pI;
int main(int argc, char* argv[])
{ hL=LoadLibrary("1111.dll");
pI=(Inc)GetProcAddress(hL,(LPCSTR)2);
cout<<pI(6);
FreeLibrary(hL);
return 0;
}
Наличие *. dll требуется только во время запуска *.exe файла.
2.6 Представление графической информации
Формат DIB (device independent bitmap) содержит таблицу цветов, которая содержит информацию о преобразовании пикселей в RGB формат. Фактически, данный формат не является объектом GDI, однако является очень удобной формой для хранения и передачи изображения между программами и компьютерами. Каждому пользователю компьютера известен этот формат – это не что иное, как файл с расширением *. bmp. Приведем описание формата этого файла. Файл *. bmp начинается с секции заголовка, определенной структурой BITMAPFILEHEADER . Эта структура имеет пять полей.
Таблица 3
|
Поле |
Размер |
Описание |
|
bfType |
WORD |
Байты «ВМ» для битовых образов |
|
bfSize |
DWORD |
Общий размер файла |
|
bfReserved1 |
WORD |
Установлено в 0 |
|
bfReserved2 |
WORD |
Установлено в 0 |
|
bfOffBits |
DWORD |
Смещение битового образа от начала файла |
За этой информацией следует другой заголовок, определенный структурой BITMAPINFOHEADER. Структура имеет 11 полей.
Таблица 4
|
Поле |
Размер |
Описание |
|
biSize |
DWORD |
Размер структуры в байтах |
|
biWidth |
LONG |
Ширина битового образа в пикселях |
|
biHaight |
LONG |
Высота битового образа в пикселях |
|
biPlanes |
WORD |
Установлено в 1 |
|
biBitCount |
WORD |
Число битов цвета на пиксель (1,4,8,24) |
|
biCompression |
DWORD |
Схема компрессии (если нет – 0) |
|
biSizeImage |
DWORD |
Размер битов битового образа в байтах (нужен только при компрессии) |
|
biXPelsPerMeter |
LONG |
Разрешение в пикселях на метр по горизонтали |
|
biYPelsPerMeter |
LONG |
Разрешение в пикселях на метр по вертикали |
|
biClrUsed |
DWORD |
Число цветов, используемых в изображении |
|
biClrImportant |
DWORD |
Число важных цветов в изображении |
Приведенная структура может иметь различный размер, определяемый полем biSize. Первые 5 параметров являются обязательными. Остальные могут присутствовать в файле, могут и нет. Кроме этого, пользователь может добавлять свои оригинальные записи в конец структуры. Если biClrUsed установлено в ноль и число битов на пиксель равно 1,4,8, то сразу за данной структурой следует таблица цветов, состоящая из двух или более структур RGBQUAD (при 1 – две, при 4 – шестнадцать, и т.д. ), каждая из которых определяет значение цвета.
Таблица 5
|
Поле |
Размер |
Описание |
|
rgbBlue |
BYTE |
Интенсивность голубого |
|
rgbGreen |
BYTE |
Интенсивность зеленого |
|
rgbRed |
BYTE |
Интенсивность красного |
|
rgbReserved |
BYTE |
Равно 0 |
Число структур RGBQUAD может быть напрямую задано в поле biClrUsed.
За таблицей цветов следует массив битов, определяющих битовый образ. Этот массив начинается с нижней строки пикселей. Каждая строка начинается с левого пикселя. Каждый пиксель представлен 1, 4, 8 или 24 битами. В первых трех случаях число, записанное в битовом образе, определяет номер RGBQUAD - структуры в таблице цветов. В случае 24-х бит – это, фактически, и есть 3 байта RGB -представления цвета. В последнем случае таблица цветов может отсутствовать.
Для вывода битовых образов, не зависящих от устройства, существует несколько функции GDI . Первая из них позволяет копировать битовый образ в контекст устройства:
int SetDIBitsToDevice(HDC hdc, // указатель на контекст устройства;
int XDest, // x-координата верхнего левого угла;
int YDest, // y-координата верхнего левого угла;
DWORD dwWidth, // ширина выводимого изображения;
DWORD dwHeight, // высота выводимого изображения;
int XSrc , // x-координата отступа в изображении;
int YSrc, // y-координата отступа на контексте;
UINT uStartScan, // первая сканируемая линия изображения;
UINT cScanLines, // число сканируемых линий;
CONST VOID *lpvBits, // адрес битового образа;
CONST BITMAPINFO *lpbmi, //адрес структуры BITMAPINFO;
UINT fuColorUse // признак RGB или палитры;
).
Следует заметить, что в функции используется структура BITMAPINFO, а не присутствующая в файле BITMAPINFOHEADER , которая определена в Windows как:
typedef struct tagBITMAPINFO
{
BITMAPINFOHEADER bmiHeader; // Уже знакомая нам структура;
RGBQUAD bmiColors; // Таблица цветов;
} BITMAPINFO.
Рассмотренная функция производит копирование битов в выбранный контекст. Другая функция, позволяет при этом масштабировать выводимое изображение, т.е. автоматически изменяет размер картинки до размеров области вывода:
int StretchDIBit
(
HDC hdc, // указатель на контекст устройства;
int XDest, // x-координата верхнего левого угла в контексте;
int YDest, // y-координата верхнего левого угла в контексте;
int nDestWidth , // ширина выводимого изображения в контексте;
int nDestHeight, // высота выводимого изображения в контексте;
int XSrc, //x-координата верхнего левого угла выводимой части изображения;
int YSrc, //у-координата верхнего левого угла выводимой части изображения int nSrcWidth , // ширина выводимого изображения в битовом образе;
int nSrcHeight, //высота выводимого изображения в битовом образе;
CONST VOID *lpBits, // адрес битового образа;
CONST BITMAPINFO *lpBitsInfo, // адрес структуры BITMAPINFO
UINT iUsage, // флаг использования цвета;
DWORD dwRop // растровая операция;
).
Флаг использования цвета определяет, есть ли в структуре BITMAPINFO таблица палитры (значение флага - DIB_PAL_COLORS) или в битовом образе содержится полная информация о цвете (DIB_RGB_COLORS). Последний параметр функции определяет код растровой операции. Наиболее часто используемые из них:
BLACKNESS. Заполняет выбранную область приемника черным цветом;
DSTINVERT. Инвертирует выбранную область приемника;
NOTSRCCOPY. Копирует изображение с инверсией;
SRCCOPY. Копирует изображение;
WHITENESS. Заполняет выбранную область приемника белым цветом.
Вид данного битового образа организован так, чтобы облегчить вывод графической информации (битов) на конкретное физическое устройство. Наиболее часто используемые форматы в этом случае – организация набора цветовых битов на пиксель или набора цветовых плоскостей.
В первом случае каждому пикселю на экране ставится в соответствие некоторое количество бит. Например, если монитор может отобразить 256 цветов, то используется 8 байт на один пиксель. Для каждой скан-линии (строки растра) первый байт представляет цвет самого левого пикселя, второй байт – следующего пикселя и т.д. Подобная организация видеопамяти, бала, например в CGA – мониторах.
Пример второго вида организации битовых образов – это EGA и VGA - мониторы, которые в большинстве стандартов поддерживают плоскостное представление изображения. Цветной битовый образ для 16-цветного VGA использует 4 цветовые плоскости для представления 16 цветов. Массив битов начинается с верхней скан-линии. Цветовые плоскости для каждой скан-линии хранятся последовательно: красная плоскость - первой, зеленая плоскость – второй, затем голубая плоскость и плоскость интенсивности. Каждая плоскость имеет свой адрес в оперативной памяти.
На основе вышеизложенного можно сделать вывод, что в каждом конкретном случае зависимый битовый образ организован по-разному. И если программа создает сама битовый образ (например, на основе функций CreateBitmap, CreateBitmapInderect), то она должна сама определять тип, количество цветовых плоскостей. Формат данных функций следующий:
HBITMAP MyBitmap 1, MyBitmap 2;
BITMAP MyStruct ;
MyBitmap 1=CreateBitmap (nWidth, nHeight, cPlanes, cBitsPerPel, lpvBits);
MyBitmap 2=CreateBitmap Inderect (& MyStruct);
где nWidth – ширина создаваемого битового образа,
nHeight - высота создаваемого битового образа,
cPlanes - количество битовых плоскостей,
cBitsPerPel - число битов на один пиксель,
lpvBits - указатель на битовый образ.
Структура BITMAP содержит перечисленные данные непосредственно.
Однако более легким вариантом является создание совместимого битового образа на основе контекста устройства. Это можно сделать при помощи функции:
HBITMAP MyBitmap;
MyBitmap = CreateCompatibleBitmap (hdc, xWidth, yHeght);
где hdc – описатель контекста устройства, остальные два параметра определяют ширину и высоту создаваемого битового образа. Созданный таким образом битовый образ будет иметь структуру, определяемую характеристиками устройства.
Теперь перейдем к вопросу вывода зависимого битового образа на конкретное устройство. Для данного вида графической информации не существует функций, осуществляющих непосредственный вывод в контекст устройства (подобных SetDIBitsToDevice и StretchDIBits для независимых битовых образов) на основе описателя битовых образов (HBITMAP). Для их вывода используется следующий механизм: битовый образ, выбранный в одном контексте, может быть скопирован в другой контекст. Таким образом, в процессе участвуют два контекста: первый (обычный), в который необходимо скопировать битовый образ, и второй, в котором содержится изображение. Второй контекст, в данном случае, необходимо создать; создается он в памяти и не соответствует конкретному устройству вывода. Он так и называется – контекст памяти. Для того чтобы дальнейшая работа по копированию битовых образов происходила без проблем, оба контекста должны быть совместимыми, или, говоря другими словами, контекст памяти необходимо создать на основе контекста устройства. Это делается при помощи следующей функции:
HDC hdcMem;
hdcMem = CreateCompatibleDC (hdc);
где hdc – описатель контекста, куда будет вестись вывод изображения.
Второй этап заключается в выборе битового образа в контекст памяти по тому же образу, каким любой объект GDI выбирается в контекст устройства:
SelectObject ( hdcMem , MyBitmap );
И только после этого можно скопировать битовый образ в контекст устройства:
BitBlt (hdc, xDest, yDest, xWidth, yHeight, hdcMem, xSrc, ySrc, dwROP);
где xDest, yDest, xWidth, yHeight определяют координаты прямоугольника на контексте устройства, в который осуществляется вывод изображения, xSrc;
ySrc – определяют начальное положение угла источника, с которого начинается вывод;
dwROP – идентификатор знакомой нам растровой операции.
После окончания работы с контекстом памяти, его необходимо удалить:
DeleteDC (hdcMem).
Существует и аналог масштабируемого вывода для зависимых битовых образов:
StretchBlt (hdc, xDest, yDest, xDestWidth, yDestHeight, hdcMem, xSrc, ySrc, xDSrcWidth, ySrctHeight , dwROP), в которой напрямую указываются размеры выводимого изображения и размеры приемника.
Следует отметить, что данные функции работают для любого копирования битовых образов между любыми контекстами.
3 Варианты задания курсовой работы
1 вариант. Разработать полноправное оконное приложение, в результате выполнения которого на экране появляется окно, содержащее стандартные элементы (заголовок, рамку, кнопки управления), соответствующее теме курсовой работы надпись. Окно можно перемещать, минимизировать, максимизировать, свертывать. Можно также изменять его размеры с помощью мыши и наблюдать программу на панели задач.
2 вариант. Разработать потоковую программы, в которой будет показано девять из двенадцати сообщений MDI. Эти сообщения имеют префикс WM_MDI. Главное окно посылает одно из этих сообщений окну - для выполнения операции над дочерним окном или для получения информации о дочернем окне (главное окно посылает сообщение WM_MDICREATE окну - для создания дочернего окна). Исключение составляет сообщение WM_MDIACTIVATE: в то время, как главное окно может послать это сообщение окну – для активизации одного из дочерних окон, окно также посылает сообщение тем дочерним окнам, которые будут активизированы, и тем, которые потеряют активность, чтобы проинформировать их о предстоящем изменении.
3 вариант. Разработать приложение с представлением графической информации, используя битовые образы, не зависящие от устройства.
4 вариант. Разработать приложение с представлением графической информации, используя битовые образы, зависящие от устройства.
5 вариант. Разработать приложение с динамически подключаемыми библиотеками при компиляция программы, используя статическое связывание первого вида.
6 вариант. Разработать приложение с динамически подключаемыми библиотеками при компиляция программы, используя статическое связывание второго вида.
7 вариант. Разработать приложение с использованием системных функций диспетчеризации и планирования потоков в Windows.
8 вариант. Разработать приложение с использованием системных функций управления процессами в Windows.
9 вариант. Разработать приложение с использованием системных функций синхронизации процессов и потоков, предотвращая тупики.
10 вариант. Разработать приложение с использованием системных функций работы с дескрипторами безопасности.
11 вариант. Разработать и описать диаграмму классов базы данных интернет-магазина.
12 вариант. Разработать и описать диаграммы прецедентов и последовательности интернет-магазина.
13 вариант. Разработать концептуальную модель антивирусной системы.
14 вариант. Разработать диаграмму развертывания Международного аэропорта.
15 вариант. Разработать, описать, обосновать архитектуру системы диагностики уровня знаний.
16 вариант. Разработать структурную модель операционной системы.
17 вариант. Разработать базу данных справочника лекарств.
18 вариант. Спроектировать антивирусную систему диаграммой состояний.
19 вариант. Разработать таблицу истинности принятия решения.
20 вариант. Разработать многокритериальную модель оценки уровня знаний.
21 вариант. Разработать базу знаний, основанную на правилах (не менее 3), 10 вариантов, принимающую решения определения наилучшего цветового решения.
22 вариант. Разработать метод, определяющий уровень сомнения пользователя при тестировании.
23 вариант. Разработать диаграмму деятельности системы «Банкомат».
24 вариант. Разработать диаграмму компонентов сайта АУЭС.
25 вариант. Разработать диаграмму последовательности поисковой системы сайтов.
26 вариант. Смоделировать систему тестирования диаграммой прецедентов.
27 вариант. Разработать техническое задание по основным пунктам на разработку интеллектуальной системы помощи.
28 вариант. Разработать техническую часть (технические требования) технического задания антивирусной системы.
29 вариант. Разработать техническое задание по специфическим требованиям базы справочника ГАИ.
30 вариант. Разработать техническое задание (психологические и экономические требования) базы данных телефонного справочника.
31 вариант. Описать метод шифрования ПО. Разработать модель и алгоритм работы.
32 вариант. Разработать модель работы информационной системы вуза.
33 вариант. Разработать модель документооборота банковской системы.
34 вариант. Разработка алгоритма и диаграммы деятельности работы системы автомата по выдаче лимонада.
35 вариант. Разработка структурной информационной модели работы банкомата.
36 вариант. Разработать модель работы информационной системы ВУЗа.
37 вариант. Разработать модель автоматизированной информационной системы деканата.
38 вариант. Разработать модель работы автомата по продаже напитков.
39 вариант. Разработать модель работы информационной системы гостиничного комплекса.
40 вариант. Разработать модель работы информационной системы складского учета.
4 Методика выполнения курсовой работы
Методика разработки программы и программной документации состоит из следующих этапов:
- техническое задание. Постановка задачи;
- определение структуры входных и выходных данных. Предварительный выбор методов решения задачи;
- определение требований к программе. Определение стадий, этапов и сроков разработки программы и документации на нее;
- разработка эскизного проекта. Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи;
- разработка технического проекта. Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Разработка структуры программы;
- разработка программы. Программирование и отладка. Разработка программных документов;
- подготовка и передача программы и программной документации для сопровождения.
4.1 Технология написания программы
4.2 Основные этапы разработки программы
К основным этапам разработки программной системы относятся следующие: постановка задачи, разработка, реализация, испытания эксплуатация системы. Эти этапы могут частично перекрываться. Так, формулирование задачи не обязательно должно заканчиваться в тот момент, когда начинается разработка программ и подготовка данных. Почти всегда продолжают возникать те или иные детали, требующие согласования с будущими пользователями. Первый шаг в проектировании прикладной программной системы заключается в точном формулировании целей программы. Общие требования к системе еще не создают полной картины.
По мере того, как проблемная ситуация проясняется, процедуры, рассматриваемые вначале как нечто единое, постепенно расчленяются на отдельные элементы. Метод исследования, который начинается с общего обзора системы и затем детализируется, приобретая иерархическую структуру с большим числом уровней, принято называть структурным анализом. Верхний уровень структурного анализа представляет собой функциональное описание системы. Составление функционального описания системы - это обобщение всей информации, касающейся целей проекта. Расчленение системы на функциональные элементы подчиняется вполне определенным правилам. Самое общее правило состоит в следующем: необходимо отделять то, что требуется сделать, от того, каким образом это можно сделать. Логические связи, существующие между различными элементами данных, составляют основу всего процесса проектирования. Были предложены различные методы построения этого процесса. В одних методах проектирование базируется на системном анализе, согласно которому на первом этапе составляется общий обзор функционирования системы и перерабатываемых в ней данных, после чего система постепенно расчленяется на все более мелкие составные части.
Другие методы исходят из базовых элементов какого-то одного класса, будь то данные или процедуры обработки, и целиком строятся на их основе. В любом случае центральную роль играет исследование структуры и взаимосвязей, а не частные вопросы машинной реализации. Проектирование становится более целенаправленным, если в его основе лежат зависимости между данными, присущие решаемой проблеме, а не условия, диктуемые вычислительной средой.
На этапе реализации кодирование модулей не вызывает особых затруднений, если проект продуман достаточно тщательно.
Процесс написания программ включает несколько этапов и является итерационным, т.е. некоторые этапы надо повторять по мере уточнения деталей программы. В последнее время общее признание получил модульный принцип построения программ. Под модульным принципом программирования понимается разделение программы на части по некоторым установленным правилам. Программы разбиваются на модули для того чтобы:
– упростить их разработку и реализацию;
– облегчить чтение программ;
– упростить их настройку и модификацию;
– облегчить работу с данными, имеющими сложную структуру;
– избежать чрезмерной детализации алгоритмов;
– обеспечить более выгодное размещения программ в памяти ЭВМ.
Методы проектирования программ, основанные на модульном принципе, делятся на три группы:
– методы проектирования "сверху-вниз" (нисходящее проектирование);
– "снизу-вверх" (восходящее проектирование);
– "изнутри к границам" (метод расширенного ядра).
Разбиение на модули осуществляется эвристическим путем. В дальнейшем мы будем использовать метод программирования “сверху-вниз”.
1) Постановка задачи. Перед началом программирования необходимо четко поставить задачу. При постановке задачи необходима консультация с заказчиком и пользователем, ибо часто заказчик не совсем точно представляет возможности системы, а разработчик программ - условия эксплуатации программы. Кроме того, при постановке задачи необходимо уяснить:
- для какой цели разрабатывается программа;
- какие данные обрабатываются и их количество, форматы, где хранятся, как вводятся и выводятся, срок хранения данных и т.д.;
- какие отчетные документы должна готовить программа и их форма;
- каков интерфейс программы с пользователем (виды экрана, и т.д.);
- какие задачи связаны, а какие самостоятельные;
- имеются ли критические ко времени обработки участки программы;
- работает ли программа в сети, могут ли к ней обращаться несколько пользователей одновременно;
- другие вопросы, связанные с эксплуатацией программы.
Процесс постановки задачи - весьма ответственная часть работы, и от успешного и корректного его выполнения зависит успешное завершение задания, особенно на этапе отладки программы. (Известно, что на отладку программ уходит до 70% времени). Применительно к курсовой работе постановка задачи сводится к написанию расширенного описания задачи, содержащего:
- что необходимо получить в результате работы программы (документы, файлы, экран и т.д.);
- способ организации меню (в видеопамяти, с помощью функций 21h прерывания, "падающее", многоуровневое и т.д.);
- обработка ошибок от неправильных действий оператора или сбоев системы;
- окончание работы.
2) Составление структуры программы. Структура программы не является обязательным компонентом техдокументации и скорее нужна разработчику для иллюстрации связей между отдельными блоками и модулями программы. На основании структуры пишется перечень блоков при программировании сверху вниз.
После составления структурной программы выясняется количество блоков (модулей) программы, последовательность их выполнения, их названия.
3) Разработка блок-схем алгоритмов. Блок-схемы алгоритмов разрабатываются параллельно с написанием программы. Можно составлять блок-схему алгоритма для небольшого участка, если его кодировка вызывает затруднения. На этом этапе уточняются названия блоков программы для занесения в программу в виде комментария.
4) Hаписание текста программы. При методе программирования "сверху вниз" сначала пишутся псевдооператоры сегментов, операторы загрузки адресов сегментов, блочные комментарии программы. Hапример, для программ на Turbo Assembler'е:
TITLE aos.asm
Comment# Программная оболочка для создания многооконного меню. Программа позволяет задать конфигурацию меню, уровень вложений ограничивается числом хранимых образов экрана и не менее 3-х. Встроенные функции: просмотр директориев и переход в поддиректории, выбор в меню файла (для просмотра или других целей), управление перемещением курсора по меню, директориям (или тексту), просмотр текстов в буферах, расположенных за пределами программы. Разработчик Иванов В.В., гр. БВТ-13-00 #
.model small
.code
.stack 200h
;__________________________________________________________
Start: Push cs
Pop ds
<Здесь будет тело программы>
.........
exit: mov ah,4ch ;выход из программы
int 21h
End Start
Для программ, написанных на MASM:
;ОПРЕДЕЛЕHИЕ ЧИСЛА УСТАHОВЛЕHHЫХ ДИСКОВ ;ВОЗВРАЩАЕМЫХ СИСТЕМОЙ, ОПРЕДЕЛЕHИЕ ЧИСЛА
;ГИБКИХ ДИСКОВ,УПРАВЛЕHИЕ КУРСОРОМ И ВЫБОР ДИСКА
;(файл DISKI.ASM)
CSEG SEGMENT
ASSUME CS:CSEG,DS:CSEG
begin: push cs
pop ds
jmp v1
fr1 db 'ОШИБКА',10,13,'$'
v1:
<Здесь будет тело программы>
.........
exit: mov ah,4ch ;выход из программы
int 21h
CSEG ends
end begin
На следующем этапе по методу программирования "сверху вниз" определяется структура программы, и заполняются названия элементов программы. Для конкретности рассмотрим пример для следующего задания: "Разработать программу для переключения текущих дисков".
В этом задании поставлена только общая задача, а ряд вопросов не определен, а именно: как определить число дисков, установленных на конкретной машине, причем, программа должна определять число гибких, жестких и логических дисков; как вывести на экран существующие диски; каков вид меню; как управлять выбором диска; как управлять движением курсора. Ответ на эти и другие, возникающие по ходу дела вопросы, необходимо получить перед или во время написания программы.
На основании самых общих соображений запишем структуру программы в виде последовательности операций (записаны в виде комментариев).
;ОПРЕДЕЛЕHИЕ ЧИСЛА УСТАHОВЛЕHHЫХ ДИСКОВ ;ВОЗВРАЩАЕМЫХ СИСТЕМОЙ, ОПРЕДЕЛЕHИЕ ЧИСЛА
;ГИБКИХ ДИСКОВ,УПРАВЛЕHИЕ КУРСОРОМ И ВЫБОР ;ДИСКА
;(файл DISKI.ASM)
CSEG SEGMENT
ASSUME CS:CSEG,DS:CSEG
begin: push cs
pop ds
jmp v1
;----------------
ch_d db 0;здесь поместим число дисков, возвр. системой
diski db 23 dup(0),'$'; буфер для помещения списка дисков
fr1 db 'ОШИБКА',10,13,'$'
;----------------
v1: ;определить, какой диск является текущим?
;сколько гибких дисков установлено?
;сформировать меню
;вывести меню
;вызвать процедуру управления курсором и выбором текущего ;диска
call UPRCUR
exit: ;выйти из программы
mov ah,4ch
int 21h
<Здесь будет помещены процедуры. Данный участок оформлен в виде процедуры только для примера, чтобы показать, как оформлять процедуру. Но это не нарушает логики работы программы!>
UPRCUR proc ;процедура опрашивает клавиатуру, анализирует
;нажатую клавишу и перемещает курсор
;выбирает по меню диск и делает его текущим
;(по <Enter>,либо выходит из процедуры без
;всяких действий по <Esc>
ret
UPRCUR endp
CSEG ends
end begin
Теперь наша программа готова к кодированию: надо написать макрокоманды (если хотите), процедуры и текст программы.
При описании процедуры необходимо в виде комментария описать, что делает процедура, какие переменные необходимо задать перед вызовом процедуры и т.д. Заметим, что имена процедур и макрокоманд по ЕСПД пишут заглавными буквами.
Рассмотрим пример составления программы на ассемблере (кодирование), вставляя рассуждения о том, как написать фрагмент программы между выделенными двойным подчеркиванием участками. Естественно, что из готовой программы эти участки необходимо удалить (строки начинаются не с точки с запятой<;>.
При написании программы постепенно заполняются и уточняются первоначально написанные комментарии и текст программы.
Описанный процесс написания программы может повторяться итерационно до тех пор, пока программа не станет удовлетворять разработчика. Например, на первом этапе программирования могло отсутствовать циклическое перемещение курсора по меню. Может быть, на последующих этапах разработчик захочет сделать меню более красочным, убрать "мусор" с экрана. Мало ли чего еще можно пожелать! Возможно, данная программа является только небольшим фрагментом более сложной программы и ее надо встроить в нее. Если программа построена корректно и работает, то особых проблем это не вызовет.
4.3 Пробная эксплуатация
После того как программа отлажена и начала что-то выполнять, необходимо начать ее "эксплуатировать", то есть поработать с ней в качестве оператора. Может быть, обнаружите, что отдельные операции неудобны по интерфейсу (например, требуют выполнения нескольких операций), и вы хотите улучшить интерфейс, или вы обнаружите, что при некоторых нештатных (не предусмотренных программой) ситуациях программа зависает и требует перегрузки системы, или обнаружится логическая ошибка. Программу следует доработать. Обычно на этом этапе происходит доработка "защиты от дурака", то есть от неправильных действий оператора, от неправильных данных и так далее. Замеченные недостатки устраняются, то есть повторяются пункты 3 и 4. Разработчик и дальше должен следить за работой своей программы. Это называется сопровождением программы.
4.4 Оформление техдокументации
Кроме пояснительной записки, оформленной в соответствии с вышеприведенными правилами, необходимо составить инструкции.
Инструкция пользователю содержит основные сведения по запуску программы сообщения об ошибках и необходимые действия при сбоях. Могут указываться правила хранения и обновления данных и так далее.
4.6 Инструкция системному программисту
Инструкция системному программисту содержит сведения о том, как устанавливать данную программу в системе (если требуется создать системную программную среду), где хранится эталонный текст программы, что делать при крахе системы и тому подобные сведения. Инструкция системному программисту нужна не для всех программ и пишется при необходимости.
Инструкция оператору требуется в том случае, когда пользователь и оператор - разные лица. Например, оператором может быть лицо, которое только вводит данные в файл данных, а пользуется этими данными пользователь.
4.8 Описание контрольного примера
Описание контрольного примера требуется в том случае, когда программа перед эксплуатацией требует настройки. В этом случае контрольный пример служит для обучения персонала и отладки системы.
5 Требования к оформлению курсовой работы
5.1 Правила оформления пояснительной записки
Курсовая работа оформляется в соответствии с требованиями соответствующих стандартов АУЭС. Текст пояснительной записки набирается на компьютере в текстовом редакторе Microsoft Word на одной стороне листа бумаги формата А4. Общий объем 40 - 45 страниц. С левой стороны листа должны быть поля шириной 30 мм, листы подшиваются в папку вместе с диаграммами, схемами и другими иллюстративными материалами. Все иллюстрации должны быть пронумерованы и снабжены подписями и ссылками в тексте.
Материалы в пояснительной записке следует располагать в следующем порядке:
- титульный лист;
- содержание;
- введение;
- выбор системных функций и разработка алгоритма;
- схема алгоритма, общее описание алгоритма и (или) функционирования программы и обоснование принятых технических решений;
- текст программы с необходимыми комментариями;
- описание программы (сведения о логической структуре и функционировании программы);
- заключение;
- список литературы;
- приложения.
В пояснительной записке должны быть выдержаны единые обозначения и единые размерности для используемых параметров. Допускаются сокращения слов, терминов, обозначений только общепринятые. Законченная записка подписывается студентом и руководителем проекта. Изложение должно быть кратким и четким, без повторений, количество иллюстраций должно быть минимальным, но достаточным для пояснения изложенного.
5.2 Правила оформления графического материала
Графическая часть проекта является не иллюстрационным материалом, а технической документацией на разработанную студентом программу.
Графический материал, помещенный в пояснительной записке, а также на листах, по формату, условным обозначениям, шрифтам и масштабам должен соответствовать требованиям единой системы конструкторской документации (ЕСКД), единой системы программной документации (ЕСПД), ГОСТ 19.701-90 «Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения», и ГОСТ 19.101-77 «Виды программ и программных документов».
6 Требования к защите курсовой работы
6.1 График выполнения курсовой работы
Курсовая работа выполняется в течение 15 учебных недель, и сроки выполнения отдельных этапов курсовой работы устанавливаются таким образом, чтобы обеспечивалась равномерная недельная трудоемкость проведенной работы. Сдача и защита курсовых работ осуществляется на 13-15 неделях семестра.
Защита курсовой работы производится перед преподавателем.
Студент допускается к защите при условии наличия подписанной руководителем и студентом пояснительной записки и расчетно-графической части проекта.
Для защиты студенту отводится 10 – 15 минут на изложение содержания работы; в процессе защиты преподаватель высказывает свои замечания; выявленные ошибки проекта должны быть отмечены красным карандашом.
По результатам защиты (доклад, ответы на вопросы, качество проекта) выставляется оценка в ведомости и на титульном листе пояснительной записки. В случае выявления принципиальных ошибок проект возвращается на доработку.
После защиты студент должен сдать пояснительную записку руководителю проекта.
В случае неудовлетворительной оценки назначается повторная защита с устранением всех ошибок проекта или с выдачей нового задания.
При отсутствии достаточного материала по проекту в контрольные сроки, студенту, как правило, выдается новое задание.
1. Джеффри Рихтер. Windows. Создание эффективных Win32- приложений с учетом специфики 64-разрядной версии Windows. - СПб., М., Харьков, Минск: “Русская редакция”, “Питер”, 2001 (Серия: для профессионалов).
2. Ал Вильямс. Системное программирование в Windows 2000. – СПб.: Питер, 2001.
3. Джонсон М. Харт. Системное программирование в среде Win32. – М.: Издательский дом “Вильямс”, 2001.
4. Румянцев П.В. Азбука программирования в Win32 API. – М.: Горячая линия – телеком, 2001.
5. Румянцев П.В. Работа с файлами в Win32. – М.: Горячая линия – телеком, 2001.
6. Ганеев Р.М. Проектирование интерфейса пользователя средствами Win32 API. – М.: Горячая линия – телеком, 2001.
7. Хелен Кастер. Основы Windows NT и NTFS: Пер. с англ. -М.: Изд. Отдел Русская редакция, 1996 г.
8. Ресурсы Windows NT: Пер с англ. -СПб.: BHV - Санкт-Петербург. 1996.
9. Джон Д. Рули и др. Сети Windows NT 4.0. Пер. с англ. -Киев: Издательская группа BHV, 1997.
Содержание
Введение
1 Цели и задачи курсовой работы
1.1 Цель курсовой работы
1.2 Задачи курсовой работы
2 Краткая теоретическая часть
2.2 Контекст устройства
2.3 Порядок обработки сообщений, цикл обработки сообщений
2.4 Многооконный интерфейс
2.5 Динамически подключаемые библиотеки
2.6 Представление графической информации
3 Варианты задания курсовой работы
4 Методика выполнения курсовой работы
4.1 Технология написания программы
4.2 Основные этапы разработки программы
4.3 Пробная эксплуатация
4.4 Оформление техдокументации
4.5 Инструкция пользователю
4.6 Инструкция системному программисту
4.7 Инструкция оператору
4.8 Описание контрольного примера
5 Требования к оформлению курсовой работы
5.1 Правила оформления пояснительной записки
5.2 Правила оформления графического материала
6 Требования к защите курсовой работы
6.1 График выполнения курсовой работы
6.2 Порядок защиты
Список литературы
Сводный план 2012 г. поз.220