|
Аннотация
Цель данной курсовой работы — разработка библиотеки классов С++ предназначенных для создания оконных приложений под ОС 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. Требования к аппаратному обеспечению
|
На уровень вверх
Купить