Панель инструментов содержит следующие компоненты:
а) функции установки режима отображения эмиттеров:
1) Playback;
2) Loop playback;
2) Static;
б) функции сохранения и загрузки:
1) Save;
2) Load;
в) функции настройки отображения:
1) Back color;
2) Back image;
3) режим смешивания;
Панель статуса имеет два поля: количество отображённых за секунду кадров, число частиц, число примитивов, быстрая подсказка (по ситуации).
Получить информацию о внутренней структуре приложения можно, обратившись к диаграмме классов (Приложение Г).
2.3 Функциональная модель приложения
Разработанный редактор имеет шесть базовых функциональных блоков: настройка очереди эмиттеров, обновление, отображение, ввод/вывод, настройка отображения и работа со справочной системой приложения (в базовой версии сводится к получению общей информации о функциональности редактора и разработчике, впоследствии планируется расширение).
Настройка очереди эмиттеров, в свою очередь, состоит из на набора функций по управлению очередью (добавление эмиттеров, удаление эмиттеров, копирование эмиттеров с переносом их параметров) и набора функций по установке параметров текущего эмиттера и его частиц.
Функция отображения реализует вывод на экран создаваемых эффектов.
Функции ввода и вывода позволяют пользователю сохранять текущий проект, а именно - данные о эмиттерах и о дополнительных параметрах отображения, на внешний носитель, и загружать проекты, которые были сохранены ранее.
Функции настройки отображения состоят в установке дополнительных параметров отображения (перечисленных в предыдущем подразделе).
Получить более детальную информацию о множестве и структуре интерфейсных функций приложения можно, обратившись к диаграмме вариантов использования (Приложение Д). На ней отображена декомпозиция крупнейших интерфейсных блоков. Диаграмма позволяет в наглядной форме представить набор действий, осуществляемых пользователем, которыми определяется работа редактора.
2.4 Информационная модель приложения
Информационная модель приложения отражает потоки информации, проходящие между его модулями и внешними сущностями.
Разрабатываемый редактор частиц является однопользовательским приложением, так как поддерживает интерфейс одновременно лишь с одним пользователем. Таким образом, первой внешней сущностью является пользователь.
Данные о частицах, обработанные редактором, выводятся на внешний носитель в виде текстовых файлов формата XML. Позже эти файлы могут быть использованы как редактором, так и поставляемым совместно с ним инструментарием в контексте целевого приложения. Таким образом, второй внешней сущностью является носитель данных.
За непосредственный приём данных эмиттеров от пользователя отвечает инструментарий фрейма ввода. Библиотеки операционной системы предоставляют для этого всё необходимое, а использование предкомпиляторных “фильтров” wxWidgets позволяет и вовсе забыть о платформе.
После ввода данные направляются в первую основную сущность приложения - очередь эмиттеров. Там они хранятся, используясь при выводе (некоторые поля модифицируются при этом).
В свою очередь, ввод управляющих сигналов осуществляется через аналогичные инструменты панели инструментов. Эти данные помещаются в служебные поля очереди эмиттеров, а также фрейма вывода.
Обмен данными с внешними носителями осуществляется по соответствующим управляющим командам. При сохранении осуществляется съём данных очереди эмиттеров, параметров отображения, хранящихся в фрейме вывода, прочей служебной информации, характеризующей состояние приложения, которые форматируются установленным образом (используется инструмент TinyXML) и выводятся. При загрузке происходит прямо противоположная последовательность действий.
Обобщая вышесказанное, к основным потокам данных приложения можно отнести:
а) ввод пользователем в систему параметров эмиттеров:
1) координаты в двумерной декартовой системе;
2) скорость;
3) размеры эмиттера;
4) значения разброса частиц;
5) стартовая задержка и длительность генерации;
б) ввод пользователем в систему параметров частиц эмиттера:
1) текстура;
2) время жизни;
3) скорость по осям;
4) гравитация по осям;
5) значения начальных и конечных растяжений;
6) значения начального и конечного цветов (32bit), по каналам;
в) вывод графической информации системы эмиттеров в буфер изображения;
Графически информационная модель приложения представлена в Приложении В, на диаграмме потоков данных.
2.5 Объектная модель приложения
Так как приложение было разработано с использованием возможностей объектно-ориентированного языка С++, следует раскрыть его объектную структуру. Подробно объектная структура программного средства описана в Приложении Г, здесь же можно привести общий обзор системы классов.
а) класс MyApp, отвечает за инициализацию приложения, создаётся и управляется полностью из среды wxWidgets. Это корневой класс всей проектируемой части приложения.
б) модуль очереди эмиттеров. Включает в себя:
1) класс ParticleSystemChain, то есть непосредственно саму очередь; в системе существует singleton-объект данного класса;
2) содержащиеся в очереди эмиттеры - объекты класса ParticleSystem;
3) для формирования и использования корректных OpenGL текстур на основании битовых изображений используются объекты класса MyTexture.
в) класс MainFrame - корневой класс оконного пользовательского интерфейса; в системе существует singleton-объект данного класса;
г) класс PSChainFrame представляет собой окно управления очередью систем;
д) объекты PSLabel применяются в PSChainFrame для представления эмиттеров, представляют собой пиктограммы;
е) PSInputFrame используется для ввода пользовательских данных активной системы;
ж) объекты классов MySpinCtrld и MySpinEditCtrld - пользовательские элементы управления, используемые для ввода чисел с плавающей точкой из указанного диапазона, применяются в PSInputFrame;
з) PSOutputFrame используется для отображения результатов работы приложения (вывода вычисленных графических примитивов - частиц); объект MyCanvas - предоставляется OpenGL в качестве контекста визуализации;
Это общий перечень разработанных в рамках программного средства классов с кратким описанием их функциональности. Взаимосвязи между ними и другими, менее значительными, классами, а также внутренняя структура классов в более полном виде раскрывается в Приложении Г.
2.6 Требования к программным, аппаратным ресурсам и ОС
Для сборки приложения необходимо наличие набора встраиваемых (статических) библиотек среды wxWidgets, установленных в системный каталог (или в один из каталогов поиска статических библиотек, указанных в настройках среды разработки Microsoft Visual Studio 2005 и в свойствах проекта). Для корректной работы приложения необходимо наличие в системе динамической библиотеки OpenGL (любой версии, по умолчанию с OS Windows поставляется версия 1.0). Драйвер OpenGL используется для растеризации графических данных, генерируемых редактором.
Приложение требует не более 30 MB оперативной памяти, 20 MB - виртуальной, 40 MB дискового пространства.
Минимальное разрешения дисплея монитора, требуемое для корректной работы приложения, составляет 1024x768 точек.
Приложение работает под управлением любой OС Windows (версии не ниже Windows XP SP2).
Кроме того, для корректной работы приложения, собранного в Microsoft Visual Studio 2005, необходимо наличие в системе установленных специальным образом библиотек (так называемых манифестов), иначе приложение не запустится. В качестве альтернативы можно собрать приложение с использованием Microsoft Visual Studio 2003, однако при этом будет использован графический пользовательский интерфейс старого образца.
3. Тестирование
3.1 Анализ надежности
Испытания проводятся с целью выявления отклонений в работе программы и результатах её функционирования, оценки причин таких отклонений. Отклонения полученных результатов от эталонов используются для оценки качества программы.
Основным методом обнаружения ошибок при проведении испытаний программы являлось тестирование, в котором целесообразно выделить три стадии:
- тестирование для обнаружения ошибок в программе, где выявлялись все отклонения результатов функционирования реальной программы от заданных эталонных значений;
- тестирование для диагностики обнаруженных искажений результатов, с целью обнаружения инструкций и данных, явившихся причиной отклонения результатов от эталонных при тестировании для обнаружения ошибок;
- тестирование для контроля выполненных корректировок программы и данных, где подтверждалась правильность выполненной корректировки.
Говоря о тестировании, понимается проверка программы не только в статическом режиме, когда обнаруживаются ошибки кода программы, но и динамическая проверка, включающая контроль адекватности реакции системы на заявки пользователя и поведения системы при возникновении недопустимых ситуаций.
Найденные ошибки устранялись, процесс продолжался до тех пор, пока работа приложения не была признана удовлетворительной.
3.2 Тестовые примеры
При тестировании был проведен ряд тестов различной направленности:
- тест корректности вводимых пользовательских данных, в рамках которого была проверена система ввода всех видов данных, используемых приложением, с попытками ввода некорректных данных;
- тест работоспособности с граничными значениями параметров; любое приложение необходимо проверять на работоспособность в граничных состояниях, так как, в силу своей неочевидности и низкой вероятности возникновения, это, как правило, наиболее узкие места в функциональности;
- тест корректности работы приложения на ПК с различными конфигурациями (драйверами графического ускорителя); приложения, использующие низкоуровневую функциональность драйвера (или близкую к ней), необходимо дополнительно тестировать на совместимость с различными разновидностями драйверов данного типа. В случае с разрабатываем приложением, необходимо выполнить проверку на корректность его работы с различными драйверами видеосистемы, так как приложение использует низкоуровневые возможности OpenGL в качестве своей осевой функциональности.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
