Создание трехмерной сцены

Создание трехмерной сцены

ВВЕДЕНИЕ

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

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

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

•    анализ методов визуализация трехмерных сцен;

•        анализ решений для управления компьютерами по сети;

•        проектирование и моделирование работы сервера;

•        проектирование базы данных системы;

•        проектирование веб - сайта на языке php;

•        анализ методов интегрирования системы;

•        разработка и тестирование системы.

Объектом исследования является визуализация и взаимодействие трехмерных агентов по сети. Предметом исследования является визуализация и взаимодействие трехмерных агентов.

. РАЗРАБОТКА И АНАЛИЗ ТРЕБОВАНИЙ

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

1.1 Описание и анализ предметной области

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1.1 Графические агенты

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

алгоритм шифрование визуализация трёхмерный

1.2 Обзор существующих аналогичных систем

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

1.2.1 GLScene

Графический движок для создания кросс-платформенных приложений на языках программирования Delphi, Free Pascal и C++, использующий библиотеку OpenGL в качестве интерфейса программирования приложений. GLScene является свободным программным обеспечением и распространяется с лицензией Mozilla Public License. С его помощью программирование трёхмерной графики в Windows становится более простым и быстрым. Последние версии движка также доступны в среде программирования Lazarus для создания приложений для Linux и др.операционных систем.

Разработка данного движка началась в 1999 году Майком Лишке, а с версии 0.5 была выложена с открытым исходным кодом GLScene позволяет программистам создавать 3D-объекты OpenGL в design-time с использованием интерфейса, показанного на картинке. Большое количество объектов и дополнительных визуальных компонентов VCL помогает программистам создавать мощные 3D-приложения для Delphi, C++ Builder и Lazarus. Загружаемые форматы файлов моделей: 3ds, obj, vrml, smd, md2, md3, nmf, oct, lwo, b3d, gl2, gls, ms3d, Nurbs, lod, и некоторые другие. Сохраняемые форматы файлов моделей: glsm, obj и smd.

Поддерживаемая физика: ODE, Newton Game Dynamics. Также есть небольшой собственный движок расчёта столкновений с учётом законов сохранения импульса DCE.

Рис. 1.1. «GLScene»

1.2.2 Stellarium

Stellarium - свободный виртуальный планетарий, с открытым исходным кодом, доступный в соответствии с GNU General Public License для платформ Linux, Mac OS X, Microsoft Windows, Symbian, Android и iOS (в последних трех как Stellarium Mobile). Начиная с версии 0.10.0 программа использует технологии OpenGL и Qt (до версии 0.10.0 использовались технологии OpenGL и SDL), чтобы создавать реалистичное небо в режиме реального времени. Со Stellarium возможно увидеть то, что можно видеть средним и даже крупным телескопом. Также программа предоставляет наблюдения за солнечными затмениями и движением комет.создан французским программистом Фабианом Шеро, который запустил проект летом 2001 года. Другие видные разработчики включают Роберта Спирмана, Джохэйннса Гадждозика, Мэтью Гейтса, Тимоти Ривза, Богдана Маринова и Джохана Меериса, который является ответственным за художественные работы.

Рис. 1.2 «The Mana World»

1.2.3 Stellarium

Stellarium - свободный виртуальный планетарий, с открытым исходным кодом, доступный в соответствии с GNU General Public License для платформ Linux, Mac OS X, Microsoft Windows, Symbian, Android и iOS (в последних трех как Stellarium Mobile). Начиная с версии 0.10.0 программа использует технологии OpenGL и Qt, чтобы создавать реалистичное небо в режиме реального времени. Со Stellarium возможно увидеть то, что можно видеть средним и даже крупным телескопом. Также программа предоставляет наблюдения за солнечными затмениями и движением комет.создан французским программистом Фабианом Шеро, который запустил проект летом 2001 года. Другие видные разработчики включают Роберта Спирмана, Джохэйннса Гадждозика, Мэтью Гейтса, Тимоти Ривза, Богдана Маринова и Джохана Меериса, который является ответственным за художественные работы.

Рис. 1.2. «Stellarium»

1.2.4 Сравнение аналогов

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

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

Таблица 1.1 Сравнительная характеристика программ аналогов

1.3 Функциональная модель разрабатываемой системы

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

Рис. 1.4 Диаграмма вариантов использования

1.4 Функциональные требования

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

1.4.1 Требования к серверной части программы

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

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

•        добавления/удаления/изменения записей о соединениях;

•        защиты информации от несанкционированного доступа;

•        проверка корректности ввода данных;

•        программа работает автономно;

•        наличие интерфейса;

•        добавлена поддержка русского языка.

1.4.2 Требования к клиентской части

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

•        запрос настроек с сервера, строго через определённый промежуток времени;

•        включение и подключение к серверу происходит автоматически;

•        при отсутствие соединения с сервером, не выполняются никакие действия;

•        при подключении к серверу, клиент передает всю актуальную информацию о компьютере зашифрованную с помощью Blowfish алгоритма;

•        поддержка русского языка;

•        наличие интерфейса.

1.4.3 Требование к надежности

Программа должна обеспечивать:

•    ошибки входных данных не должны приводить к некорректной работе или порче информации;

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

•        некорректное завершение работы клиенты не должны приводить к остановки сервера.

1.4.4 Требования к эргономике и технической эстетике

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

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

Вывод

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

·        анализ особенностей средств визуализации трёхмерный объектов;

·        сравнительный анализ систем визуализации трёхмерный объектов;

·        проектирование программного продукта;

·        тестирование и отладка программного продукта.

Объектом исследования является визуализация и взаимодействие трехмерных объектов по сети. Предметом исследования является визуализация и взаимодействие трехмерных объектов.

2. МАТЕМАТИЧЕСКАЯ ЧАСТЬ

В данном разделе будут представлены два алгоритма, первый из которых алгоритм шифрования Blowfish c обратной связью по шифр-тексту, вторым является алгоритм взаимодействия двух и более объектов в трехмерном пространстве.

2.1 Blowfish c обратной связью по шифр-тексту

До появления Blowfish существовавшие алгоритмы были либо запатентованными, либо ненадёжными, а некоторые и вовсе держались в секрете. Алгоритм был разработан в 1993 году Брюсом Шнайером в качестве быстрой и свободной альтернативы устаревшему DES и запатентованному IDEA. По заявлению автора, критериями проектирования Blowfish были:

•    Скорость (шифрование на 32-битных процессорах происходит за 26 тактов);

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

•        Компактность (возможность работать в менее, чем 5 Кбайт памяти);

•        Настраиваемая безопасность (изменяемая длина ключа);

•    Алгоритм представляет собой сеть Фейстеля. Шифрование данных выполняется за 16 раундов, в каждом из которых над левым 32-битным субблоком данных проводятся следующие действия:

•    Значение субблока складывается с ключом i-го раунда Ki операцией XOR, результат операции становится новым значением субблока.;

•        Субблок обрабатывается функцией F (описана ниже), результат обработки накладывается на правый субблок операцией XOR;

•        Субблоки меняются местами во всех раундах, кроме последнего;

•        После 16 раундов выполняется наложение на субблоки еще двух подключей: K17 и K18 складываются операцией XOR с правым и левым субблоками соответственно.

Структура алгоритма представлена на рисунке 3.1.

Рис. 2.1 «Blowfish алгоритм»

Функция F (рис. 2.2.) обрабатывает субблок следующим образом:

1. Входное 32-битное значение делится на четыре фрагмента по 8 бит, каждый из которых прогоняется через одну из таблиц замен S1...S4 с получением четырех 32-битных выходных фрагментов. Таблицы замен содержат по 256 значений по 32 бита, они не являются фиксированными и зависят от ключа шифрования. Принципы их вычисления подробно описаны ниже:

  2. Первые два выходных фрагмента складываются по модулю ;

  3. Результат предыдущего шага складывается операцией XOR с третьим выходным фрагментом;

  4. Выходное значение функции F получается путем сложения результата предыдущего шага с четвертым выходным фрагментом по модулю .

Рис. 2.2 «Функция F алгоритма Blowfish»

Функцию F можно определить так:

(x) = ( (S1(x1) + S2(x2) mod ) (+) S3(x3) ) + S4(x4) mod     (3.1)

где x1...x4 - 8-битные фрагменты входного значения x.

Расшифрование выполняется аналогично шифрованию, но ключи K1...K18 используются в обратном порядке.

2.1.1 Процедура расширения ключа

Задача процедуры расширения ключа состоит в вычислении на основе ключа шифрования значений ключей раунда K1-K18 и таблиц замен S1-S4.

Расширение ключа выполняется в 5 этапов:

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

·        операцией XOR на K1 накладываются первые 32 бита ключа шифрования, на K2 − следующие 32 бита и т. д. - до K18. Если ключ шифрования короче, чем необходимо для наложения на K1...K18, то он накладывается циклически;

·        с использованием полученных ключей раунда и таблиц замен выполняется шифрование алгоритмом Blowfish блока данных, состоящего из 64 нулевых бит. Результат становится новым значением ключей K1 и K2;

·        результат предыдущего этапа снова шифруется алгоритмом Blowfish, в результате получаются новые значения ключей K3 и K4;

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

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

Ниже представлена блок-схема (рис. 3.3.) главной функции программы, которая реализует режим Blowfish обратной связи по шифр-тексту. Так как сам алгоритм кодирования был рассмотрен выше, то на данной схеме он не описан.

Рис. 2.3 «Алгоритма Blowfish с обратной связью по шифр-тексту»

3. ПРОЕКТНАЯ ЧАСТЬ

.1 Архитектура программного продукта

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

•    Выбранная архитектура приложения − «клиент - сервер».

•        Тип приложения - насыщенное клиентское приложение.

Ниже приведена архитектура ПС (рис. 4.1.), опишем взаимодействия происходящие в ней.

•    Клиент совмещен с сервером по сети, использует TCP и UDP протоколы, в зависимости от выбора сети (локальная, либо глобальная).

•        С помощью метода шифрования Blowfish клиент зашифровывает личную информацию и отправляет ее на сервер.

•        После настройки соединения клиент, получает координаты с сервера и визуализирует объект.

•        После клиент отправляет серверу информацию о координатах, анимации и дополнительную информацию.

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

•        После аутентификации, полученные данные необходимо передать на обработку.

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

Рис. 3.1 Архитектура ПС

3.2 Описание средств разработки

.2.1 Описание СУБД

Microsoft SQL Server - система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов - Transact - SQL, создан совместно Microsoft и Sybase. Transact - SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка.

Компоненты SQL Server:

·        компонент Database Engine;

·    службы Reporting Services;

·        службы Analysis Services;

·        службы Notification Services;

·        службы Integration Services;

·        компонент Full - Text Search;

·        компонент репликации;

·        компонент Service Broke.

3.2.2 Язык программирования

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

•    простота;

•        объектная ориентированность;

•        типовая защищенность;

•        скорость разработки;

•        большая популярность среди разработчиков.

С++ предоставляет множество возможностей, некоторые из них:

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

•        согласованный и четко определенный набор базовых типов;

•        автоматическая очистка динамически распределяемой памяти.

3.2.3 Обоснование выбора среды программирования

В качестве инструментальной среды разработки приложений выбрана Microsoft Visual Studio 2012. Среда разработки Visual Studio представляет собой полный набор средств разработки для различного рода приложений. Visual C++ используют единую интегрированную среду разработки (IDE), которая позволяет совместно использовать средства и упрощает создание решений на базе нескольких языков.

Сервер написан на кроссплатформенном инструментарии разработки ПО - Qt5. Отличительная особенность Qt от других библиотек - использование Meta Object Compiler (MOC) - предварительной системы обработки исходного кода. MOC позволяет во много раз увеличить мощь библиотек, вводя такие понятия, как слоты и сигналы. Кроме того, это позволяет сделать код более лаконичным. Утилита MOC ищет в заголовочных файлах на C++ описания классов, содержащие макрос Q_OBJECT, и создаёт дополнительный исходный файл на C++, содержащий метаобъектный код.

3.3 Макет интерфейса

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

Высокая удовлетворенность от работы достигается в случае:

• Прозрачной для пользователя навигации и целевой ориентации в программе;

•        Ясности и четкости понимания пользователем текста. В программе должны быть те слова и графические образы, которые пользователь знает или обязан знать;

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

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

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

•    информативность;

•        эргономичный дизайн;

•        быстрый доступ к основным функциям программного средства.

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

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

•        главное меню программы;

•        рабочая область программы;

•        область дополнительных элементов управления;

•        область вывода служебной информации.

Рис. 3.2 Интерфейс клиентской части

Интерфейс клиента представлен на рис. 4.3. На нем обозначены:

•        область вывода служебной информации;

•        область элементов управления;

Рис. 3.3 Интерфейс серверной части

.4 Модели программы

.4.1 Проектные модели

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

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

На рис. 4.3. рассматриваем диаграмму классов нашей системы, в ней представлены следующие основные классы интерфейса:

•    Класс Director - класс для организации классов. В его конструкторе создается пустой объект. Создается соединение с сервером.

•        Класс Сonnection - класс для создания связи и обмена сообщениями между клиентом и сервером..

•        Класс Cats - класс для создания и управления объектом.

•        Класс Ms3d - класс для отображения объекта и анимации.

•        Класс Qtclass - класс, который содержит инструменты для организации работы сервера, то есть создание связи клиентом и обработка информации.

•        Класс Animate - содержит инструменты для загрузки анимации, и её хранения.

•        Класс MyThread - содержит инструменты распараллеливания потоков.

Рис. 3.3. Диаграмма классов

3.4.2 Модель данных

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

Логический уровень - это абстрактный взгляд на данные, объектами логической модели являются сущности (Entity), атрибуты (Attribute) и отношения между сущностями (Relationship). Логическая модель является универсальной, она не связана с конкретной реализацией СУБД, для атрибутов используются абстрактные типы данных. На этом уровне объекты именуются в соответствии с их реальным содержанием. Логическая модель дает возможность обсуждать структуру данных с экспертами предметной области. Первая нормальная форма требует, чтобы на любом пересечении строки и столбца находилось единственное значение, которое должно быть атомарным. Кроме того, в таблице, удовлетворяющей первой нормальной форме не должно быть повторяющихся групп.

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

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

Ниже рис. 3.4 приведены представления модели данных, как исходные объекты предметной области, так и конечное состояние базы данных.

В качестве конечной базы данных используется MS SQL Server 2012.

Рис. 3.4 Связи таблиц базы данных

Разработанная база данных содержит в себе 6 таблиц.

Таблица model - содержит в себе информацию о агенте (вид, тип, цвет и анимацию).

Таблица color - содержит первый и второй цвет агента.

Таблица type - содержит в себе виды объектов и их скорость.

Таблица userdate - содержит информацию о пользователе, его личную информацию и номер модели.

В таблице vspominfo - содержит в себе вспомогательную информацию, такую как код для шифрования и путь.

Таблица animate - содержит в себе виды анимации и их продолжительность.

3.4.3 Алгоритмическое конструирование

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

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

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

Рис. 3.5 Алгоритм ПС

4. ТЕСТИРОВАНИЕ

4.1 Описание методики тестирования

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

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

4.2 Проверка выполнения функциональных требований

Тест №1. При загрузке главного окна приложения, пользователю предлагаются поля для ввода логина и пароля. Для успешной авторизации нужно ввести верные логин и пароль и нажать кнопку «Вход».

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

Тест №2. Тестирование реакции приложения на попытку выйти за пределы видимости.

Для этого необходимо:

•        С помощью клавиш клавиатуры «A», «S», «W», «D» вывести свою модель вне поля видимости.

Ожидается возврат модели на прежнее место.

Тест №3. Тестирование взаимодействия моделей.

Для этого необходимо:

•        Выбрать модель.

•        Войти в программу.

•        Попробовать пересечь вторую модель.

•        Ожидаемый результат:

•        Возврат модели на прежнее место.

.3 Нагрузочное тестирование

Тест №4. Нагрузка на сервер

Для этого необходимо:

•        Присоединить к серверу четыре клиента.

•        Попробовать подключится пятому.

Ожидаемый результат:

•        Сервер возвратит отказ.

.4 Тестирование в исключительных ситуациях

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

Для этого необходимо:

•    Запустить процесс поиска.

•        Нажать кнопку прерывания незадолго до конца выполнения процесса поиска.

Ожидаемый результат:

•    Процесс завершается.

Вывод

Все тесты прошли успешно, сбоев не обнаружено.

5. БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ

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

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

•        высокие уровни электростатического и электромагнитного излучения, источниками которого являются видеотерминалы.

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

Параметры при работе с видеодисплейными терминалами и персональными компьютерами регламентирует СанПиН 2.2.2/2.4. 1340-03 «Гигиенические требования к персональным электронно-вычислительным машинам и организации работы»; общие рекомендации по электробезопасности, а также особенности воздействия других факторов даны в «Типовой инструкции по охране труда при работе на персональном компьютере» (ТОИ Р-45-084-01).

Цель работы: рассмотреть основные производственные опасные и вредные факторы, воздействующие на программиста.

5.1 Рабочее место

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

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

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

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

•    Недостаточная освещенность рабочего места;

•        Превышающий допустимые нормы шум;

•        Повышенный уровень ионизирующего излучения;

•        Повышенный уровень электромагнитных полей;

•        Повышенный уровень статического электричества;

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

•        Блеклость экрана дисплея.

5.2 Микроклимат помещения

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

По «СанПиНу» помещение с ЭВМ должны иметь и естественное и искусственное освещение. При этом дополнительное искусственное освещение применяется не только в темное, но и в светлое время суток. Искусственное освещение в помещениях эксплуатации ЭВМ должно осуществляться системой общего равномерного освещения. В качестве источников искусственного освещения обычно используются люминесцентные лампы типа ЛБ или ДРЛ, которые попарно объединяются в светильники, которые должны располагаться над рабочими поверхностями равномерно.

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

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

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

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

Таблица 5.1 Параметры микроклимата для помещений

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

Таблица 5.2 Нормы подачи свежего воздуха

5.3 Шум и вибрация

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

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

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

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

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

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

Устройство заземления выполняется в соответствии с требованиями Правилами устройства электроустановок (ПУЭ), ГОСТ 12.1.030-81, ГОСТ Р МЭК 61140-2000.

Заземление следует выполнять:

·        при напряжениях переменного тока 380В и выше и постоянного тока 440В и выше во всех электроустановках;

·        при напряжениях переменного тока выше 42В и постоянного тока выше 110В только в электроустановках, размещённых в помещениях с повышенной опасностью и особо опасных, а также в наружных электроустановках;

В качестве естественных заземлителей могут быть использованы:

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

·        свинцовые оболочки кабелей, проложенных в земле и т. д.

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

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

Вид заземлителя, его размеры и размеры соединительной полосы описаны в табл. 5.3.

Таблица 5.3 Описания заземлителя

Примечание:

·    Диаметр заземлителя d = 0,04 м;

·        Ширина соединительной полосы b = 0,03 м;

·        Допустимое сопротивление системы заземления по ПУЭ Rз.н.= 4 Ом

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

Таблица 5.4 Приближённое значения удельного сопротивления грунта

Определяем значение электрического сопротивления растеканию тока в землю с одиночного заземлителя по формуле (6.1)

где t - расстояние от поверхности грунта до середины заземлителя, которое высчитывается по формуле h + 0,5*l = 0,65 + 0,5 * 2,75 = 2,025.

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

Рассчитаем число заземлителей с учётом коэффициента экранирования

где hэ - коэффициент экранирования, выбираемый в зависимости от вида заземления, числа заземлителей и расстояния a = 5 между соседними заземлителями, он является равным 0,62.

Определяем длину соединительной полосы

= 1,05 n × a = 1,05 * 31 * 5 = 165 (М.)

Рассчитываем значение сопротивления растеканию тока с соединительной полосы.

Рассчитываем полное значение сопротивления системы заземления

где hП - коэффициент экранирования полосы равный 0,32.

Вывод

Можно сделать вывод, что расчет выполнен, верно, так как получено значение меньше ПУЭ RЗ.Н.. В итоге можно сделать вывод, что число заземлителей равно 31 и длина соединительной полосы равна 165 метров.

. ЭКОНОМИЧЕСКАЯ ЧАСТЬ

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

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

6.1 Организационная структура проекта

Организационная структура проекта (OBS) приведена на рис. 7.1.

Рис. 6.1. Организационная структура проекта

6.2 Календарный план проекта

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

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

1)      cбор требований Заказчика к разрабатываемому ПО;

2)      разработка и согласование технического задания;

)        разработка технического проекта;

)        разработка ПО;

)        разработка веб-интерфейса;

)        разработка сайта;

)        разработка пользовательской документации;

)        тестирование ПО;

)        внедрение ПО.

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

Таблица 6.1

Структура общего времени на создание программного продукта

При реализации данного проекта работы выполняются последовательно. Диаграмма Ганта приведена на рис. 6.2.

Рис. 6.2 Табличное представление Диаграммы Ганта

Рис. 6.3 Графическое представление Диаграммы Ганта

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

Таблица 6.2 Трудозатраты членов проектной команды

6.3 Расчёт затрат на разработку продукта

Расчет затрат на создание и внедрение ПО включает следующие составляющие с последующим их графическим представлением в виде круговой диаграммы:

·    заработная плата исполнителей работ по проекту - ЗПосн;

·        дополнительная заработная плата ЗПдоп;

·        заработная плата обслуживающего и административного персонала;

·        отчисления на социальные нужды (страховые взносы) - Нзп;

·        арендные платежи за производственные (офисные) помещения - Апм;

·        амортизация используемых основных средств и нематериальных активов - А;

·        расходы на модернизацию и приобретение основных средств - Рмод;

·        расходы на приобретение необходимого ПО - РПО;

·        расходы на интернет, связь - Ртел;

·        расходы на канцелярские товары и расходные материалы - Рр.м.;

·        прочие расходы - Пр.р..

6.4 Расчёт заработной платы исполнителей работ по созданию программного продукта

Основная ЗП определяется по формуле:

где M - месячная зарплата (руб.), T - общие трудозатраты (чел.-ч), Чр - число рабочих дней в месяц, tр.д. - продолжительность рабочего дня в часах, П - процент премии. В данной работе Чр = 22 день, tр.д.=8ч, П=0.

Значение месячной заработной платы (М), суммарные трудозатраты членов, а также рассчитанная по формуле 6.1 основная заработная плата проектной команды приведены в табл. 6.3.

Таблица 6.3 Основная заработная плата членов проектной команды

Суммарное значение основной заработной платы проектной команды на период реализации проекта составит 45 750 (руб.).

Проект реализуется в небольшой ИТ-компании, где доля вспомогательного и административного персонала по отношению к основному персоналу не велика. Большая часть административного персонала задействована в проектной деятельности в качестве руководителей проекта. Кадровый учет, бухгалтерский и налоговый учет в Компании отдан на аутсорсинг. Затраты на аутсорсинг войдут в прочие расходы. В связи с этим примем заработную плату обслуживающего персонала равной 0 руб.

6.5 Расчёт отчислений на социальные нужды (страховые взносы)

Теперь можно рассчитать величину отчислений на социальные нужды (страховые взносы), которые начисляются на заработную плату и в 2015 г. для организаций, осуществляющих деятельность в области информационных технологий, составляют 14% по выплатам в пределах 624 тыс. руб. Структура отчислений на социальные нужды (страховые взносы) приведена в табл. 6.4.

Таблица 6.4

Структура отчислений на социальные нужды (страховые взносы)

Таким образом, Нзп= 6 405 (руб.).

6.6 Арендные платежи за производственные (офисные) помещения

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

Стоимость аренды составляет 400 руб/м2 в месяц.

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

На каждого члена проектной команды приходится 5,5 м2 арендуемого офисного помещения. На период данного проекта члены проектной команды в других проектах не задействованы.

Исходя из изложенного выше, затраты на аренду помещений, отнесенные на проект составят Апм = 15 400 (руб.).

6.7 Амортизация используемых основных средств и нематериальных активов

При реализации проекта по разработке и внедрению ПО для автоматизации внутри складской логистики задействованы 7 персональных компьютеров в сборе первоначальной стоимостью 25 000 (руб.) каждый.

Срок полезного использования для задействованных в проекте основных средств определен в 3 года. Метод начисления амортизации - линейный.

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

25 000 / 36 = 694,44 (руб.).

Амортизационные отчисления по ОС, относящиеся на проект составят:

 (руб.).

Данное ПО принимается Компанией к учету как расходы будущих периодов со сроком списания 3 года. Метод списания - линейный.

В качестве ОС используется ОС Windows 7 Корпоративная стоимостью 13 000(руб) и свободно распространяемое ПО Linux. В качестве сервера БД используется MS SQL Server стоимостью 30 000(руб) .

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

 (руб.).

Суммарные амортизационные отчисления составят: А=9100руб.

6.8 Расходы на модернизацию и приобретение основных средств

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

6.9 Расходы на приобретение необходимого ПО

При реализации проекта не планируется приобретение ПО.

6.10 Расходы на интернет и связь

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

6.11 Расходы на канцелярские товары и расходные материалы

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

6.12 Прочие расходы

Прочие расходы составляют 30% от суммы следующих элементов структуры затрат: ЗПосн, ЗПдоп, Нзп, Апм, А, Рмод, РПО, Ртел и Рр.м..

Таким образом, Пр.р.= 23 146,5 (руб.).

6.13 Расчёт себестоимости программного продукта

В себестоимость программного продукта входят следующие элементы: ЗПосн, ЗПдоп, Нзп, Апм, А, Рмод, РПО, Ртел, Рр.м. и Пр.р..

Сложив все элементы, можно определить себестоимость программного продукта и услуг по его внедрению: Сп.п.= 100 301,5 (руб.).

Структура себестоимости программного продукта отражена в табл. 7.5. и представлена на рис.7.4.

Таблица 7.5 Структура себестоимости программного продукта

Рис. 6.4 Структура себестоимости программного продукта

ЗАКЛЮЧЕНИЕ

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

В результате выполнения дипломной работы исследована библиотека opengl, рассмотрены загрузки агентов и возможность их взаимодействия; разработан проект qt приложения, содержащий архитектуру, основные диаграммы UML и диаграмму «сущность-связь»; разработано и протестировано интернет приложение. Система состоит из двух приложений, клиентского и серверного. Серверное приложение работает автономно и не имеет интерфейса, клиентское приложение служит для визуализации объектов.

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Бринзаре, Б. Разработка динамических приложений. - М.: Символ - Плюс, 2012. - 336 с.

. Виейра, Р. Программирование баз данных Microsoft SQL Server- М.: «Диалектика», 2007. - С. 832.

. Данилин, А. Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия. - М.: Интернет-университет информационных технологий, 2013. - 504 с.

. Когаловский, М. Р. Энциклопедия технологий баз данных. - М.: Финансы и статистика, 2002. - 800 с.

. Коулс, М. SQL Server 2008: ускоренный курс для профессионалов. - М.: «Вильямс», 201. - С. 768.

. Кузнецов, С. Основы баз данных.- М.: Интернет-университет информационных технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с.

. Марка, Д. А. Методология структурного анализа и проектирования SADT  М.: МетаТехнология, 2003. - 284 с.

. Методология IDEF0 / Стандарт. Русская версия - М.: Метатехнология, 1993. - 107 с.

. Трофимов, С.А. Case - технологии: практическая работа в Rational Rose С.А. Трофимов. - М.: Бином, 2001. - 272 с.

. Фаулер, М. Архитектура корпоративных программных приложений. - М.: Издательский дом «Вильямс», 2006. - 544 с.

. Херн, М. Компьютерная графика и стандарт OpenGL. - М.: Вильямс, 2005. - 1168 с.

. Энджел, Э. Интерактивная компьютерная графика. Вводный курс на базе OpenGL. - М.: Вильямс, 2001. - 592 с.