Автоматизированная система генерации приложений, использующих библиотеку OpenGL

Вид работы:

Дипломная (ВКР)
Предмет:

Информационное обеспечение, программирование
Язык:

Русский
,
Формат файла:
MS Word

286,15 Кб
Опубликовано:

2014-03-04

Все дипломные работы по информационному обеспечению

Скачать дипломную работу Читать текст online Заказать дипломную
*Помощь в написании! Посмотреть все дипломные работы

Вы можете узнать стоимость помощи в написании студенческой работы.

Автоматизированная система генерации приложений, использующих библиотеку OpenGL

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

. ПРЕДПРОЕКТНЫЕ ИССЛЕДОВАНИЯ

.1 Описание предметной области задачи автоматизации

.2 Анализ прототипов системы

.3 Обоснование выбора технической платформы разрабатываемой системы

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

.5 Задачи выпускной работы

. АНАЛИЗ ЗАДАЧИ

.1 Анализ автоматизированной системы

.1.1 Анализ первого уровня детализации задачи

.1.2 Анализ второго уровня детализации задачи

.1.3 Анализ третьего уровня детализации задачи

.2 Анализ шаблона графического приложения

.2.1 Анализ первого уровня детализации задачи

.1.2 Анализ второго уровня детализации задачи

. РАЗРАБОТКА АЛГОРИТМОВ РЕШЕНИЯ ЗАДАЧИ

.1 Автоматизированная система генерации приложений

.1.1 Алгоритм решения задачи “Ввод данных”

.1.2 Алгоритм решения задачи “Конвертация файла”

.1.3 Алгоритм решения задачи “Генерация шаблона”

.2 Шаблон графического приложения

.2.1 Алгоритм решения задачи “Инициализация OpenGL”

.2.2 Алгоритм решения задачи “Загрузка 3D файла”

.2.3 Алгоритм решения задачи “Вывод 3D файла на экран”

. СИНТЕЗ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

.1 Архитектура программного обеспечения

.2 Информационное пространство системы

.3 Интерфейс пользователя

. ТЕСТИРОВАНИЕ СИСТЕМЫ

. ОЦЕНКА ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ПРИМЕНЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ОПРЕДЕЛЕНИЕ ЕГО ЦЕНЫ

.1 Порядок расчета и анализа экономической эффективности

.2 Расчет экономической эффективности применения программного обеспечения и определение его цены

. ОХРАНА ТРУДА

.1 Характеристика рабочего места

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

.3 Разработка мероприятий по предотвращению или ослаблению возможного воздействия опасных и вредных эксплуатационных факторов на работающих

.4 Обеспечение экологической безопасности функционирования проектируемого объекта

Список использованной литературы

ВВЕДЕНИЕ

Сейчас трёхмерные изображения можно увидеть везде, начиная от компьютерных игр и заканчивая системами моделирования в реальном времени. Раньше, когда трёхмерная графика существовала только на суперкомпьютерах, не существовало единого стандарта в области графики. Все программы писались с "нуля" или с использованием накопленного опыта, но в каждой программе реализовывались свои методы для отображения графической информации. С приходом мощных процессоров и графических ускорителей трёхмерная графика стала реальностью для персональных компьютеров. Но в тоже время производители программного обеспечения столкнулись с серьёзной проблемой - это отсутствие каких-либо стандартов, которые позволяли писать программы, независимые от оборудования и операционной системы. Одним из первых таких стандартов, существующий и по сей день, является OpenGL [1].- это графический стандарт в области компьютерной графики. На данный момент он является одним из самых популярных графических стандартов во всём мире. Ещё в 1982 г. в Стенфордском университете была разработана концепция графической машины, на основе которой фирма Silicon Graphics в своей рабочей станции Silicon IRIS реализовала конвейер рендеринга. На основе библиотеки IRIS GL, в 1992 году был разработан и утверждён графический стандарт OpenGL. Создатели OpenGL - это крупнейшие фирмы выпускающие как оборудование, так и программное обеспечение: Silicon Graphics, Inc., Microsoft, IBM Corporation, Sun Microsystems, Inc., Digital Equipment Corporation (DEC), Evans & Sutherland, Hewlett-Packard Corporation, Intel Corporation и Intergraph Corporation.

Каждый, кто хоть раз использовал возможности библиотеки OpenGL, мог увидеть, что создание объектов, а именно, указание их геометрических параметров (координат) является сложной задачей. Как вы можете догадаться, это явление имеет место вследствие отсутствия наглядности - указывать геометрию моделей приходится интуитивно, либо по заранее рассчитанным зависимостям.

Как же решить эту проблему? Первое, что приходит в голову - для создания модели использовать сторонние приложения. Именно так сейчас и поступают в современных проектах, например играх. Как минимум, такое приложение должно иметь графический интерфейс и уметь сохранять результат в удобном для чтения формате. Это могут быть любые пакеты для создания и редактирования трехмерной компьютерной графики, CAD системы.

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

) преобразование подающихся на вход графических файлов 3D моделей в универсальный файл (файл с описанием модели, в формате, удобном для использования в приложениях ориентированных на применение библиотеки OpenGL);

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

Полученный шаблон можно будет использовать как фундамент для разнообразных графических приложений.

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

Данная выпускная работа состоит из трех частей:

) основная часть;

) экономическая часть;

) вопросы безопасности жизнедеятельности.

В основной части выпускной работы содержатся такие разделы:

) предпроектные исследования;

) анализ задачи;

) разработка алгоритмов решения задачи;

) синтез программного обеспечения;

) тестирование системы.

В разделе «Предпроектные исследования» формируются задачи выпускной работы. Описывается суть самой задачи, предполагаемой к автоматизации. Обосновывается выбор инструментальных средств, которые будут использованы для разработки программного приложения. Обосновывается выбор технического обеспечения, необходимого для развертывания создаваемой системы. А также описываются прототипы систем.

В разделе «Анализ задачи» формулируется задача системы в наиболее общем виде и осуществляется ее последовательная детализация. Описывается состав уровней детализации, набор предполагаемых операндов и результатов для каждой составляющей уровня. Производится проверка корректности назначения составляющих для каждого уровня.

В разделе «Разработка алгоритмов решения задачи» приводятся алгоритмы реализации набора подзадач, выявленных в ходе анализа. Для описания алгоритмов используется любой удобный способ: формульный, с помощью блок схем, лингвистический. Уточняется набор операндов и результатов для разработанной системы алгоритмов.

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

В разделе «Тестирование» описываются примеры, подтверждающие работоспособность созданного программного обеспечения.

В экономической части выпускной работы, содержание и структура раздела уточняется консультантом работы по экономической части.

В разделе охраны труда, содержание и структура раздела уточняется консультантом работы по вопросам обеспечения жизнедеятельности.

1. Предпроектные исследования

.1 Описание предметной области задачи автоматизации

Компьютерная графика нашла широкое распространение и применение в повседневной жизни. Учёные используют компьютерную графику для анализа результатов моделирования. Инженеры и архитекторы используют трёхмерную графику для создания виртуальных моделей. Кинематографисты создают спецэффекты или полностью анимированные фильмы («Шрек», «История игрушек» и др.). В последние годы широкое распространение получили также компьютерные игры, максимально использующие трёхмерную графику для создания виртуальных миров.

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

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

Поэтому было принято решение стандартизировать метод доступа к графической аппаратуре на уровне программного интерфейса.

Таким образом, появился программный интерфейс OpenGL, который стандартизирует доступ к графической аппаратуре путём смещения ответственности за создание аппаратного драйвера на производителя графического устройства. Это позволило разработчикам программного обеспечения использовать более высокий уровень абстракции от графического оборудования, что значительно ускорило создание новых программных продуктов и снизило на них затраты.переводится как «Открытая Графическая Библиотека» (Open Graphics Library), это означает, что OpenGL - это открытый и мобильный стандарт. Программы, написанные с помощью OpenGL можно переносить практически на любые платформы, получая при этом одинаковый результат, будь это графическая станция или суперкомпьютер. OpenGL освобождает программиста от написания программ для конкретного оборудования. Если устройство поддерживает какую-то функцию, то эта функция выполняется аппаратно, если нет, то библиотека выполняет её программно.

Что же представляет из себя OpenGL? С точки зрения программиста OpenGL - это программный интерфейс для графических устройств, таких как графические ускорители. Он включает в себя около 150 различных команд, с помощью которых программист может определять различные объекты и производить рендеринг. Говоря более простым языком, вы определяете объекты, задаёте их местоположение в трёхмерном пространстве, определяете другие параметры (поворот, масштаб, ...), задаёте свойства объектов (цвет, текстура, материал, ...), положение наблюдателя, а библиотека OpenGL позаботится о том, чтобы отобразить всё это на экране. Поэтому можно сказать, что библиотека OpenGL является только воспроизводящей (Rendering), и занимается только отображением 3D объектов.

На данный момент OpenGL - одна из наиболее популярных графических библиотек, предоставляющих возможность реализовывать сложные задачи с 3D объектами у себя в программе. Ее главным конкурентом является DirectX [2] - коммерческий проект, изначально нацеленный на разработку видеоигр. Благодаря правильной рекламной компании от Microsoft и тому, что платформа Windows на данный момент является самой распространенной, DirectX завоевал большую популярность. Новые версии этой библиотеки используют самые передовые достижения в графической индустрии. Множество производителей видеокарт аппаратно поддерживают ее спецификацию. Но, не смотря на все эти преимущества, OpenGL имеет один главный плюс - открытость и кроссплатформенность. Благодаря этому OpenGL независим от языка программирования и используется на многих платформах, а также во многих тяжелых приложениях, таких как САПР системы. Разработка OpenGL не прекращается и на данный момент ее последняя версия (4.2) ничем не уступает по возможностям DirectX 11.

К преимуществам OpenGL можно отнести:

) производительность - с самого начала в OpenGL была заложена "крайне желательная" возможность отрисовки динамических сцен;

) ортогональность - по возможности все функции OpenGL являются ортогональными, то есть независимыми;

) полнота - насколько это представляется возможным, OpenGL соответствует набору функций, предоставляемому современными аппаратными средствами графической акселерации;

) интероперабельность - в сетевом окружении важно передавать данные между разными платформами;

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

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

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

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

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

Такие модели рационально хранить в отдельных файлах и по мере необходимости загружать их в память. Как уже было сказано, модель состоит из множества параметров - вершин, граней, цветов и т.д., а значит, данный файл будет иметь сложную структуру. Очевидно, что заполнить этот файл вручную будет очень сложно и неоправданно долго, а в случае, когда модель представляет собой сложный объект почти невозможно.

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

Обычно файлы, созданные графическими редакторами и содержащие модели объектов, имеют схожую структуру. Конечно, каждый редактор дополняет исходный файл своими, присущими только ему, параметрами, например настройки оболочки, функционала и др., но часть, касающаяся модели, почти не отличается.

Основными данными, описывающими 3D модель, являются:

) список вершин;

) список граней (треугольники, четырехугольники);

) список нормалей;

) материалы граней;

) текстурные координаты;

) другие специфические каждому редактору блоки.

1.2 Анализ прототипов системы

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

Основной задачей проекта является автоматизация генерации приложений, использующих библиотеку OpenGL. Автоматизация включает разработку приложения выполняющего преобразование полученного на вход файла, описывающего модель или любой набор объектов, в универсальный файл с описанием модели, но в формате удобном для его использования в OpenGL. Также по требованию пользователя будет генерироваться шаблон, представляющий собой базовый набор кода для создания какого-либо графического приложения. К этому шаблону будет поставляться библиотека необходимая для предоставления возможностей по простой манипуляции с полученным универсальным файлом (загрузка, чтение внутренних данных и т.п.).

Очевидно, что чем больше форматов графических файлов будет понимать приложение, тем гибче оно будет. Но, учитывая ограниченное время на разработку программного продукта, сделать поддержку большого количества форматов не представляется возможным. Также трудности вызовет и то, что некоторые форматы являются закрытыми, а другие имеют перегруженную структуру. Поэтому логично выбрать за основу несколько открытых форматов, ставших де-факто форматами обмена графической информацией.

Самыми широко используемыми можно назвать 3DS [3] и OBJ [4] форматы. Эти форматы поддерживаются всеми популярными графическими редакторами, такими как 3DS Max, Maya, Blender и т.д., а также разнообразными CAD системами.

К плюсам 3DS формата можно отнести:

) поддерживается почти всеми редакторами трехмерной графики;

) наиболее встречаемый формат, имеется множество готовых моделей в сети интернет;

) является бинарным форматом, благодаря чему занимает меньше места на диске;

) спецификация формата достаточна для описания любой модели, включая необязательные дополнительные параметры (камеры, свет, материал, текстурные карты и т.д.).

Минусами 3DS формата являются:

) все поверхности полигональной сетки должны быть треугольниками;

) имена текстур ограничены форматом записи DOS 8.3;

) число вершин и полигонов в полигональной сетке ограничено 65536;

) нормали вершин не могут быть сохранены в файле этого формата;

) не поддерживаются направленные источники света.

К плюсам OBJ формата можно отнести:

) является общепринятым форматом, поддерживается большим количеством редакторов графики (не только трехмерной);

) имеет текстовый формат, благодаря чему легко читается и имеет возможность ручного редактирования;

) хорошо описывает геометрию модели любой сложности.

Минусами OBJ формата являются:

) представляет собой описание лишь геометрии модели;

) не поддерживает иерархию в полигональной сетке.

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

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

С 3DS форматом все предстоит иначе. Учитывая его сложную структуру и то, что он является бинарным форматом, были разработаны неплохие отрытые библиотеки. Одним из примеров такой библиотеки является Lib3DS.DS [5] представляет собой бесплатную открытую кроссплатформенную библиотеку позволяющую легко управлять файлами 3DS формата. К основным возможностям данной библиотеки можно отнести:

) работа в двух режимах процессора - big-endian и little-endian;

) загрузка и сохранение:

a) настроек атмосферы, фона, теней, окна просмотра;

b) материалов;) камер и света;) полигональной сетки;) иерархии;) ключевых кадров;

) модули для работы с векторами и матрицами;

) оценка ключевых кадров анимации.

Проект данной библиотеки был основан энтузиастами, и его поддержка не ведется с 2007 года. Основной функцией Lib3DS является загрузка 3DS файла во внутренние структуры и простая манипуляцию ими в программе. Но эта библиотека кроме геометрии еще грузит множество различных параметров, как-то свет, камера или анимация, что занимает существенный объем памяти и усложняет программу. Поэтому использование Lib3DS в данном программном продукте не оправданно.

Как известно, 3DS формат был разработан как формат-контейнер для сохранения модели и настроек среды, а значит, он не совсем подходит для прямого использования в программном коде. Именно по этой причине в данном программном продукте и разработан свой универсальный файл с описанием геометрии модели, специально оптимизированный для использования с библиотекой OpenGL.

Еще в 90-х годах создатель редактора трехмерной графики 3DS Max компания Autodesk, которая собственно и разработала 3DS формат, написала свою открытую библиотеку 3DSFTK [6], предоставляющую программистам возможность по управлению 3DS файлами. Но как случается с подобными утилитами, после написания этой библиотеки ее поддержка прекратилась. Поэтому она не совсем стабильная и имеется очень мало документации по ее использованию, особенно на русском языке.

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

1.3 Обоснование выбора технической платформы разрабатываемой системы

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

Минимальные требования, предъявляемые к комплексу технических средств:

) процессор - 233 MHz;

) оперативная память - 64 Mb RAM;

) объем дисковой памяти - 1,5 GB свободного дискового пространства;

) видеоадаптер и монитор - Super VGA 800x600;

Рекомендуемые требования к комплексу технических средств:

) процессор - 300 MHz и выше;

) оперативная память - 128 Mb RAM;

) объем дисковой памяти - 1,5 GB свободного дискового пространства и выше;

) видеоадаптер и монитор - Super VGA 800x600 и выше;

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

В качестве языка программирования для реализации данной работы был выбран язык С++. Этот выбор обусловлен следующими особенностями языка:

) возможность генерации высокоэффективного программного кода;

) поддерживаются различные стили и технологии программирования, включая традиционное директивное программирование, ООП, обобщённое программирование, метапрограммирование (шаблоны, макросы);

) автоматический вызов деструкторов объектов при их уничтожении, причём в порядке, обратном вызову конструкторов. Это упрощает (достаточно объявить переменную) и делает более надёжным освобождение ресурсов (память, файлы, семафоры и т. п.), а также позволяет гарантированно выполнять переходы состояний программы, не обязательно связанные с освобождением ресурсов ;

) пользовательские функции-операторы позволяют кратко и ёмко записывать выражения над пользовательскими типами в естественной алгебраической форме;

) имеется возможность работы на низком уровне с памятью, адресами;

) эффективность. Язык спроектирован так, чтобы дать программисту максимальный контроль над всеми аспектами структуры и порядка исполнения программы. Ни одна из языковых возможностей, приводящая к дополнительным накладным расходам, не является обязательной для использования - при необходимости язык позволяет обеспечить максимальную эффективность программы.

Разрабатываемое программное обеспечение должно работать под управлением ОС Windows. Из существующих инструментальных сред разработки ПО с использованием языка C++ для ОС Windows была выбрана среда Microsoft Visual Studio 2005. Visual Studio 2005 представляет собой полный набор средств, помогающих ускорить процесс реализации замысла разработчика. К преимуществам Microsoft Visual Studio 2005 относятся:

) удобное, продуманное рабочее место программиста;

) наличие обширных справочных материалов для разработчика (MSDN);

) гибкость программных средств, легкая достижимость требуемого результата;

) среда, имеющая наибольшее распространение среди профессиональных разработчиков Windows-приложений;

) возможность создания проектов любой сложности и объема;

) огромное количество отдельных классов, компонентов, библиотек, написанных за последние 10-15 лет (повторная применимость кода);

) удобные отладочные средства;

) мощный оптимизирующий компилятор;

) генерация каркаса приложения в зависимости от его предназначения и особенностей интерфейса.

1.5 Задачи выпускной работы

Суть проблемы, которую необходимо решить в данной выпускной работе, состоит в следующем. В приложениях, использующих библиотеку OpenGL, необходимо задавать геометрические параметры (координаты) изображаемых объектов, что представляет определенную трудность вследствие отсутствия наглядности. Поэтому имеет смысл автоматизировать этот процесс, а именно ввод геометрии объектов. Объект строится в каком-либо приложении, поддерживающем графический интерфейс. Затем геометрические данные объекта записываются в файл или экспортируются каким-либо иным способом. Далее с помощью разработанного приложения на основе полученного файла генерируется универсальный файл, содержащий данные об объекте в формате, удобном для его использования в приложении, ориентированном на применение библиотеки OpenGL. Затем пользователю предоставляется возможность сгенерировать шаблон, позволяющий с помощью идущей с ним библиотеки, загрузить и вывести на экран модель из универсального файла.

Для достижения поставленных целей необходимо решить следующие задачи:

) рассмотреть структуру 3DS формата, выявить основные ее части;

) рассмотреть структуру Obj формата, выявить основные ее части;

) спроектировать свой универсальный формат хранения геометрии модели, необходимый для удобного и простого подключения к приложению;

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

) разработать динамическую библиотеку (lib3do) выполняющую загрузку спроектированного универсального формата (далее 3DO) и предоставляющую простой интерфейс по манипуляции с ним:

a) выполнить анализ задачи с целью выявления подзадач, которые должны быть решены;

b) разработать алгоритмы решения выявленных подзадач;) разработать архитектуру библиотеки и определить характер взаимосвязи программных единиц;) выполнить кодирование, а также его отладку и тестирование библиотеки для подтверждения работоспособности созданного программного обеспечения.

) разработать программный продукт выполняющий трансляцию входного файла (3DS или Obj) в свой спроектированный формат (3DO) и генерацию шаблона графического приложения:

a) выполнить анализ задачи с целью выявления подзадач, которые должны быть решены;

b) разработать алгоритмы решения выявленных подзадач;) разработать архитектуру программного обеспечения и определить характер взаимосвязи программных единиц;) выполнить кодирование приложения, а также его отладку и тестирование для подтверждения работоспособности созданного программного обеспечения.

2. Анализ задачи

В данном разделе производится детализация и анализ таких задач:

) автоматизированная система генерации приложений, использующих библиотеку OpenGL;

) шаблон графического приложения.

2.1 Анализ автоматизированной системы

.1.1 Анализ первого уровня детализации задачи

На первом уровне детализации программное приложение можно представить в виде трех основных блоков, представленных на рисунке 2.1.

Рисунок 2.1 - первый уровень детализации

Основными входными данными являются графические файлы, с описанием моделей в форматах поддерживаемых приложением - 3DS и Obj форматы. В последующих версиях планируется увеличение поддерживаемых форматов.

К выходным данным относится полученный после конвертации входного файла (3DS или Obj) универсальный файл 3DO, и шаблон графического приложения, позволяющий отобразить этот файл на экране.

Универсальный 3DO файл основан на xml [7] формате и имеет следующую структуру:

<3DO version=”1.0”>

-03-19T18:31:50

</created>

2012-03-19T18:31:50

</modified>

<source_array id="Name-mesh-positions-array" count="9">

.4375 -0.1640625 0.765625 -0.4375 0.1640625 0.765625

.5 0.09375 0.6875

</source_array>

<technique_common>

</accessor>

</technique_common>

</source>

<source_array id="Name-mesh-normals-vertices-array" count="9">

0.6649926 -0.2007524 0.719363 -0.6649926 -0.2007524 0.719363

.8294267 -0.303581 0.4689242

</source_array>

<technique_common>

</accessor>

</technique_common>

</source>

<source_array id="Name-mesh-normals-faces-array" count="9">

0.6649926 -0.2007524 0.719363 -0.6649926 -0.2007524 0.719363

.8294267 -0.303581 0.4689242

</source_array>

<technique_common>

</accessor>

</technique_common>

</source>

</vertices>

</vcount>

<p>

2 3

</p>

</polylist>

</geometry>

</geometries>

</3DO>

2.1.2 Анализ второго уровня детализации задачи

Структура рассматриваемой задачи на втором уровне детализации представлена на рисунке 2.2.

Рисунок 2.2 - второй уровень детализации

2.1.2.1 Ввод данных

Назначение задачи “Ввод данных” состоит в указании пути к файлу с описанием модели (3DS или Obj), который далее будет преобразован в универсальный 3DO файл.

Также если пользователь захочет сгенерировать шаблон графического приложения, то необходимо указать имя этого приложения и путь по которому оно будет сохранено. Еще необходимо указать путь к файлу 3DO для его загрузки и вывода в коде шаблона.

2.1.2.2 Конвертация файла

Назначение задачи “Конвертация файла” состоит в преобразовании указанного файла с описанием модели (3DS или Obj) в универсальный формат файла 3DO. При конвертации исходный файл будет дополнен по возможности дополнительной информацией облегчающей использование 3DO файла в приложении. Это может быть расчет нормалей к граням для 3DS файла или расчет нормалей во всех вершинах для 3DS и Obj. Такие дополнительные расчеты призваны сократить время обработки 3DO файла при его загрузке, т.к. отпадет необходимость в повторном их выполнении.

Входными данными задачи являются:

) путь к конвертируемому файлу (3DS или Obj);

) путь и имя получаемого файла (3DO).

Структура исходного 3DO файла была описана выше.

К выходным данным относится полученный универсальный 3DO файл.

.1.2.3 Генерация шаблона

Назначение задачи “Генерация шаблона” состоит в получении каркаса приложения используемого в дальнейшем для разработки несложных графических программ.

При выборе шаблона с подключенной библиотекой будет сгенерировано приложение позволяющее загрузить и вывести на экран сконвертированный универсальный 3DO файл.

Входными данными задачи являются:

) путь и имя генерируемого шаблона;

) путь к универсальному 3DO файлу.

К выходным данным относится полученный каркас графического приложения.

2.1.3 Анализ третьего уровня детализации задачи

Рассмотрим структуру задачи “Конвертация файла” (рисунок 2.3).

2.1.3.1 Загрузка файла для конвертации

Целью задачи является загрузка данных, описывающих геометрию объекта, из внешнего файла (3DS или Obj) во внутренние структуры приложения.

Входными данными задачи являются путь и имя универсального 3DO файла.

К выходным данным относятся загруженные в память приложения данные о геометрии модели из конвертируемого файла.

Рисунок 2.3 - структура задачи “Конвертация файла”

2.1.3.2 Расчет недостающих данных

Обычно в 3D форматах для минимизации их объема стараются хранить не всю информацию о геометрии модели. В таких случаях могут опускаться такие данные, например, как нормали (в вершинах и у граней). При этом расчет этих данных возлагается на приложение, а это негативно влияет на его производительность.

По этой причине для увеличения производительности приложения, использующего данные из 3DO файла, геометрия исходного файла дополняется рассчитанными недостающими данными. В случае, когда исходным файлом является 3DS файл, производится расчет нормалей и у вершин и к граням, а когда Obj файл - только вершинных.

К входным данным относятся структуры в памяти, полученные при загрузке исходного файла, и описывающие геометрию модели (массивы вершин, граней и т.п.).

Выходными данными являются рассчитанные нормали (вершинные и/или к граням).

2.1.3.3 Сохранение данных в 3DO формате

Основной целью задачи является сохранение, полученных после дополнительных расчетов, описания геометрии объектов в разработанный универсальный 3DO формат.

Входными данными является полное описание геометрии объектов, хранимое во внутренних структурах приложения, а также путь и имя 3DO файла.

Выходными данными является файл в 3DO формате, описывающий геометрию объектов.

Рассмотрим структуру задачи “Генерация шаблона” (рисунок 2.4).

Рисунок 2.4 - структура задачи “Генерация шаблона ”

2.1.3.4 Настройка параметров шаблона

К задаче “Настройка параметров шаблона” относится:

) указание пути и имени 3DO файла;

) указание пути по которому шаблон будет сохранен.

2.1.3.5 Создание и сохранение шаблона

Под созданием шаблона понимается внесение настроек в уже готовый каркас приложения (простой или с подключенной библиотекой). После чего измененный каркас переносится по указанному в настройках пути. При этом в папку с шаблоном также копируется и 3DO файл.

Готовый шаблон представляет собой проект выполненный в Microsoft Visual Studio 2005 на базе MFC Application.

Входными данными являются настройки шаблона.

К выходным данным относится полученный после конфигурирования шаблон.

2.2 Анализ шаблона графического приложения

.2.1 Анализ первого уровня детализации задачи

На первом уровне детализации приложение можно представить в виде трех основных блоков, представленных на рисунке 2.5.

Рисунок 2.5 - первый уровень детализации

Основными входными данными являются графические файлы, с описанием моделей в форматах поддерживаемых приложением - 3DS, Obj и 3DO форматы. В последующих версиях планируется увеличение поддерживаемых форматов.

К выходным данным относится отображенный на экране выбранный 3D файл.

2.1.2 Анализ второго уровня детализации задачи

Структура рассматриваемой задачи на втором уровне детализации представлена на рисунке 2.6.

Рисунок 2.6 - второй уровень детализации

2.2.2.1 Инициализация OpenGL

Назначение задачи “Инициализация OpenGL” состоит в начальной инициализации внутренних данных библиотеки OpenGL. Инициализация представляет собой следующие шаги:

) установка формата пикселей;

) создание контекста отображения;

) выбор текущего контекста отображения.

2.1.2.2 Загрузка 3D файла

Целью задачи является загрузка данных, описывающих геометрию объекта, из внешнего файла (3DS, Obj или 3DO) во внутренние структуры приложения.

Входными данными задачи являются путь и имя 3D файла.

К выходным данным относятся загруженные в память приложения данные о геометрии модели из выбранного файла.

2.1.2.3 Вывод 3D файла на экран

Назначение задачи “Вывод 3D файла на экран” состоит в отображении на экране средствами библиотеки OpenGL геометрии объектов загруженных ранее из 3D файла.

При выводе пользователь имеет возможность задать некоторые настройки, влияющие на отображение объектов на экране.

3. Разработка алгоритмов решения задачи

Этот раздел содержит описание алгоритмов решения следующих задач:

) автоматизированная система генерации приложений, использующих библиотеку OpenGL:

a) ввод данных;

b) конвертация файла;) генерация шаблона.

) шаблон графического приложения:

a) инициализация OpenGL;

b) загрузка 3D файла;

c) вывод 3D файла на экран.

Последовательное выполнение указанных задач обеспечивает достижение целей основной задачи. Алгоритмы решения выделенных подзадач описаны в следующих подразделах текущего раздела.

3.1 Автоматизированная система генерации приложений

.1.1 Алгоритм решения задачи “Ввод данных”

Целью задачи “Ввод данных” является получение исходных данных необходимых для получения 3DO файла или шаблона приложения. Для достижения данной цели нужно выполнить следующие действия:

) для конвертации файла:

a) осуществить указание пути к конвертируемому файлу (3DS или Obj);

b) осуществить указание пути и имени получаемого файла (3DO).

) для генерации шаблона:

a) задать имя шаблона;

b) указать путь к 3DO файлу;) указать путь по которому шаблон будет сохранен.

3.1.2 Алгоритм решения задачи “Конвертация файла”

.1.2.1 Алгоритм решения задачи “Загрузка файла для конвертации”

В результате выполнения данной задачи будет получена структура содержащая описание геометрии исходного файла (3DS или Obj).

Основными этапами этой задачи являются:

) открытие файла для чтения;

) определение типа файла - либо по расширению, либо по заголовку;

) чтение и интерпретация данных из файла:

a) чтение данных о координатах вершин;

b) чтение данных об индексах граней;) чтение данных о нормалях к граням (для Obj формата).

) сохранение прочитанных данных во внутренние структуры;

) закрытие файла.

3.1.2.2 Алгоритм решения задачи “Расчет недостающих данных”

Результатом выполнения задачи “Расчет недостающих данных” будет получение нормалей в каждой вершине и ко всем граням модели.

Обычно в 3D файлах хранение нормалей необязательно, т.к. имеется возможность их получения с помощью других данных геометрии - вершин и граней. Но для этого необходимо провести ресурсоемкие расчеты.

Для определения вектора нормали к плоскости достаточно иметь координаты трех точек принадлежащих этой плоскости. На рисунке 2.1 схематически показано получение такой нормали.

Рисунок 2.1 - Нормаль к плоскости

детализация файл данные графический

По определению векторное произведение двух векторов есть вектор перпендикулярный плоскости определенной их координатами. Исходя из этого свойства нужный нам вектор нормали n можно представить как векторное произведение векторов ab и bc:

= (bc, ab) (1.1)

где n - вектор нормали;, bc - векторы перпендикулярные n.

Используя правило треугольника и зная соответствующие вектора a, b и c получим вектора ab и bc:

= b - a (1.2)

bc = b - c (1.3)

Чтобы привести вектор нормали к единичной длине необходимо разделить вектор на его норму (длину):

n1 = n / |n| (1.4)

где n1 - вектор единичной длины;- вектор нормали;

|n| - длина вектора нормали.

В случае когда необходимо найти нормаль в вершине дело предстоит немного иначе. Для определения нормали в вершине требуется пройтись по всем граням содержащим эту вершину и просуммировать их нормали. После чего необходимо привести нормаль к единичному виду.

Как видно поиск нормалей в вершинах может занять некоторое время, поэтому хранение их в 3DO файле оправданно, и сильно сэкономит предварительную инициализацию.

3.1.2.3 Алгоритм решения задачи “Сохранение данных в 3DO формате”

Результатом данной задачи будет получение 3DO файла, описывающего большинство параметров геометрии объектов (вершины, грани, нормали).

Алгоритм решения можно разделить на такие этапы:

) открытие файла для записи;

) запись геометрии объектов в файл с учетом структуры 3DO формата:

a) запись координат вершин;

b) запись координат нормалей в вершинах;) запись координат нормалей к граням;) запись количества вершин в каждой грани;) запись индексов граней;

) закрытие файла.

3.1.3 Алгоритм решения задачи “Генерация шаблона”

.1.3.1 Алгоритм решения задачи “Настройка параметров шаблона”

Выполнение данной задачи сводится к заполнению полей отвечающих за настройку параметров шаблона:

) имя шаблона;

) путь к шаблону;

) путь и имя 3DO файла.

3.1.3.2 Алгоритм решения задачи “Создание и сохранения шаблона”

В результате проведения данной задачи будет получен сконфигурированный шаблон графического приложения.

Алгоритм “Создания и сохранения шаблона” подразумевает следующие пункты:

) копирование файлов шаблона по указанному пути;

) копирование 3DO файла.

3.2 Шаблон графического приложения

.2.1 Алгоритм решения задачи “Инициализация OpenGL”

Целью задачи “Инициализация OpenGL” является начальная инициализация OpenGL машины. Для достижения данной цели нужно выполнить следующие действия:

) установка формата пикселей;

) создание контекста отображения;

) выбор текущего контекста отображения.

3.2.2 Алгоритм решения задачи “Загрузка 3D файла”

Целью задачи “Загрузка 3D файла” является загрузка геометрии объектов из выбранного 3D файла.

Основными этапами этой задачи являются:

) открытие файла для чтения;

) определение типа файла - либо по расширению, либо по заголовку;

) чтение и интерпретация данных из файла:

a) чтение данных о координатах вершин;

b) чтение данных об индексах граней;) чтение данных о нормалях к граням;) чтение данных о нормалях в вершинах.

) сохранение прочитанных данных во внутренние структуры;

) закрытие файла.

3.2.3 Алгоритм решения задачи “Вывод 3D файла на экран”

Целью задачи “Вывод 3D файла на экран” является отображении на экране средствами библиотеки OpenGL геометрии объектов загруженных ранее из 3D файла.

Основными этапами этой задачи являются:

) настройка состояния отображения OpenGL окна;

) вывод 3D объектов с помощью функций OpenGL.

4. Синтез программного обеспечения

.1 Архитектура программного обеспечения

Для создания программного обеспечения в данной аттестационной работе используется язык программирования C++ и инструментальная среда разработки Microsoft Visual Studio 2005. Все создаваемые с помощью Microsoft Visual Studio 2005 приложения являются проектами. Студия предоставляет возможность создавать каркасы проектов при помощи генераторов приложений - мастеров. Мастер генерирует шаблон проекта, на основании которого, впоследствии, создается приложение. Также мастер предоставляет структуру программы, основные меню, панели инструментов, значки и т.д. Это позволяет, создав каркас приложения, сразу перейти непосредственно к программированию его функциональности.

Каркас проекта создан при помощи стандартного генератора приложений Application Wizard на основе шаблона MFC Application. Шаблон приложения MFC Application - является основой для стандартных приложений Windows.

В состав созданного при помощи Application Wizard проекта с именем GenOGLApp входят следующие файлы:

1) GenOGLApp.h - заголовочный файл, содержащий описание класса отвечающего за начальную инициализацию и создание главного окна проекта;

2) GenOGLApp.cpp - содержит реализацию выше описанного класса;

3) MainFrm.h - содержит описание класса отвечающего за внешний вид главного окна проекта;

4) MainFrm.cpp - содержит реализацию выше описанного класса;

5) GenOGLAppDoc.h - описывает класс хранящий основные данные проекта;

6) GenOGLAppDoc.cpp - содержит реализацию выше описанного класса;

7) GenOGLAppView.h - содержит описание класса отвечающего за отображение в главном окне проекта данных из предыдущего класса;

8) GenOGLAppView.cpp - содержит реализацию выше описанного класса;

9) Camera.h - отвечает за описание класса предоставляющего реализацию камеры для просмотра OpenGL окна;

10) Camera.cpp - содержит реализацию выше описанного класса;

11) ConvertDlg.h - содержит описание класса окна диалога отвечающего за конвертацию 3D файла в 3DO формат;

12) ConvertDlg.cpp - содержит реализацию выше описанного класса;

13) GenerateDlg.h - содержит описание класса окна диалога отвечающего за создание шаблона OpenGL приложения;

14) GenerateDlg.cpp - содержит реализацию выше описанного класса;

15) StdAfx.h - используется для создания пре-компилированного файла заголовка.

Основными классами приложения являются:

1) CGenOGLApp - главный класс приложения, наследуется от стандартного класса CWinApp. Выполняет начальную инициализацию и создание главного окна проекта;

) СMainFrame - класс наследуемый от CFrameWnd, задает внешний вид главного окна проекта;

3) CGenOGLAppDoc - класс наследуемый от CDocument, хранит основные данные проекта;

4) CGenOGLAppView - класс наследуемый от CView, выполняет начальную инициализации OpenGL и отвечает за вывод данных хранящихся в предыдущем классе;

5) CCamera - класс, реализующий возможности камеры для просмотра объектов в OpenGL окне;

6) CConvertDlg - класс наследуемый от CDialog, отвечает за получение основных параметров для конвертации 3D файла в 3DO формат и саму конвертацию;

7) CGenerateDlg - класс наследуемый от CDialog, отвечает за получение основных параметров для генерации шаблона OpenGL приложения и саму генерацию.

Общая архитектура приложения на уровне основных классов представлена на рисунке 4.1.

Рисунок 4.1 - Архитектура приложения

Результатом выполнения данного программного обеспечения является сгенерированный шаблон графического приложения. Шаблон, так же как и основное приложение, создан с помощью Application Wizard на основе MFC Application и имеет схожую с ним архитектуру.

В состав спроектированного шаблона графического приложения с именем OGLApp входят следующие файлы:

1) OGLApp.h - заголовочный файл, содержащий описание класса отвечающего за начальную инициализацию и создание главного окна проекта;

2) OGLApp.cpp - содержит реализацию выше описанного класса;

3) MainFrm.h - содержит описание класса отвечающего за внешний вид главного окна проекта;

4) MainFrm.cpp - содержит реализацию выше описанного класса;

5) OGLAppDoc.h - описывает класс хранящий основные данные проекта;

6) OGLAppDoc.cpp - содержит реализацию выше описанного класса;

7) OGLAppView.h - содержит описание класса отвечающего за отображение в главном окне проекта данных из предыдущего класса;

8) OGLAppView.cpp - содержит реализацию выше описанного класса;

9) Camera.h - отвечает за описание класса предоставляющего реализацию камеры для просмотра OpenGL окна;

10) Camera.cpp - содержит реализацию выше описанного класса;

11) StdAfx.h - используется для создания пре-компилированного файла заголовка.

Основными классами шаблона являются:

1) COGLApp - главный класс приложения, наследуется от стандартного класса CWinApp. Выполняет начальную инициализацию и создание главного окна проекта;

) СMainFrame - класс наследуемый от CFrameWnd, задает внешний вид главного окна проекта;

3) COGLAppDoc - класс наследуемый от CDocument, хранит основные данные проекта;

4) COGLAppView - класс наследуемый от CView, выполняет начальную инициализации OpenGL и отвечает за вывод данных хранящихся в предыдущем классе;

5) CCamera - класс, реализующий возможности камеры для просмотра объектов в OpenGL окне;

Общая архитектура шаблона графического приложения на уровне основных классов представлена на рисунке 4.2.

Рисунок 4.2 - Архитектура шаблона OpenGL приложения

4.2 Информационное пространство системы

Рисунок 4.3 отображает информационное пространство приложения. Прямоугольниками изображены основные объекты приложения. Параллелограммами представлены передаваемые между объектами приложения данные. Стрелки на рисунке указывают направление передачи данных.

Под данными обозначенными на рисунке 4.3 как “Геометрические параметры 3D объекта” подразумевается геометрия объекта загруженного из 3DO файла.

Под данными “Положение камеры в пространстве” подразумевается положение камеры использующейся для просмотра OpenGL окна.

Параллелограммы с надписями “Путь к конвертируемому 3D файлу” и “Путь к исходному 3DO файлу” показывают входные данные, использующиеся при операции конвертирования.

Под данными обозначенными как “Сконвертированный 3DO файл” понимается файл 3DO формата полученный после операции конвертирования.

Параллелограммы с надписями “Путь к 3DO файлу” и “Путь к шаблону приложения” показывают входные данные, использующиеся при операции генерации приложения.

Под данными обозначенными как “Сгенерированный шаблон приложения” подразумевается шаблон OpenGL приложения полученный после операции генерации шаблона приложения.

Рисунок 4.4 в свою очередь отображает информационное пространство шаблона графического приложения.

Под данными обозначенными как “Геометрические параметры 3D объекта” подразумевается геометрия объекта загруженного из 3DO файла.

Рисунок 4.3 - Информационное пространство приложения

Рисунок 4.4 - Информационное пространство шаблона приложения

4.3 Интерфейс пользователя

Для корректного запуска программы необходимо:

) предустановленная операционная система Windows XP SP3;

) наличие установленного пакета NET Framework 2.0;

) наличие установленного пакета Microsoft Visual C++ 2005 Redistributable;

) правильно установленное программное обеспечение на компьютере.

Под правильной установкой программного обеспечения понимается приведенная на рисунке 4.5 структура расположения файлов приложения. Прямоугольниками обозначены каталоги.

Рисунок 4.5 - Структура расположения файлов приложения

Программа имеет оконный графический интерфейс. При запуске программы на выполнение на экране монитора появляется окно, имеющее заголовок “Автоматизированная система генерации приложений” и являющееся главным окном приложения. Изображение вышеуказанного окна представлено на рисунке 4.6.

Рисунок 4.6 - Главное окно приложения

Главное окно имеет:

) меню с различными пунктами;

) окно OpenGL с осями и сеткой;

) статусную строку, показывающую состояние приложения и подсказки.

Меню в свою очередь разделено на следующие пункты:

) пункт меню “Файл” - содержит стандартные команды открытия, и закрытия файла, а также пункт корректного выхода из приложения;

) пункт “Вид” (рисунок 4.7) - отвечает за вид главного окна и предоставляет доступ к следующим командам:

a) команда “Статусная строка” - отвечает за отображение/скрытие cтатусной строки;

b) команда “Оси” - отвечает за отображение/скрытие осей в OpenGL окне;) команда “Сетка” - отвечает за отображение/скрытие сетки;) команды “Точка” - “Сглаживание” - отвечают за режим отображения 3D модели;) команда “Режим отсечения” - отвечает за включение/отключение режима отсечения задней поверхности полигонов;) команда “Свет” - отвечает за включение/отключение света в OpenGL окне;) команда “Тест глубины” отвечает за включение/отключение теста глубины в OpenGL пространстве.

) пункт меню “Инструменты” - реализует доступ к основным функциям приложения и включает следующие команды:

a) команда “Конвертирование” - вызывает диалоговое окно выполняющее операцию конвертирования 3D файла;

b) команда “Генерация” - вызывает диалоговое окно выполняющее операцию генерации шаблона приложения;

) пункт меню “Помощь” - имеет единственный подпункт “О программе”, который отвечает за отображение окна с одноименным названием (рисунок 4.12).

Рисунок 4.7 - Пункт меню “Вид”

При выборе команды “Конвертирование” на экране отображается окно, вид которого приведен на рисунке 4.8. В данном окне необходимо указать пути, используемые при операции конвертирования - путь к входному 3D файлу и путь к выходному 3DO файлу. При вводе несуществующих путей будет выведено сообщение, приведенное на рисунке 4.9. В случае, если указанные пути существуют, но 3D файл имеет несоответствующий формат или поврежден, будет выведено сообщение, изображенное на рисунке 4.10. Если конвертирование будет успешным, то окно просто закроется, а в статусной строке будет соответствующее сообщение.

При выборе команды “Генерация” на экране появится диалоговое окно, вид которого приведен на рисунке 4.11. Здесь необходимо ввести исходные данные, используемые при операции генерации шаблона OpenGL приложения - путь к 3DO файлу и путь, по которому шаблон будет сохранен. При вводе несуществующих путей будет выведено сообщение, приведенное на рисунке 4.9. Если генерация пройдет успешно, то окно просто закроется, а в статусной строке будет соответствующее сообщение.

Рисунок 4.8 - Вид окна “Конвертирование”

Рисунок 4.9 - Окно предупреждения

Рисунок 4.10 - Окно предупреждения

Также данное приложение умеет загружать и отображать на экране файлы 3D форматов (3DS, OBJ и 3DO). Для этого необходимо выбрать пункт меню “Открыть” (рисунок 4.13), после чего необходимо указать 3D файл. После этого выбранный 3D файл будет открыт и его содержимое отображено в главном окне приложения (рисунок 4.14). Для того чтобы убрать 3D объект с экрана необходимо выбрать пункт меню “Закрыть”.

Рисунок 4.11 - Вид окна “Генерация”

Рисунок 4.12 - Вид окна “О программе”

Также если при открытии 3D файла, данный файл окажется поврежденным или несоответствующего формата, будет выведено сообщение, представленное на рисунке 4.10.

Рисунок 4.13 - Вид окна “Открыть”

Рисунок 4.14 - Вид главного окна с открытым 3D объектом

5. Тестирование системы

Тестирование - это доказательство работоспособности или неработоспособности программного продукта. Тест - это комбинация исходных данных, результат обработки которых тестируемой программой известен заранее.

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

Тестирование программы производилось на следующей конфигурации ПО компьютера:

) операционная система - Windows XP SP3;

) пакет NET Framework 3.5;

3) пакет Microsoft Visual C++ 2005 Redistributable.

При тестировании программы производилась последовательная проверка корректности выполнения данным приложением его основных функций:

1) загрузка 3D файла;

) конвертирование 3D файла;

) генерация шаблона OpenGL приложения.

В целях тестирования устойчивости работы программы при загрузке 3D файлов, был произведен ввод некорректных данных и получены следующие результаты:

) выбран 3D файл с неправильной структурой. Результат - на экран выводится окно с сообщением “Файл поврежден или не является поддерживаемым форматом!”.

) выбран 3D файл с нулевым размером. Результат - на экран выводится окно с сообщением “Файл поврежден или не является поддерживаемым форматом!”.

) выбран 3D файл с правильной структурой, но не хранящий никакой информации о геометрии объектов. Результат - загрузка прошла успешно, но на экране ничего не выведено.

В целях тестирования устойчивости работы программы при конвертировании 3D файлов, был произведен ввод некорректных данных и получены следующие результаты:

) нажатие кнопки “Конвертировать” без заполнения полей исходных данных. Результат - программа не реагирует и продолжает ждать ввода данных.

) ввод в поля окна “Конвертирование” несуществующих путей. Результат - на экран выводится окно с сообщением “Исходные данные введены неверно!”.

) ввод в поля окна “Конвертирование” существующих путей, но 3D файл имеет неправильную структуру. Результат - на экран выводится окно с сообщением “Файл поврежден или не является поддерживаемым форматом!”.

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

) нажатие кнопки “Генерация” без заполнения полей исходных данных. Результат - программа не реагирует и продолжает ждать ввода данных.

) ввод в поля окна “Генерация” несуществующих путей. Результат - на экран выводится окно с сообщением “Исходные данные введены неверно!”.

) удаление из каталога с программой директории с именем “TemplateOGLApp”. Результат - на экран выводится окно с сообщением “Не найден шаблон графического приложения!”.

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

) нарушена структура расположения каталогов приложения. Результат - на экран выводится окно с сообщением “Не найден шаблон графического приложения!”.

) удалены из каталога с исполняемым файлом библиотеки поставляемые с ним. Результат - на экран выводится окно с сообщением “Приложению не удалось запуститься, поскольку ld3ds.dll не был найден. Повторная установка приложения может исправить эту проблему!” и программа прекращает свое выполнение.

При выполнении операции конвертирования по указанному в диалоговом окне “Конвертирование” пути, был создан файл 3DO формата (структура этого файла уже приводилась выше). Корректность данного файла была проверена его открытием в данном приложении, что показало его соответствие исходному 3D файлу.

При выполнении операции генерации шаблона приложения по указанному в окне “Генерация приложения” пути, был сгенерирован шаблон графического приложения. Данное приложение является проектом, созданным в Microsoft Visual Studio 2005 на базе шаблона MFC Application. Для компиляции этого проекта студия должна иметь набор библиотек описывающих стандартные классы MFC. При этом для запуска приложения данные библиотеки не потребуются, т.к. их функционал статически связан с приложением.

Полученные в результате проведенного тестирования результаты свидетельствуют о корректности выполнения тестируемым приложением своих функций. Из этого можно сделать вывод о корректности работы всей программы.

6. Оценка экономической эффективности применения программного обеспечения и определение его цены

.1 Порядок расчета и анализа экономической эффективности

В составе комплекса средств автоматизации особое место занимает программное обеспечение (ПО) автоматизированных систем (АСНИ, САПР, АСУ). Особая важность данного вида обеспечения определяется тем, что именно в нем закладываются и реализуются функции автоматизированных систем. В состав ПО могут включаться пакеты программ и отдельные программные модули, созданные для широкого применения или специального назначения. Однако оригинальные или специальные программы имеют возможность найти в дальнейшем широкое применение, если они созданы и оформлены в соответствии с определенными требованиями, предъявляемыми к созданию программ как к продукции производственно-технического назначения, т.е. как к программным изделиям.

В связи с этим целесообразно выделять процесс создания программного обеспечения из общего процесса создания автоматизированных систем и рассматривать его с двух позиций:

1) системной, т.е. как создание программного обеспечения автоматизированных систем;

2) прикладной - как создание отдельных изделий, которые могут использоваться независимо от программного обеспечения данной автоматизированной системы.

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

Качество программного обеспечения определяется тремя составляющими:

1) с точки зрения специалиста-пользователя данным программным изделием;

2) с позиции использования ресурсов и их оценки;

) с позиции выполнения требований на программном обеспечении.

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

Основные сложности в процессе создания программного изделия возникают, прежде всего, из-за плохого планирования (50%), недостаточного контроля (34%), по техническим причинам (всего 16%).

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

Процесс программирования необходимо планировать, контролировать и завершать в заданные сроки. Кроме того, работа программистов должна быть оплачена по результатам их труда: его качеству, количеству, интенсивности выполнения работ; стимулировать высокие результаты труда. Для перечисленных целей часто используют нормативы, чтобы сравнивать и оценивать планируемые и фактические результаты.

На первых этапах проектирования следует выполнять укрупненные расчеты трудоемкости работ по созданию программного обеспечения автоматизированных систем (подсистем, задач) в целях прогнозирования сроков работ, затрат на их выполнение, оценки предполагаемой экономической эффективности автоматизации.

Известно несколько нормативных методов, укрупненных расчетов трудоемкости работ по созданию систем (задач):

1) сопоставительный (метод аналогов), применяемый когда трудоемкость новых разработок принимают по опытным данным подобных разработок с использованием поправочных коэффициентов;

2) метод эмпирических зависимостей, основанный на применении нормативов в виде математических зависимостей искомого показателя (трудоемкости, стоимости работ) от технических параметров объекта разработки (например, показателя сложности программ);

) метод прямого счета, основанный на определении содержания и объемов работ и использовании нормативов на отдельные единицы работ. Нормативы этого метода можно разделить на объемные, характеризующие предполагаемые объемы работ (например, количество операторов в программе, количество входных и выходных форм в задаче и т.п.), и ресурсные, определяющие трудоемкость типовых единиц работы;

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

Разнообразие методов объясняется различными возможностями получения исходных данных о планируемых работах, наличием соответствующих нормативов, потребностями детализации и точности расчетов.

Анализ различных подходов к нормированию процесса программирования показывает, что в качестве основного фактора следует принимать размер исходного текста программного обеспечения (для любого типа программного обеспечения).

Для быстрой приближенной оценки трудоемкости и длительности, разработки программного обеспечения может использоваться и так называемая «базовая модель».

При этом затраты труда (трудоемкость разработки программного обеспечения) оценивают таким образом, чел.-мес.:

(6.1)

где - число исходных команд (тыс.), а длительность разработки, мес.:

(6.2)

Производительность труда группы разработчиков программного изделия (исх.команд./чел.-мес.) определяется формулой

(6.3)

Среднее число исполнителей рассчитывают исходя из определенных или заданных характеристик трудоемкости и длительности разработки программного продукта, чел.:

(6.4)

Если известны по опыту работы или заданы по нормативам затраты труда на подготовку описания задачи, исследование алгоритма решения задачи, разработку блок-схемы алгоритма, программирование, отладку программы на ЭВМ, подготовку документации по задаче, то трудоемкость разработки программного обеспечения можно рассчитать по формуле:

(6.5)

где - трудоемкость i-го этапа.

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

Таблица 6.1 - Коэффициенты, используемые при оценке затрат труда на подготовку задачи к решению ее на ЭВМ

№ п/п	Фактор	Условные обозначения	Коэффициент	Примечания
1	Коэффициент сложности ПО	1.25..2.00Относительно типовой задачи
2	Коэффициент коррекции программы	1.05..1.103-5 коррекций ведут к изменению 5-10% ПО

3 Коэффициент квалификации разработчика До двух лет -1,25

-3 года - 1,0

-5 лет - 0,9..0,85

-7 лет - 0,8..0,7

Св. 7 лет - 0,7..0,6В зависимости от срока разработчика
4	Коэффициент увеличения затрат вследствие недостаточного описания задачи	1,2..1,5В зависимости от сложности задачи
5	Коэффициент, учитывающий затраты на оформление задачи	1,2
6	Коэффициент, учитывающий затраты на внедрение задачи	1,1

Влияние на (формула (6.1)) числа тысяч исходных команд снижено, но зато мы учитываем ряд других факторов, влияющих на трудоемкость разработки программного обеспечения.

Смету затрат на разработку программного обеспечения составляют по статьям калькуляции. При этом необходимо в первую очередь рассчитать фонд заработной платы разработчиков:

(6.6)

где - трудоемкость i-й работы по созданию и внедрению ПО;

- средняя дневная (часовая) ставка разработчика;

n - количество работ (этапов), на которые разделена задача.

Стоимость программного обеспечения:

(6.7)

где - коэффициент, учитывающий дополнительную заработную плату (можно принимать 0,1..0,3).

- коэффициент, учитывающий отчисления в фонд заработной платы;

- коэффициент накладных расходов организаций, разрабатывающих проект (можно принять равным единице);

- коэффициент прочих расходов (0,1…0,2);

- машинное время, необходимое для отладки программы, ч.;

- стоимость машино-часа работы ЭВМ (принимают по установленным тарифам на аренду или рассчитывают для конкретных условий).

Эффективность программного продукта определяется формулой:

(6.8)

где - среднегодовой экономический эффект, полученный от применения данного программного продукта, грн.

При расчетах затрат на создание и внедрение систем (задач) необходимо выделять затраты на создание программного обеспечения, которые потом будут списываться в эксплуатационные затраты. Если программа разрабатывается организацией только для себя, стоимость программного обеспечения определяется формулой (6.5) для объема соответствующих работ (постановки задач, разработки и отладки программ, разработки программной документации).

Если же разрабатываемая программа будет использоваться несколькими предпринимателями-потребителями, на нее определяют цену реализации.

Цена программы для отдельного потребителя может быть рассчитана так:

(6.9)

где - стоимость дополнительных работ по тиражированию программы для отдельного потребителя;

- норматив прибыли организации, разрабатывающей программу, можно принимать равным 0.1…0.15.

- количество организаций, которые приобретут данную программу.

Нижний предел цены может быть рассчитан так:

(6.10)

Верхний предел цены:

(6.11)

где - годовой экономический эффект t-го года;

- число лет эксплуатации программного обеспечения (до шести лет).

Договорная цена должна находиться в диапазоне между нижним и верхним пределами, причем эффективность программного обеспечения и с точки зрения разработчика, и с точки зрения покупателя должна быть больше нормативной :

(6.12)

а при тиражировании:

(6.13)

где m - число копий;

- затраты на тиражирование.

Эффективность с точки зрения покупателя (потребителя) ПО:

(6.14)

где - коэффициент, учитывающий налог на добавленную стоимость (0,2);

- дополнительные издержки капитального характера при введении ПО в эксплуатацию.

6.2 Расчет экономической эффективности применения программного обеспечения и определение его цены

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

Смету затрат на разработку программного обеспечения составляют по статьям калькуляции. При этом в первую очередь необходимо рассчитать фонд заработной платы разработчиков по формуле 6.7.

Так как при создании данного программного продукта был занят один разработчик, фонд его заработной платы рассчитаем следующим образом:

, (6.18)

где tобщ - общая трудоемкость работ;

L - средняя дневная ставка разработчика.

Общая трудоемкость работ составила 60 дней. Среднюю дневную ставку разработчика примем в размере 100 грн. Тогда фонд заработной платы составит:

Фзп = 60 * 100 = 6000 грн.

Стоимость программного обеспечения вычислим по формуле 6.8. Для этого примем коэффициент wот = 0,426, представляющий собой сумму коэффициентов отчисления (в фонд соц. страхования - 0,05; в фонд Чернобыля - 0,1; в фонд занятости - 0,05; в пенсионный фонд - 0,2; на мед. страхование - 0,026), а так же коэффициенты wд = 0,2, wн = 1, wпр = 0,1 и величины tЭBM = 480 ч., Lэвм = 6,5 грн.

Подставим значения коэффициентов и других величин в формулу затрат на разработку:

Кпр = 6000 × [(1+0,2) × (1+0,426)+ 1 + 0,1] + 480 × 6,5= 19987.2 грн.

Получим Кпр = 19987.2 грн.

Предположим, что программный продукт будет использоваться несколькими предпринимателями - потребителями. В этом случае цена для отдельного потребителя может быть рассчитана по формуле 6.10.

Так как на момент расчета неизвестно количество потребителей, нижний предел цены примем равным стоимости разработки программного продукта, т. е. ЦНИЖН = 19987.2 грн. Верхний предел зависит от экономического эффекта в каждый год использования. Так как в данном случае невозможно оценить экономический эффект, примем верхний предел цены равным:

ЦВЕРХ = 2 * КПР = 2 * 19987.2 = 39974 ,4 грн.

Для формирования договорной цены на программный продукт воспользуемся формулами (6.13) и (6.15), позволяющими оценить экономическую эффективность с позиции продавца-разработчика и покупателя-пользователя.

Предположим, что договорная цена Цдог = 30000 грн.

Таблица 6.2 - Структура трудоемкости работ по этапам создания программного обеспечения

№ п/п	Наименование работ	Структура трудоёмкости, %	Структура трудоёмкости, чел/дни	Машинное время, ч
1	Организационная подготовка к созданию ПО	1	0,6	__
2	Разработка ТЗ на постановку задачи	3	1,8	25
3	Постановка задачи
3.1	Разработка алгоритмов	14	8,4	60
3.2	Разработка информационной базы	8	4,8	20
3.3	Техническое обеспечение	3	1,8	10
3.4	Разработка контрольного примера	10	6	40
3.5	Расчёт экономической эффективности	1	0,6	5
3.6	1	0,6	20
4	Разработка ПО
4.1	Разработка машинных алгоритмов	10	6	50
4.2	Разработка программы	20	12	140
4.3	Разработка программной документации	5	3	20
4.4	Расчет затрат и экономической эффективности	1	0,6	10
4.5	Выпуск комплекта рабочей документации	2	1,2	12
5	Внедрение программного обеспечения
5.1	Подготовка к внедрению программного обеспечения	5	3	10
5.2	Наладка и предварительные испытания	8	4,8	24
5.3	Отладка и корректировка ПО и документации	6	3,6	24
5.4	Расчёт фактической экономической эффективности	2	1,2	10
	Итого	100 %	60	480

Если учесть, что дополнительные издержки на обучение персонала и ввод в эксплуатацию системы составили 2000 грн., а НДС=20%, то

Таким образом сравнение полученных коэффициентов экономической эффективности с величиной коэффициента нормативной эффективности Ен=0,5, рассчитанного по величине банковского процента по долгосрочным кредитам, позволяет сделать вывод, что разработчик программного продукта вправе добиваться в процессе переговоров более высокой договорной цены, чем Цдог = 30000 грн.

Договорная цена, на программный продукт может быть установлена и из условия равной экономической эффективности у разработчика и пользователя, то есть когда Еразр=Епотр, при выполнении условия, что данные коэффициенты эффективности превышают нормативный уровень.

Такой подход к формированию договорной цены на программный продукт позволит более обоснованно достигать баланса интересов и учитывать целесообразность затрат на разработку в целом.

7. Охрана труда

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

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

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

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

В результате выполнения данной выпускной работы был получен программный продукт, позволяющий генерировать приложения, использующие библиотеку OpenGL.

При создании данного продукта была использована компьютерная техника, а именно ПК, что подразумевает воздействие опасных и вредных производственных факторов.

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

7.1 Характеристика рабочего места

Существенное значение в работе с компьютером имеет рабочая поза. От нее зависит степень функционального напряжения и, следовательно, преждевременное утомление. Рабочее место пользователя видеотерминала и ЭВМ, все его элементы, а также их расположение должны соответствовать эргономическим требованиям ГОСТ 12.2.032 "ССБТ. Рабочее место при выполнении работ сидя. Общие эргономические требования".

Результаты измерений, проведенные в компьютерных классах показали, что расстояние от глаз пользователя до экрана монитора составляет от 40 до 70 см при гигиенической норме 50 - 70 см. Угол зрения у отдельных пользователей колеблется от 15 до 30° при оптимальной величине 10 - 20°.

Для обеспечения пространственных параметров рабочего места в эргономическом отношении необходима специальная мебель - регулируемые по высоте стулья, столы.

Следует применять в обязательном порядке подставку для ног тем, у кого ноги не достают до пола, для обеспечения оптимальной рабочей позы. Сидение, спинка и стационарные или съемные подлокотники рабочего сидения должны быть подъемно-поворотными, такими, чтобы можно было регулировать высоту, угол наклона сидения и спинки, расстояние спинки к переднему краю сидения, высоту подлокотников. Регулирование каждого параметра должно быть независимым, плавным или ступенчатым, с надежной фиксацией.

Монитор и клавиатура должны располагаться на оптимальном расстоянии от глаз пользователя (но не ближе 60 см) с учетом размера алфавитно-цифровых знаков и символов.

Клавиатуру следует размещать на поверхности стола или на специальной регулируемой по высоте рабочей поверхности, отдельно от стола на расстоянии 100...300 мм от края, более близкого к пользователю. Угол наклона клавиатуры может быть в границах 5...150. Исследования показали, что неправильное положение тела относительно клавиатуры и устройства типа «мышь» может стать причиной заболеваний скелетно-мышечного аппарата кистей и негативно влиять на пользователей компьютера.

Рабочие места с ВДТ (видеодисплейный терминал) и ПЭВМ по отношению к световым проектам должны располагаться так, чтобы естественный свет падал сбоку, преимущественно слева. Оконные проемы в помещениях должны быть оборудованы регулируемыми устройствами типа жалюзи, занавеси, внешние козырьки и др.

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

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

Опасные и вредные производственные факторы подразделяются на четыре группы: физические, химические, биологические и психофизические.

При работе с ПЭВМ пользователь подвергается воздействию следующих вредных физических факторов.

Повышенный уровень шума

Шум ухудшает условия труда, оказывая вредное действие на организм человека. Работающие в условиях длительного шумового воздействия испытывают раздражительность, головные боли, головокружение, снижение памяти, повышенную утомляемость, понижение аппетита, боли в ушах и т. д. Такие нарушения в работе ряда органов и систем организма человека могут вызвать негативные изменения в эмоциональном состоянии человека вплоть до стрессовых. Под воздействием шума снижается концентрация внимания, нарушаются физиологические функции, появляется усталость в связи с повышенными энергетическими затратами и нервно-психическим напряжением, ухудшается речевая коммутация. Все это снижает работоспособность человека и его производительность, качество и безопасность труда. Уровень шума на рабочих местах не должен превышать 50 дБ.

В ПЭВМ источниками шума служат охлаждающие вентиляторы и накопители данных с подвижными частями.

Неблагоприятные параметры микроклимата

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

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

Отсутствие или недостаточная освещённость рабочей зоны

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

Вредная ионизация воздуха

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

Вредное статическое электричество

При работе с ВДТ разрядные токи статического электричества чаще всего возникает при прикосновении к поверхности экрана или корпусу системного блока. Такие разряды опасности для человека не представляют, но кроме неприятных ощущений они могут привести выходу из строя компьютера.

Электромагнитное излучение

ЭМИ, возникающие при работе электронных компонентов системного блока, имеют незначительные уровни, а дисплеи, сконструированные на основе электронно-лучевой трубки (ЭЛТ), излучают:

1) рентгеновские лучи, источником которых является люминофорное покрытие экрана;

2) лучи оптического диапазона, возникающие в результате взаимодействия электронов со слоем люминофора;

3) ЭМИ и электромагнитные поля (ЭМП) радиочастотного диапазона, источником которых является электронный луч.

Результаты обследования людей, работающих в условиях воздействия ЭМП значительной интенсивности, показали, что нервная и сердечнососудистая системы наиболее подвержены вредному воздействию. Отмечены изменения в системе кроветворения, а также имеют место заболевания эндокринной системы и органов зрения. В условиях длительного профессионального облучения с периодическим повышением предельно допустимых уровней (ПДУ) у части людей отмечались функциональные изменения в органах пищеварения, нарушения секреции и кислотности желудочного сока. Выявлены также функциональные сдвиги со стороны эндокринной системы (повышение функциональной активности щитовидной железы, изменение характера сахарной кривой и т.д.). ЭМИ влияют на центральную нервную систему, что ведет к торможению в коре головного мозга, в результате чего резко снижается работоспособность.

Опасность поражения электрическим током

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

7.3 Разработка мероприятий по предотвращению или ослаблению возможного воздействия опасных и вредных эксплуатационных факторов на работающих

С целью исключения вредного влияния персонального компьютера (ПК) на организм человека необходимо соблюдать и выполнять изложенные ниже правила и нормы.

Микроклимат. Основные параметры микроклимата (температура воздуха, влажность и скорость движения воздуха на рабочем месте) должны соответствовать требованиям СН 2152-80.

Таблица 7.1 - Параметры микроклимата в помещениях, оснащенных видеотерминалами

Период года	Температура воздуха, 0С не более	Относительная влажность воздуха, %	Скорость движения воздуха, м/с
Холодный	22-24	40-60	0,1
Теплый	23-25	40-60	0,1

Для нормализации влажности воздуха в помещениях с ПЭВМ следует применять увлажнители воздуха, заправляемые ежедневно дистиллированной или прокипяченной питьевой водой. Также, для поддержания нужного температурного режима необходимо применять системы кондиционирования.

Также необходимо контролировать уровень аэроионизации. Параметры ионного состава воздуха в помещениях, оснащенных видеотерминалами, должны отвечать требованиям, приведенным в таблице 7.2, и соблюдаться в обязательном порядке.

Таблица 7.2 - Параметры ионного состава воздуха в помещениях

Уровни	Число ионов в 1см3 воздуха
	n+	n-
Минимально необходимые	400	600
Оптимальные	1500-3000	300-5000
Максимально допустимые	50000	50000

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

Вентиляция. Одним из мероприятий по оздоровления воздушной среды является устройство вентиляции и отопления. Задачей вентиляции является обеспечение чистоты воздуха и заданных метеорологических условий на рабочих местах путем удаления загрязненного или нагретого воздуха. Т.к. работа видеотерминалов сопровождается выделением тепла, то необходим достаточный объем вентиляции, для чего в вычислительном центре предусматриваются системы кондиционирования воздуха.

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

Освещение. В помещениях, где эксплуатируются ПЭВМ, освещение, как правило, смешанное. Не рекомендуется работать на компьютере в темноте, только при свечении монитора. Если естественного освещения недостаточно, дополнительно устанавливается искусственное, причем применяется всегда - не только в темное время суток.

Искусственно освещаются помещения эксплуатации мониторов ПЭВМ при помощи системы общего равномерного освещения. Можно использовать местное освещение, предназначенное для освещения зоны расположения документов.

Для подсветки документов можно использовать местное освещение, если оно не образует бликов на поверхности экрана и не увеличивает освещенность экрана более 300 лк. Светильники местного освещения должны иметь непросвечивающий отражатель с защитным углом не менее 40°. Следует также ограничивать неравномерность распределения яркости в поле зрения мониторов и ПЭВМ, при этом соотношение яркости между рабочими поверхностями не должно превышать 3:1 - 5:1, а между рабочими поверхностями и поверхностями стен и оборудования - 10:1. Для обеспечения нормированных значений освещения в помещениях с видеотерминалами ПЭВМ общего и персонального пользования необходимо очищать оконное стекло и светильники не реже двух раз в год и своевременно заменять перегоревшие лампы.

Организация рабочего места. Расстояние между рабочими столами и видеомониторами должно быть не менее 2 м, а расстояние между боковыми поверхностями видеомониторов - не менее 1,2м. Идеально ПК должны размещаться по периметру помещения. Конструкция рабочего стула (кресла) должна обеспечивать поддержание рациональной рабочей позы при работе на ПК, позволять изменять позу с целью снижения статического напряжения мышц шейно-плечевой области и спины. Клавиатуру следует располагать на поверхности стола на расстоянии 100-300 мм от края стола. Экран монитора должен находиться от глаз пользователей на оптимальном расстоянии 700-800 мм, но не ближе 600 мм с учетов размеров алфавитно-цифровых знаков и символов.

Режимы труда и отдыха должны организовываться в зависимости от вида и категории трудовой деятельности. На протяжении рабочей смены должны устанавливаться регламентированные перерывы. Продолжительность непрерывной работы с ВДТ без регламентированного перерыва не должна превышать двух часов.

Электромагнитное излучение. Насколько следует отстраниться от источника излучения - зависит от его интенсивности. Например, чтобы уменьшить полевую интенсивность, Вам, возможно, придется переместиться на расстояние:

1) 25 метров для линий электропередачи и вышек сотовой связи;

) 30 см. от Вашего компьютерного монитора;

) 2.5 см от сотового телефона.

Правила защиты:

) по возможности, стоит приобрести жидкокристаллический монитор, поскольку его излучение значительно меньше, чем у распространённых ЭЛТ мониторов (монитор с электроннолучевой трубкой);

) системный блок и монитор должен находиться как можно дальше от вас;

) не оставляйте компьютер включённым на длительное время если вы его не используете;

) в связи с тем, что электромагнитное излучение от стенок монитора намного больше, постарайтесь поставить монитор в угол, так что бы излучение поглощалось стенами;

) по возможности сократите время работы за компьютером и почаще прерывайте работу.

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

1) каждый пользователь ПЭВМ, впервые приступающий к работе в данной учебной лаборатории, должен изучить инструкцию по технике безопасности при работе на данном оборудовании и пройти инструктаж по месту работы с обязательной отметкой в журнале регистрации;

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

) ремонтные и профилактические работы на электроустановках, установка и снятие корпусов ЭВМ допускается только при отключенном электропитании;

) корпуса электроустройств должны быть надежно заземлены.

Расчет защитного заземления

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

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

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

На рисунке 7.1 представлена принципиальная схема защитного заземления в сетях с изолированной нейтралью. При этом, чем меньше сопротивление заземления Rз, тем меньший ток будет протекать через тело человека, распределяясь между параллельными ветвями обратно пропорционально их сопротивлениям: Rh = 1000 Ом, Rз <= 4 Ом.

Расчет заземляющего устройства осуществляют исходя из его максимально допустимого сопротивления, установленного для соответствующего оборудования.

В электроустановках напряжением до 1000 В в сети с заземленной нейтралью сопротивление заземляющего устройства должно быть не более 10 Ом в любое время года, то есть Ом (согласно ПУЭ).

Так как естественный заземлитель отсутствует (не предусмотрен заданием), то предусматривается искусственный заземлитель, сопротивление которого

Ом.

Определим расчетное удельное сопротивление

, (7.1)

где - удельное сопротивление грунта, Ом*м, - климатический коэффициент (выбирается из справочника в соответствии с климатическими условиями отдельных зон).

Выбираем тип грунта - суглинок с сопротивлением Ом*м, а климатический коэффициент в соответствии с нашей зоной . Тогда расчетное удельное сопротивление будет определено:

Ом*м.

Выберем тип заземлителя и его размеры. Искусственный заземлитель относится к типу трубчатый или стержневой длиной м и диаметром м. Расстояние от заземлителя до поверхности земли в расчетах примем равным м.

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

, (7.2)

где (м) - расстояние от поверхности земли до средины заземлителя.

Используя выше приведенные данные, получим:

(Ом)

Количество параллельно соединенных одиночных заземлителей, необходимых для получения допустимого значения сопротивления заземления, без учета сопротивления полосы соединения, будет составлять:

, (7.3)

где - коэффициент использования группового заземлителя.

Согласно справочным данным, количество параллельно соединенных одиночных заземлителей должно быть не меньше двух. Так как мы рассчитываем одиночное заземление, то из справочных таблиц выбираем .

Тогда .

Длина полосы соединения определяется как:

, (7.4)

где м - расстояние между вертикальными заземлителями.

Соответственно м. Рассчитаем сопротивление полосы соединения, используя формулу:

, (7.5)

где - эквивалентный диаметр соединительной полосы шириной .

В расчетах примем при см.

Тогда (Ом).

Исходя из найденных значений, можно рассчитать сопротивление всего заземляющего устройства с учетом соединительной полосы:

, (7.6)

где - коэффициент использования соединительной полосы, выбирается из справочника и в соответствии с заданными условиями имеет значение .

(Ом).

Таким образом, сопротивление растекания группового искусственного заземлителя меньше заданного (10 Ом), что удовлетворяет безопасности защитного заземления.

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

Для защиты персонала ИВЦ от статического электричества необходимо:

1) использовать нейтрализаторы и увлажнители;

) полы должны иметь антистатическое покрытие, например, однослойный поливинилхлоридный антистатический линолеум;

) протирать экран и рабочее место специальной антистатической салфеткой или смоченной тканью.

.4 Обеспечение экологической безопасности функционирования проектируемого объекта

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

) ингредиентное загрязнение как совокупность веществ, количественно или качественно чуждых естественным биогеоценозам;

) параметрическое загрязнение, связанное с изменением качественных параметров окружающей среды (уровня шума, освещенности, радиации и т.д.);

) биоценотическое загрязнение, заключающееся в воздействии на состав и структуру популяции живых организмов;

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

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

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

Однако, значительная часть эксплуатируемых мониторов персональных компьютеров не соответствует современным гигиеническим требованиям по энергетическим характеристикам электромагнитного поля и предопределяет необходимость защиты пользователя и окружающих, поскольку излучение распространяется по всем направлениям в радиусе 2,5 м.

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

Список использованной литературы

1 <http://www.opengl.org> - Официальный сайт открытой графической библиотеки OpenGL.

2 http://www.microsoft.com/downloads/ru-ru/details.aspx?familyid=2da43d 38-db71-4c1b-bc6a-9b6652cd92a3#QuickDetails <http://www.microsoft.com/downloads/ru-ru/details.aspx?familyid=2da43d%2038-db71-4c1b-bc6a-9b6652cd92a3> - Описание технологии DIrectX.

3 http://merlin.fit.vutbr.cz/upload/IvProjects/2006/3ds2iv/3ds2iv.pdf - Спецификация 3DS формата.

<http://www.martinreddy.net/gfx/3d/OBJ.spec> - Спецификация Obj формата.

<http://code.google.com/p/lib3ds/> - Официальный сайт библиотеки Lib3DS.

Библиотека 3DSFTK устарела и не имеет поддержки в интернете.

<http://www.w3.org/XML> - Спецификация формата XML.

Боресков А. В. Б82 Графика трехмерной компьютерной игры на основе OpenGL. - М.: ДИАЛОГ-МИФИ, 2004. - 384 с.

Хилл Ф. Х45 OpenGL. Программирование компьютерной графики. Для профессионалов. - СПб.: Питер, 2002. - 1088 с.: ил.

Автоматизированная система генерации приложений, использующих библиотеку OpenGL

Автоматизированная система генерации приложений, использующих библиотеку OpenGL

ВВЕДЕНИЕ

. ПРЕДПРОЕКТНЫЕ ИССЛЕДОВАНИЯ

.1 Описание предметной области задачи автоматизации

.2 Анализ прототипов системы

.3 Обоснование выбора технической платформы разрабатываемой системы

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

.5 Задачи выпускной работы

. АНАЛИЗ ЗАДАЧИ

.1 Анализ автоматизированной системы

.1.1 Анализ первого уровня детализации задачи

.1.2 Анализ второго уровня детализации задачи

.1.3 Анализ третьего уровня детализации задачи

.2 Анализ шаблона графического приложения

.2.1 Анализ первого уровня детализации задачи

.1.2 Анализ второго уровня детализации задачи

. РАЗРАБОТКА АЛГОРИТМОВ РЕШЕНИЯ ЗАДАЧИ

.1 Автоматизированная система генерации приложений

.1.1 Алгоритм решения задачи “Ввод данных”

.1.2 Алгоритм решения задачи “Конвертация файла”

.1.3 Алгоритм решения задачи “Генерация шаблона”

.2 Шаблон графического приложения

.2.1 Алгоритм решения задачи “Инициализация OpenGL”

.2.2 Алгоритм решения задачи “Загрузка 3D файла”

.2.3 Алгоритм решения задачи “Вывод 3D файла на экран”

. СИНТЕЗ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

.1 Архитектура программного обеспечения

.2 Информационное пространство системы

.3 Интерфейс пользователя

. ТЕСТИРОВАНИЕ СИСТЕМЫ

. ОЦЕНКА ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ПРИМЕНЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ОПРЕДЕЛЕНИЕ ЕГО ЦЕНЫ

.1 Порядок расчета и анализа экономической эффективности

.2 Расчет экономической эффективности применения программного обеспечения и определение его цены

. ОХРАНА ТРУДА

.1 Характеристика рабочего места

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

.3 Разработка мероприятий по предотвращению или ослаблению возможного воздействия опасных и вредных эксплуатационных факторов на работающих

.4 Обеспечение экологической безопасности функционирования проектируемого объекта

Список использованной литературы

ВВЕДЕНИЕ

6. Оценка экономической эффективности применения программного обеспечения и определение его цены

.1 Порядок расчета и анализа экономической эффективности

6.2 Расчет экономической эффективности применения программного обеспечения и определение его цены

7. Охрана труда

7.1 Характеристика рабочего места

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

7.3 Разработка мероприятий по предотвращению или ослаблению возможного воздействия опасных и вредных эксплуатационных факторов на работающих

.4 Обеспечение экологической безопасности функционирования проектируемого объекта

Список использованной литературы

Похожие работы на - Автоматизированная система генерации приложений, использующих библиотеку OpenGL