УЗНАЙ ЦЕНУ

(pdf, doc, docx, rtf, zip, rar, bmp, jpeg) не более 4-х файлов (макс. размер 15 Мб)


↑ вверх
Тема/ВариантБиблиотека классов C++ для разработки оконных приложений
ПредметПрограммирование
Тип работыкурсовая работа
Объем работы16
Дата поступления12.12.2012
890 ₽

Содержание

Содержание Содержание 2 Аннотация 3 1. Введение 3 1.1. Глоссарий 3 1.2. Описание предметной области 3 1.3. Неформальная постановка задачи 4 1.4. Обзор существующих методов решения 4 1.5. Вывод 5 1.6. План работ 5 2. Требования к окружению 5 2.1. Требования к аппаратному обеспечению 5 2.2. Требования к программному обеспечению 5 2.3. Требования к пользователям 6 3. Требования к производительности 6 4. Требования к интерфейсу 6 5. Проект 8 5.1. Средства реализации 8 5.2. Модули и алгоритмы 8 6. Реализация 9 Заключение 9 Список литературы 9 Приложение 10 Демонстрационное приложение 10 Код приложения на bildigo 10 Код приложения на WinForms .NET 11

Введение

Аннотация Цель данной курсовой работы — разработка библиотеки классов С++ предназначенных для создания оконных приложений под ОС Windows. Библиотека должна обеспечивать поль-зователя возможностью создавать оконные приложения, где структура пользовательского интерфейса ясно просматривалась в описании класса окна. Для реализации данной цели бу-дут использованы особенности С++ (шаблоны, множественное наследование, пространства имен, стандартная библиотека, очередность вызовов конструкторов), причем только те, ко-торые предусмотрены стандартом языка. 1. Введение 1.1. Глоссарий STL (Standard Template Library) — Стандартная библиотека шаблонов, обеспечена в каждой реализации языка, содержит множество стандартах контейнеров (массив, список...), утилит, алгоритмов и пр. Дескриптор — уникальный идентификатор окна или другого объекта операционной системы 1.2. Описание предметной области Основой интерфейса в Windows являются окна. Каждое окно имеет свои параметры со-стояния, входные и выходные сообщения. Взаимодействие между окнами осуществляется через сообщения. Например, при нажатии кнопки мыши окну посылается сообщение об этом. Аналогичным образом окно получает сообщение в ответ на любое связанное с ним из-менение. Обработкой сообщений занимается специальная функция, называемая оконной процедурой. Каждое окно принадлежит к одному из оконных классов, содержащему общие свойства для группы окон. Ядро Windows предоставляет несколько стандартных классов, реализующих кнопки, списки, редактируемое поле и другие элементы управления. При соз-дании окна ему дается уникальный идентификатор, называемый дескриптором окна. Основой приложения является цикл обработки сообщений, который получает из очере-ди сообщение и направляет его на обработку соответствующей оконной процедуре с указа-нием дескриптора окна, идентификатора сообщения и параметров. [5] Традиционно при написании программ с использованием чистого WinAPI применяются методы структурного программирования. Однако операционную систему Windows можно считать объектно-ориентированной, т.к. все элементы управления (окна в том или ином ви-де) являются объектами. Таким образом, разработку части приложения отвечающей за поль-зовательский интерфейс можно рассматривать с объектно-ориентированной точки зрения и реализовывать ее на объектно-ориентированном языке, но для этого необходима библиотека, которая осуществит перевод структурного WinAPI на объектный язык. Причем библиотека должна не допускать проявления WinAPI в программе кроме случаев явного выигрыша в производительности или невозможности другого подхода. Таким образом, каждому типу окна можно поставить в соответствие класс, оконной процедуре — виртуальную функцию, ситуации, когда в окне расположена, например, кноп-ка, — отношение «содержит», тогда время жизни дескриптора должно быть связано со вре-менем жизни объекта класса, а цикл обработки сообщений должен быть спрятан в библиоте-ку. Кроме того, даже рисование графических примитивов (линий, эллипсов и пр.) можно све-сти не к процедуре рисования, а к созданию объекта, например, «квадрат», который должен сам себя перерисовывать в случае необходимости. 1.3. Неформальная постановка задачи Необходимо разработать библиотеку классов C++, предоставляющую возможности: • Создавать несложный пользовательский интерфейс, при минимуме исходного кода. • Использовать стандартный C++ без расширений языка. • Не использовать макроподстановок. • Не допускать проявления элементов WinAPI. • Описание класса окна должно быть читаемо, т.е. есть возможность представить, как выглядит окно, глядя на описание класса. • Обработка сообщений должна быть реализована через переопределение вирту-альных функций, причем стандартное поведение предусматривает передачу управления соответствующему методу класса родительского окна. • Для рисования графических примитивов должны быть введены как процедуры рисования, так и классы соответствующих геометрических фигур. • Для обработки ошибок должен быть использован механизм «броса-ния/перехватывания» исключений. • Библиотека не должна быть жестко привязана к определенному шаблону ООП (например, архитектуре документ-представление). • Обеспечить механизм автоматического изменения размеров и положения эле-ментов окна при изменении размеров самого окна. Библиотека не обязана включать в себя множество экзотических элементов управления (например, аналоговые часы), но в ней должна быть предоставлена возможность реализации подобных контролов. Все классы библиотеки должны сопровождаться документацией, а так же необходимо описать методику разработки приложений на основе данной библиотеки, дополнив неболь-шим демонстрационным приложением. 1.4. Обзор существующих методов решения На текущий момент существует достаточно много решений этой проблемы: MFC, Qt, .NET WinForms, и т.д. (я не рассматриваю библиотеки, написанные не для C++) — однако они не все в полном объеме используют возможности языка (например шаблоны, множест-венное наследование), зато вводят свои специфические расширения, не всегда интуитивно понятные и требующие предварительного ознакомления. Достаточно простые интерфейсные вещи могут реализовываться в большом объеме кода — как результат программист отвлека-ется от основной задачи. Кроме того, описание, инициализация и отображение одного эле-мента окна рассредоточены по разным частям программного кода, и потому представить, как должно выглядеть окно, глядя на описание класса, очень сложно, а редактирование весьма затруднено. Библиотека MFC, которая создавалась как надстройка к WinAPI, нарушает неко-торые принципы объектно-ориентированного программирования, что негативно сказывается на архитектуре исходного проекта. («Я могу сказать, что эта библиотека (MFC) была спроек-тирована без заботы об удобстве сопровождения людьми, не подозревающими о существо-вании даже элементарных принципов объектно-ориентированного проектирования», — Ален Голуб [6].) Тем не менее, существующие библиотеки реализуют очень много графических возможностей и содержат большое количество всевозможных элементов управления, но на-писание простого приложения с пользовательским интерфейсом становиться нетривиальной задачей. А появления разнообразных контролов — это вопрос времени и расширения. Рассмотренные библиотеки предоставляют схожие возможности, однако каждая имеет свои недостатки. Результаты сравнения приведены в Табл. 1. Табл. 1. Обзор существующих методов решения. MFC .NET Win-Forms Qt bildigo (реализуемая библиотека) Читаемость описания окна – – – + Отсутствие расширений языка – – – + Отсутствие макроподстановок – + – + Гибкая архитектура приложения – + + + Полная инкапсуляция WinAPI – + + + Богатый выбор разнообразных элементов управления + + +/– – Механизм исключений +/– + + + IDE для разработки форм + + + – Геометрические фигуры как объ-екты – – – + Сравнение исходного кода приложения построенного на WinForms .NET и bildigo вы найдете в Приложении. 1.5. Вывод Существующие библиотеки не удовлетворяют описанным требованиям, поэтому при-нято решение о разработке собственной библиотеки. 1.6. План работ Учитывая особенности разрабатываемой библиотеки, установлены виды работ и при-мерные сроки их выполнения, приведённые в Табл. 2 Табл. 2. План работ Вид работы Сроки Проведение анализа и формулировка требований 2 недели Поиск методов решения, разработка архитектуры 3 недели Кодирование 5 недель Тестирование библиотеки + демон-страционное приложение 1 неделя Написание документации 2 недели Подготовка к защите работы 1 неделя 2. Требования к окружению 2.1. Требования к аппаратному обеспечению

Литература

Список литературы [1] MSDN Library for Visual Studio .NET 2003 [2] Рихтер Дж. Windows для профессионалов: создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows/Пер. с англ. — СПб: Питер, 2004 [3] Арчер Т., Уйатчепел Э. Visual C++ .NET. Библия пользователя/Пер. с англ. — М.: Издательский дом «Вильямс», 2003 [4] Старуструп Б. Язык программирования С++. Специальное издание/Пер. с англ. — М.: ООО «Бином-Пресс», 2004 [5] Верма Р.Д. Справочник по функциям Win32 API. — М.: Горячая линия – Теле-ком, 2005 [6] Голуб А. Веревка достаточной длины, чтобы... выстрелить себе в ногу. Правила программирования на Си и Си++/Пер. с англ. — М., 2001
Уточнение информации

+7 913 789-74-90
info@zauchka.ru
группа вконтакте