перейти к полному списку дипломных проектов

Ссылка на скачивания файла в формате .doc находится в конце странички

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

а) класс 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 в качестве своей осевой функциональности.

3.3 Реакция программы на тесты

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

После успешной компиляции и сборки приложения, непосредственно в процессе тестирования, были обнаружены и устранены ошибки времени исполнения. Из наиболее трудно-устранимых можно отметить ошибку приведения данных типов с плавающей запятой при пользовательском вводе (что приводило к их неявному искажению), а также ошибки проектирования пользовательского интерфейса, в связи с чем последний был целиком переработан несколько раз. При тестировании приложения с графическим ускорителем от фирмы ATI были выявлены ошибки инициализации текстурных данных, из-за чего нарушался их вывод.

скачать бесплатно Требования к разрабатываемому программному средству

Содержание дипломной работы

При этом, параметры не должны вступать в противоречие друг с другом (например, дублирование существенной части функциональности одного параметра – другим)
Однако при этом должна быть реализована возможность подключения и использования выходных данных редактора (созданных эффектов) к внешним графическим приложениям
Достаточно широко применяются шаблоны контейнеров из стандартной библиотеки шаблонов (STL), входящей в библиотеку C++
Далее нужно просто перетаскивать мышью необходимые графические объекты на рисунок, вставлять в них нужный текст, соединять объекты
Использование V-образной модели не имело смысла, так как она применяется при разработке программного продукта командой разработчиков, и особо ориентирована на верификацию и аттестацию продукта
Заказчик оценил первичный прототип и совместно с программистом определил проблемы, над устранением которых необходимо было работать в рамках разработки последующего прототипа системы
Фрейм вывода объединяет в себе всю функциональность вывода графических данных приложения
В свою очередь, ввод управляющих сигналов осуществляется через аналогичные инструменты панели инструментов
В противном случае происходит сильное усложнение процесса их локализации в финальной версии модуля, так как они начинают влиять друг на друга
При запросе справочной информации системы помощи или информации о разработчике осуществляется активация диалоговых окон с соответствующими запросу данными
В этом случае должна быть либо увеличена длительность перерыва для отдыха, либо произведена смена деятельности
Нормами для данных работ установлена необходимая освещенность рабочего места Ен=300лк (средняя точность работы по различению деталей размером от 1 до 10 мм)
Распределение работ в течение смены должно учитывать, что период вырабатывания у операторов ПК составляет от 10 до 40 минут (в послеобеденное время период вырабатывания сокращается)
Выбор эффективных проектов ПС связан с их экономической оценкой и расчетом экономического эффекта, который может определяться как у разработчика, так и у пользователя
4 Расчет основной заработной платы Нормативная трудоемкость служит базой для расчета основной заработной платы
10 Расчет прочих прямых затрат Расходы на конкретное ПС включают затраты на приобретение и подготовку специальной научно-технической информации и специальной литературы
15 Определение отпускной цены на ПС ВТ Отпускная цена определяется на основании цены разработчика, которая формируется на основе показателя рентабельности продукции
При сравнении базового и нового вариантов ПС в качестве экономического эффекта будет выступать общая экономия всех видов ресурсов относительно базового варианта
Для пользователя в качестве экономического эффекта выступает лишь чистая прибыль – дополнительная прибыль, остающаяся в его распоряжении (?Пч), которая определяются по формуле:
, (6
Прирост прибыли за счёт экономии начислений на заработную плату, оплаты машинного времени и материалов в каждый из расчётных лет составил соответственно 2333533 руб
Возможно, будет введены параметры дисперсии гравитации, или иные параметры, задающие изменение значений гравитации
– Мн
x, appear_box_position
x) (point
begin(); bool chain_is_run = false; while(iter != all_ps
begin(), tmp_ps_ptr); tmp_ps_ptr = new ParticleSystem(); } delete tmp_ps_ptr; if(tmp_all_ps
pGreenBegin = 1
startDelay; } void ParticleSystem::setStopDelay(double time) { data
pGreenBegin = green; } void ParticleSystem::setBlueBegin(double blue) { data
pCountOnStart = sys_from->data
pBlueBegin; data
initialY; } void ParticleSystem::restart() { startInTime = data
0, boundedRectColor
0; } x -= w/2
SetAttribute(MAX_COUNT_ATTR, data
SetDoubleAttribute(SCALE_END_W_ATTR, data
pGravityX) != TIXML_SUCCESS || next_element_ptr->QueryDoubleAttribute(GRAVITY_Y_ATTR, data
0; //change DX DY currentX += data