Министерство образования и науки Российской Федерации Государственное образовательное учреждение высшего профессионального образования ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР) Кафедра компьютерных систем в управлении и проектировании (КСУП) К ЗАЩИТЕ ДОПУСТИТЬ Заведующий кафедрой КСУП д-р техн. наук, проф. ____________ Ю.А.Шурыгин «___» ___________ 2011 ОПТИМИЗАЦИЯ ВЫЧИСЛЕНИЙ НА СЕРВЕРЕ НАГРУЖЕННЫХ ПРИЛОЖЕНИЙ Пояснительная записка к дипломному проекту ФВС ДП.70301 — 01 81 01 СОГЛАСОВАНО Консультант по экономической части Студент гр. 586-1 ст. преподаватель кафедры АОИ ____________ Е. С. Мурзин ______________ Б.А. Рыбалов «____»______________ 2011 г. «____»______________ 2011 г. Консультант по безопасности Руководитель жизнедеятельности инженер кафедры КСУП Ст. преподаватель кафедры РЭТЭМ _____________ А. А. Котов ______________ И. А. Екимова «____»______________ 2011 г. «____»______________ 2011 г. 2011 2 Реферат Пояснительная записка к дипломному проекту ____с., ____ рис., ____ист., ____ табл., ____прил. ВЕБ-СЕРВЕР, SQL, MySQL, Apache, ПОТОК, ТРАЗАКЦИЯ, ЗАПРОС, БРАУЗЕР, CRON, UML. Цель работы — спроектировать и реализовать программный комплекс для обеспечения вычислений на сервере браузерных игр. Детально изучить предметную область технологий и средств оптимизации работы сервера, разработать концепцию равномерного распределения нагрузки на сервер по времени. Реализовать ядро браузерной стратегии и инструменты администрирования игры. Результатом работы является реализация серверной части программной системы, предназначенной для обеспечения работы сервера игр, а так же процессы мониторинга «развития» игроков и анализа данных. Реализация программы выполнена в среде разработки Eclipse и NET Beans. Пояснительная записка к дипломному проекту выполнена в текстовом редакторе Microsoft Word 2007 с использованием Enterprise Architect 7.5, MS Visio, MySQL Workbench 5.2. 3 Abstract Degree thesis includes ___ pages, ___ fig., ___ tab., ___ sources, ___ app. WEB SERVER, SQL, MySQL, Apache, FLOW, TRAZAKTSIYA,, your browser, CRON, UML. The purpose of the work - to design and implement a software system for computing on the server browser games. Detailed study of the subject area of technology and means of optimization of the server, to develop the concept of a uniform distribution of load on the server at the time. Implement the core browserbased strategies and tools to administer the game. Result is the implementation of server-side software system designed to provide the server game, as well as monitoring processes of "development" players, and data analysis. Implementation of the program is executed in the Eclipse development environment and NET Beans. Explanatory note to the diploma project carried out in a text editor, Microsoft Word 2007 using Enterprise Architect 7.5, MS Visio, MySQL Workbench 5.2. 4 Министерство образования и науки Российской Федерации Государственное образовательное учреждение высшего профессионального образования Томский государственный университет систем управления и радиоэлектроники (ТУСУР) Кафедра компьютерных систем в управлении и проектировании (КСУП) УТВЕРЖДАЮ Зав. кафедрой КСУП д-р техн. наук, проф __________Ю.А. Шурыгин «_____» __________ 2009 г. ЗАДАНИЕ на дипломный проект студенту Мурзину Евгению Сергеевичу группа 586-1 факультет Вычислительных Систем 1 Тема работы: Оптимизация вычислений на сервере нагруженных приложений. (утверждена приказом по вузу от 31 мая 2011 № 5908 ) 2 Срок сдачи студентом законченной работы 10.06.2011 3 Исходные данные к работе: — Подробно изучить предметную область и принципы создания вебсерверов; — Изучить стандартную архитектуру клиент-сервер и ее частный случай веб-сервер; — Проанализировать языки программирования на предмет скорости выполнения задач сортировки и выборки из БД; — Провести обзор подходов к построению БД; — Выделить самые ресурсоемкие процессы, проходящие на сервере; 5 — Реализовать ресурсоемкие процессы на выбранном языке программирования 4 Содержание пояснительной записки (перечень подлежащих разработке вопросов): — Описание предметной области; — Анализ и постановка задачи; — Разработка проекта; — Реализация программной системы; — Тестирование; — Вопросы охраны труда и безопасности жизнедеятельности; — Технико-экономическое обоснование; Перечень графического материала (с точным указанием обязательных чертежей): Оптимизация вычислений на сервере нагруженных приложений (презентация в формате MS Power Point) – 00 слайдов. Твердая копия презентации – 4 экземпляра. Задание согласовано: Консультант по вопросам безопасности жизнедеятельности: Екимова И. А., Ст. преподаватель кафедры РЭТЭМ (фамилия, имя, отчество, должность, место работы) «____» ____________ 2011 года _______________ (подпись) Консультант по экономической части работы: Рыбалов Б.А., ст. преподаватель кафедры АОИ, ТУСУР (фамилия, имя, отчество, должность, место работы) «____» ____________ 2011 года _______________ (подпись) 6 Руководитель работы: Котов А. А., инженер кафедры КСУП, ТУСУР (фамилия, имя, отчество, должность, место работы) «____» ____________ 2011 года _______________ (подпись) Задание принял к исполнению: Мурзин Е. С., студент гр. 586-1, КСУП, ТУСУР «____» ____________ 2011 года _______________ (подпись) Содержание 1 Введение ............................................................................................................... 10 2 Описание предметной области........................................................................... 11 2.1 Основные определения ................................................................................ 11 2.2 Основные проблемы создания поддержки работоспособности сервера 12 2.3 Общая схема организации сервера ............................................................. 16 3 Анализ и постановка задачи ............................................................................... 22 3.1 Выбор сервера и СУБД ...................... Ошибка! Закладка не определена. 3.2 Выбор средств разработки для пользовательского интерфейса ............. 22 3.3 Сравнение языков программирования при работе с базой данных ........ 26 4 Разработка проекта .............................................................................................. 28 4.1 Реализация БД .............................................................................................. 28 4.2 Пользовательский интерфейс ..................................................................... 29 4.3 Фоновые расчетные процессы .......... Ошибка! Закладка не определена. 5 Реализация программной системы .................................................................... 32 5.1 БД ......................................................... Ошибка! Закладка не определена. 5.2 Фоновые процессы ............................. Ошибка! Закладка не определена. 5.3 Пользовательский интерфейс ..................................................................... 32 6 Тестирование........................................................................................................ 36 7 Технико-экономическое обоснование проекта ................................................ 40 7.1 Карта описания программного продукта ................................................... 40 7.2 Определение технико-экономических показателей проекта методом функциональных точек ....................................................................................... 42 7.3 Определение договорной цены на создание программной системы ...... 49 ФВС ДП.----- — 01 81 01 Изм. Лист № докум. Разраб. Е. С. Мурзин А. А. Котов Провер. Подпись Дат а Лит. Сервер вычислений Н. Контр. Утверд. Хабибулина Шурыгин Лист 6 Листов --- ТУСУР, ФВС, каф.КСУП, гр.586-1 7.3.1 Определение фонда оплаты труда на разработку и комплексные испытания программной системы .............................................................. 49 7.3.2 Определение фонда оплаты труда на проведение опытной эксплуатации программной системы. ........................................................ 52 7.3.3 Структура договорной цены на программное обеспечение ......... 52 7.4 Резюме ........................................................................................................... 54 8 Безопасность жизнедеятельности ...................................................................... 55 8.1 Анализ опасных и вредных производственных факторов, связанных с эксплуатацией ПЭВМ на рабочем месте........................................................... 55 8.2 Требования безопасности к рабочему месту пользователя электронновычислительной машины (ЭВМ) ....................................................................... 56 8.2.1 Допуск к работе и контроль здоровья ............................................ 56 8.2.2 Требование к ПЭВМ ......................................................................... 56 8.2.3 Требования к помещениям для работы с ПЭВМ........................... 57 8.2.4 Требования к микроклимату............................................................ 58 8.2.5 Требования к уровню шума и вибрации. ....................................... 59 8.2.6 Требования к освещению помещений и рабочих мест с ПЭВМ . 61 8.2.7 Требования к уровням электромагнитных полей на рабочем месте, оборудованным ПЭВМ. ................................................................... 65 8.2.8 Требования к визуальным параметрам ВДТ, контролируемым на рабочем месте. .............................................................................................. 66 8.2.9 Требования к организации и оборудованию рабочих мест с ПЭВМ взрослых пользователей. ................................................................ 67 8.3 Комплекс защитных мероприятий ............................................................. 68 8.3.1 Мероприятия по использованию ПЭВМ ........................................ 68 ФВС ДП.------ — 01 81 01 Изм. Лист № докум. Разраб. Е. С. Мурзин А. А. Котов Провер. Подпись Дат а Лит. Сервер вычислений Н. Контр. Утверд. Хабибулина Шурыгин Лист 7 Листов --- ТУСУР, ФВС, каф.КСУП, гр.586-1 8.3.2 Мероприятия по улучшению микроклимата ................................. 69 8.3.3 Мероприятия по устранению шума ................................................ 69 8.3.4 Мероприятия по снижению пожароопасности в рабочей зоне.... 69 8.3.5 Мероприятия по контролю и гигиенической оценке уровня электромагнитных полей на рабочих местах ............................................ 70 8.3.6 Мероприятия по обеспечению электробезопасности ................... 71 8.4 Инструкция по технике безопасности для пользователей и операторов ЭВМ ...................................................................................................................... 72 8.4.1 Общие требования ............................................................................ 72 8.4.2 Требования безопасности перед началом работы ......................... 72 8.4.3 Требования безопасности во время работы ................................... 73 8.4.4 Требования безопасности в аварийных ситуациях ....................... 74 8.4.5 Требования безопасности по окончании работы........................... 74 8.4.6 Меры оказания первой медицинской помощи при поражении электрическим током ................................................................................... 74 8.4.7 Действия персонала в случае возникновения пожара .................. 76 9 Заключение ........................................................................................................... 77 Список использованных источников ...................................................................... 78 Графический материал: Презентация в формате PowerPoint «Оптимизация вычислений на 20 слайдов сервере нагруженных приложений» Копия презентации 4 экземпляра ФВС ДП.------ — 01 81 01 Изм. Лист № докум. Разраб. Е.С. Мурзин А. А. Котов Провер. Н. Контр. Утверд. Хабибулина Шурыгин Подпись Дат а Лит. Сервер вычислений Лист 8 Листов --- ТУСУР, ФВС, каф.КСУП, гр.586-1 10 1 Введение За последние годы резко увеличилось число пользователей интернет. Все большее количество фирм имеет свои веб-сайты. Проблемой большинства Web проектов зачастую является не возможность выдерживать высокие нагрузки. При неправильном планировании и реализации, каждый проект в последствии сталкивается с проблемой обеспечения работоспособности из-за чрезмерных нагрузок со стороны пользователей. В результате этого компания приходится наращивать серверные мощности, иначе в результате сбоев число пользователей резко сократится. Отдельной категорией являются веб-игры, где зачастую из-за большого количества запросов к базе данных, приходится наращивать серверные мощности. Зачастую в данной ситуации не помогает даже распределение баз данных и прочие способы оптимизации работы сервера. На данный момент нет общего подхода к оптимизации работы сервера с нагруженными приложениями, некоторые подходы оптимизируют серверную часть и настройки программного обеспечения, другие обеспечивают оптимизацию баз данных и пользовательских запросов. В данном проекте реализована программная часть браузерной игры. В нее входит ядро, выполняющее расчеты и обработку данных полученных от пользователя, а так же некоторые фоновые процессы, необходимые для реализации логики самой игры. В проекте разработаны подходы к распределению нагрузки на сервер по времени. Использование других языков программирования, нежели PHP или иной стандартный язык для вебразработок, для производительности, некоторых а задач использование дает ощутимый параллельных выигрыш вычислений в дает огромный выигрыш в скорости исполнения, что положительно сказывается на работе сервера вследствие уменьшения задержки ответа пользователю. 11 2 Описание предметной области 2.1 Основные определения Web-сервером называют программу, которая принимает HTTP-запросы, обрабатывает их и выдает ответ. Запросы идентифицируются с помощью URL (адреса ресурса в Интернете). Ответ может быть взят из статического файла (статика), сформирован в результате выполнения какой-либо программы (динамика обычно используются скриптовые языки программирования типа php или perl), либо получен в результате запроса к другому web-серверу (проксирование). Обычно перед формированием ответа веб-сервер проверяет права доступа к данному ресурсу, а после формирования ответа делает запись в протокол запросов или лог-файл. Наиболее популярными web-серверами являются Apache и IIS, на сайтах с большой посещаемостью часто используются "быстрые" web-серверы lighttpd или nginx. Иногда термином "web-сервер" называют компьютер, на котором запущена такая программа. Apache - это полнофункциональный, полностью поддерживающий протокол расширяемый HTTP/1.1 веб-сервер, и распространяющийся с открытым исходным кодом. Сервер может работать практически на всемх распространенных платформах. Существуют готовые исполняемые файлы сервера для Windows NT, Windows 9x, OS/2, Netware 5.x и нескольких UNIXсистем. При этом он очень прост в установке и конфигурации. В этом вы сможете убедиться несколько позднее. MySQL - сервер баз данных. MySQL характеризуется большой скоростью, устойчивостью и легкостью в использовании, является идеальным решением для малых и средних приложений. 12 2.2 Основные проблемы поддержки работоспособности сервера базы данных Проблемой большинства web-проектов зачастую является не возможность выдерживать высокие нагрузки. зачастую узким местом в современных приложениях является БД. Проблемы с ней делятся, как правило, на два класса: производительность и необходимость хранения большого количества данных. Отдельной категорией являются браузерные игры, где зачастую из-за большого количества запросов к базе данных, приходится наращивать серверные мощности. Не старайтесь поместить в базы данных всю информацию, которая у Вас есть. Например, не нужно хранить там картинки, хоть MySQL это и позволяет. Помещая в базу данных двоичные образы графических файлов, Вы только замедлите работу своего сервера. Прочитать файл с картинкой с диска гораздо проще и, с точки зрения потребляемых ресурсов, экономичнее, нежели соединиться из скрипта к SQL, сделать запрос, получить образ, обработать его и, выдав нужные http-заголовки, показать посетителю веб-сервера. Во втором случае операция выдачи картинки потребует в несколько раз больше ресурсов процессора, памяти и диска. Также стоит помнить о том, что существуют механизмы кэширования веб-документов, которые позволяют пользователю экономить на трафике, а при динамической генерации контента Вы фактически лишаете своих посетителей этой удобной возможности. Вместо картинок лучше хранить в MySQL информацию, на основе которой можно генерировать ссылки на статические картинки в динамически создаваемых скриптами документах. В ситуациях, когда реально требуется получить только определенную порцию данных из MySQL, можно использовать ключ LIMIT для функции SELECT. Это полезно, когда, например, нужно показать результаты поиска чего-либо в базе данных. Допустим, в базе есть список товаров, которые предлагает Ваш интернет-магазин. Выдавать весь список товаров в нужной 13 категории несколько негуманно по отношению к пользователю - каналы связи с интернет не у всех быстрые и выдача лишних ста килобайт информации зачастую заставляет пользователей провести не одну минуту в ожидании результатов загрузки страницы. В таких ситуациях информацию выдают порциями по, допустим, 10 позиций. Неправильно делать выборку из базы всей информации и фильтрацию вывода скриптом. Гораздо оптимальнее будет сделать запрос вида select good, price from books limit 20,10 В результате, MySQL "отдаст" Вам 10 записей из базы начиная с 20-й позиции. Выдав результат пользователю, сделайте ссылки "Следующие 10 товаров", в качестве параметра передав скрипту следующую позицию, с которой будет делаться вывод списка товаров, и используйте это число при генерации запроса к MySQL. Также следует помнить, что при составлении запросов к базе данных (SQL queries) следует запрашивать только ту информацию, которая Вам реально нужна. Например, если в базе 10 полей, а в данный момент реально требуется получить только два из них, вместо запроса select * from table_name используйте конструкцию вида select field1, field2 from table_name Таким образом, Вы не будете нагружать MySQL ненужной работой, занимать лишнюю память и совершать дополнительные дисковые операции. Также следует использовать ключ WHERE там, где нужно получать информацию, попадающую под определенный шаблон. Например, если нужно получить из базы поля с названиями книг, автором которых является Иванов, следует использовать конструкцию вида select title from books where author='Иванов' Также есть ключ LIKE, который позволяет искать поля, значения которых "похожи" на заданный шаблон : select title from books where author like 'Иванов%' 14 В данном случае MySQL выдаст названия книг, значения поля author у которых начинаются с 'Иванов'. Вместе с тем следует помнить, что существуют операции, выполнение которых само по себе требует больших ресурсов, чем для обычных запросов. Например, использование операции DISTINCT к функции SELECT вызывает потребление гораздо большего количества процессорного времени, чем обычный SELECT. DISTINCT пытается искать уникальные значения, зачастую производя множество сравнений, подстановок и расчетов. Причем, чем больше становится объем данных, к которому применяется DISTINCT (ведь Ваша база со временем растет), тем медленее будет выполняться такой запрос и рост ресурсов, требуемых для выполнения такой функции, будет происходить не прямо пропорцонально объему хранимых и обрабатываемых данных, а гораздо быстрее. Индексы используют для более быстрого поиска по значению одного из полей. Если индекс не создается, то MySQL осуществляет последовательный просмотр всех полей с самой первой записи до самой последней, осуществляя сопоставление выбранного значения с исходным. Чем больше таблица и чем больше в ней полей, тем дольше осуществляется выборка. Если же у данной таблицы существует индекс для рассматриваемого столбца, то MySQL сможет сделать быстрое позиционирование к физическому расположению данных без необходимости осуществлять полный просмотр таблицы. Например, если таблица состоит из 1000 строк, то скорость поиска будет как минимум в 100 раз быстрее. Эта скорость будет еще выше, если есть необходимость обратиться сразу ко всем 1000 столбцам, т.к. в этом случае не происходит затрат времени на позиционирование жесткого диска. В каких ситуациях создание индекса целесообразно: Быстрый поиск строк при использовании конструкции WHERE Поиск строк из других таблиц при выполнении объединения Поиск значения MIN() или MAX() для проиндексированного поля 15 Сортировка или группировка таблицы в случае, если используется проиндексированное поле В некоторых случаях полностью теряется необходимость обращаться к файлу данных. Если все используемые поля для некоторой таблицы цифровые и формируют левосторонний индекс для некоторого ключа, то значения могут быть возвращены полностью из индексного дерева с намного большей скоростью. SELECT Если * выполняются FROM tbl_name запросы WHERE col1=val1 AND вида col2=val2; и существует смешанный индекс для полей col1 и col2, то данные будут возвращены напрямую. Если же созданы отдельные индексы для col1 и для col2, то оптимизатор попробует найти наиболее ограниченный индекс путем определения того, какой из индексов может найти меньше строк, и будет использовать этот индекс для получения данных. Если у таблицы есть смешанный индекс, то будет использоваться любое левостороннее совпадение с существующим индексом. Например, если есть смешанный индекс 3-х полей (col1, col2, col3), то индексный поиск можно осуществлять по полям (col1), (col1, col2) и (col1, col2, col3). Как известно, для работы с MySQL-сервером необходимо предварительно установить с ним соединение, предъявив логин и пароль. Процесс установки соединения может продолжаться гораздо большее время, нежели непосредственная обработка запроса к базе после установки соединения. Следуя логике, надо избегать лишних соединений к базе, не отсоединяясь от нее там, где это можно сделать, если в дальнейшем планируется продолжить работу с SQL-сервером. Например, если Ваш скрипт установил соединение к базе, сделал выборку данных для анализа, не нужно закрывать соединение к базе, если в процессе работы этого же скрипта Вы планируете результаты анализа поместить в базу. Также можно поддерживать так называемое persistent (постоянное) соединение к базе, но это возможно в полном объеме при использовании более 16 сложных сред программирования, чем php или perl в обычном CGI-режиме, когда интерпретатор соответствующего языка разово запускается веб-сервером для выполнения пришедшего запроса. 2.3 Общее описание архитектуры клиент-сервер Итак, поговорим, наконец, о том, что же все-таки такое клиент-сервер. Строго говоря, следует отличать технологию клиент-сервер в широком смысле, которая может быть использована в любых компьютерных системах от собственно архитектуры клиент-сервер применительно к информационным приложениям вообще и автоматизированным системам управления предприятием особенно. Согласно онлайновому словарю компьютерных терминов, клиент-сервер - это вид распределенной системы, в которой есть сервер, выполняющий запросы клиента, причем сервер и клиент общаются между собой с использованием того или иного протокола. Под клиентом понимается программа, использующая ресурсы, а под сервером (по английски - слуга) программа, обслуживающая запросы клиентов на получение ресурсов определенного вида. Столь широкое определение включает в себя практически любую программную технологию, в которой участвуют больше одной программы, функции между которыми распределены асимметрично. Соответственно, говорят о технологии КС применителько к операционным системам, локальным и глобальным сетям и т. д. Такое широкое определение рождает некоторую путаницу. Так, файлсерверная система тоже использует технологию клиент-сервер, однако с точки зрения архитектуры прикладных программ важным является то, какого рода ресурсы сервер предоставляет клиентам. Понятие архитектуры клиент-сервер в системах управления предприятием связано с делением любой прикладной программы на три основных компонента или слоя. Этими тремя компонентами являются: 17 компонент представления (визуализации) данных; компонент прикладной логики; компонент управления базой данных. Действительно, любая программа, компьютеризирующая выполнение той или иной прикладной задачи, должна обмениваться информацией с пользователем, осуществлять собственно обработку этой информации в рамках автоматизации того или иного бизнес-процесса, и, наконец, хранить данные используемые в программе, на том или ином постоянном носителе. Для локальных приложений, полностью работающих на ПЭВМ (например, Word или Excel), все эти компоненты собраны вместе и не могут быть распределены между различными компьютеры. Такая программа является монолитной и использует для выполнения ресурсы только того компьютера, на котором выполняется. В файл-серверных приложениях часть компоненты хранения переносится на файловый сервер, однако, все манипуляции со структурами данных выполняются на клиентской машине, и код пользовательской программы тоже работает только на ней. Критерием, позволяющим отнести прикладную программы к архитектуре клиент-сервер является то, что хотя бы один из трех ее компонентов полностью выполняется на другом компьютере, и взаимодействие между компонентами на разных компьютерах осуществляется через ту или иную сетевую среду посредством передачи запросов на получение того или иного ресурса. Поскольку архитектура клиент-сервер является частным случаем технологии клиент-сервер, в ней обязательно есть клиент и сервер. Соответственно, выделяют клиентскую и серверную стороны приложения. Клиентская сторона приложения функционирует на рабочем месте пользователя, в роли которого в подавляющем числе случаев выступает персональный компьютер. Серверная сторона функционирует на специализированном комплексе, включающем в себя мощные аппаратные 18 средства, требуемый набор стандартного программного обеспечения, систему управления базами данных и собственно структуры данных. Взаимодействие клиентской и серверной частей приложения осуществляется через сеть - локальную или глобальную. При этом с точки зрения клиента и сервера взаимодействие осуществляется прозрачно, соответственно сетевой компонент здесь включает в себя совокупность необходимого сетевого оборудования, набор программных технологий, обеспечивающих передачу данных между узлами сети, а также собственно протокол или протоколы для обмена запросами и результатами их выполнения. Компонент визуализации прикладной задачи осуществляет ввод информации пользователем с помощью тех или иных средств, а также вывод информации на экран и печать. Компонент визуализации для архитектуры клиент-сервер всегда исполняется на рабочем месте пользователя (поскольку должен же он наблюдать какие-либо результаты работы программы). Компонент прикладной логики решает собственно ту или иную задачу, связанную с обработкой данных в той или иной предметной области. Этот компонент может быть распределен между клиентской и серверной частью различным образом в зависимости от применяемой модели. Компонент хранения базы данных осуществляет физические операции, связанные с хранением данных, чтением информации из БД и записью в нее. В архитектуре клиент-сервер этот компонент всегда выполняется на сервере. С точки зрения количества составных частей клиент-серверные системы делятся на двухуровневые и трехуровневые. Двухуровневые системы состоят только из клиента и сервера. В трехуровневых же между пользовательским клиентом и сервером, осуществляющим хранение и обработку базы данных появляется третий, промежуточный слой, являющийся для пользователя сервером, а для системы управления базами данных - клиентом. Такая архитектура позволяет более гибко распределять функции системы и нагрузку между компонентами программно-аппаратного комплекса, а также может снизить требования к ресурсам рабочих мест пользователей. Необходимой 19 платой за это является то, что подобные системы намного сложнее в разработке, внедрении и эксплуатации и требуют значительных затрат и высококвалифицированного персонала. В третьей части рассмотрен пример трехзвенной структуры Baikonur Server. В архитектуре клиент-сервер выделяются несколько различных моделей приложения, в зависимости от распределения компонентов приложения между клиентской и серверной частями. Исторически самой первой была разработана модель сервера удаленного доступа к данным. В этой модели серверная часть осуществляет только хранение данных, а всю прикладную логику реализует клиентская часть. При этом клиент будет передавать серверу запросы на получение данных, а сервер возвращать клиенту те или иные выборки. Самым распространенным средством общения между клиентом и сервером в этом случае является SQL (структурированный язык запросов) - стандартный непроцедурный язык, ориентированный на обработку данных. В модели сервера удаленного доступа к данным на стороне сервера не исполняется никакой прикладной части системы, что может повлечь за собой недогрузку сервера и перегрузку клиента. Поэтому впоследствии была предложена, а затем реализована архитектура сервера базы данных. В ней часть прикладной логики реализуется на сервере, при помощи специального языка программирования, а часть - на клиенте. Это стало возможным благодаря росту производительности серверов современных СУБД. По сравнению с вариантом сервера удаленного доступа к данным, в данном случае несколько уменьшается нагрузка на клиентскую часть, интенсивность сетевого обмена данными, а также в ряде случаев упрощается структура приложения. В настоящее время этот вариант построения систем является самым распространенным. Еще одним вариантом архитектуры клиент-сервер является сервер приложений. В данном случае клиент выполняет только операции визуализации и ввода данных, а всю прикладную логику реализует сервер. Обмен между клиентом и сервером в таких системах осуществляется на уровне 20 команд вывода данных на экран и результатов пользовательского ввода. Наиболее ярким примером данной архитектуры является хорошо известный веб-браузер. Чаще всего, в модели сервера приложений компоненты прикладной логики и управления данными реализуются раздельно. Архитектуру сервера приложений часто называют так называемым "тонким" клиентом, в отличие от традиционного "толстого" клиента, реализуемого в архитектуре сервера баз данных. "Тонкий" клиент является вариантом, который может быть использован, когда ресурсов, доступных на рабочих местах пользователей, недостаточно для исполнения логики приложения. Кроме того, эта технология позволяет сократить расходы на эксплуатацию клиентских компонент системы за счет их сильного упрощения. Сервер — это программа, представляющая какие-то услуги другим программам. Примеры серверов — вебсервер Apache, серверы баз данных — MySQL, ORACLE, сетевые файловые системы и принтера Windows. Клиент — это программа, использующая услугу, представляемую программой сервера. Примеры клиентов —MSIE (MS Internet Explorer), клиент ICQ. Часто люди клиентом или сервером просто называют компьютер, на котором работает какая-то из этих программ. В сущности клиент и сервер — это роли, исполняемые программами. Клиенты и сервера физически могут находиться на одном компютере. Одна и та же программа может быть и клиентом, и сервером одновременно, итд… это только роли. Если проводить аналогию с обществом — банк или магазин — «сервера». Они представляют какие-то услуги своим клиентам. Но банк может в то же время быть клиентом какой-то другой фирмы итд… Архитектура и термин «клиент-сервер» впервые использовались в начале 80-тых годов. Первые приложения с архитектурой «клиент-сервер» были базы данных. 21 До этого не было ясного разделения — программа обычно всё делала сама — в том числе работала с данными в файловой системе, представлением данных пользователю и др. Со временем рос обьем и критичность данных для бизнеса, и это со временем начало породить проблемы (быстродействия, безопасности и другие). Тогда придумали, что удобно поставить базу данных на мощном отдельном компютере (сервере) и разрешить эту базу данных использовать многим пользователям малого компютера (клиентам) через сеть. Так и сделали. По существу «взрыв» популярности технологии «клиент-сервер» был вызван изобретением фирмой IBM простого языка запросов к реляционным базам данных SQL (Structured Query Language). Сегодня SQL всеобщий стандарт работы с базами данных. В последнее время этот «взрыв» продолжает изобретение Интернета, в котором буквально происходит по архитектуре «клиент-сервер». каждое взаимодействие 22 3 Анализ и постановка задачи 3.1 Выбор средств разработки для пользовательского интерфейса Что такое пользовательский интерфейс? По логике вещей, это то с чем мы сталкиваемся каждый день в повседневной жизни: столовые приборы, дверные ручки, пульты управления телевизором и т.д. Сложилось так, что в мире информационных технологий пользовательский интерфейс, прежде всего, ассоциируется с GUI операционной системы. Это неудивительно, ведь ныне элементы управления компьютерными программами нам столь же привычны, как и тумблеры бытовых электроприборов. Пользовательские интерфейсы неотъемлемая часть любого веб-приложения. Любой сайт, к которому мы можем обратиться посредством Интернет, является пользовательским интерфейсом для доступа к информации. Однако в настоящее время задача программирование пользовательских интерфейсов для веб несколько иное, нежели в случае настольных программ. Современная операционная система базируется на устоявшемся стандарте пользовательского интерфейса для всех, взаимодействующих с нею программ. Соответственно имеется определенная модель, которой подчиняются любые интерфейсные решения в программах для данной операционной системы. А раз так, то создание пользовательского интерфейса сводиться к использованию функций стандартных библиотек. Например, это могут быть функции Win32 API или объекты MFC для программ MS Windows. Подобный подход имеет одно замечательное свойство. Если пользователь научился пользоваться хотя бы одной программой, он быстро освоится с любой другой для той же операционной системы. Но такое положение вещей не может быть отнесено к веб-приложениям. Каждый новый сайт – это новый информационный и графический дизайн, а также новый пользовательский интерфейс. В данном случае едва ли применимы программные библиотеки для какого-то одного определенного стандарта пользовательского интерфейса. И до сих пор чаще всего при разработке сайтов используется «ручное» программирование, что подразумевает внесистемное 23 задание оформления и программных реакций, для каждого элемента пользовательского интерфейса и для каждого его состояния. В случае крупного полнофункционального решения подобный подход означает «начало конца». Но давайте обратимся к существующим и перспективным стандартам в области описания пользовательских интерфейсов. PHP (Hypertext Preprocessor - Препроцессор Гипертекста)– это широко используемый язык сценариев общего назначения с открытым исходным кодом. PHP - язык программирования, специально разработанный для написания web-приложений (скриптов, сценариев), исполняющихся на Webсервере. Синтаксис языка во многом основывается на синтаксисе C, Java и Perl. Он очень похож на С и на Perl, поэтому для профессионального программиста не составит труда его изучить. С другой стороны, язык PHP проще, чем C, и его может освоить веб-мастер, не знающий пока других языков программирования. Огромным плюсом PHP, в отличие от, например, JavaScript, является то, что PHP-скрипты выполняются на стороне сервера. PHP не зависит от скорости компьютера пользователя или его браузера, он полностью работает на сервере. Пользователь даже может не знать, получает ли он обычный HTML-файл или результат выполнения скрипта. Сценарии на языке PHP могут исполняться на сервере в виде отдельных файлов, а могут интегрироваться в html страницы. PHP способен генерировать и преобразовывать не только HTML документы, но и изображения разных форматов - JPEG, GIF, PNG, файлы PDF и FLASH. PHP способен формировать данные в любом текстовом формате, включая XHTML и XML. PHP - кроссплатформенная технология. Дистрибутив PHP доступен для большинства операционных систем, включая Linux, многие модификации Unix, Microsoft Windows, Mac OS и многих других. PHP поддерживается на большинстве вебсерверов, таких, как Apache, Microsoft Internet Information Server (IIS), Microsoft Personal Web Server и других. 24 Для большинства серверов PHP поставляется в 2-х вариантах - в качестве модуля и в качестве CGI препроцессора. PHP поддерживает работу с ODBC и большое количество баз данных: MySQL, MSQL, Oracle, PostgreSQL, SQLite и др. Язык программирования PHP, особенно в связке с популярнейшей базой данных MySQL - оптимальный вариант для создания интернет-сайтов различной сложности. После определения пути реализации системы необходимо разработать структурную схему программы. При разработке максимально проектированию. структурной использовать схемы программы объектно-ориентированный Объектно-ориентированное необходимо подход проектирование — к это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы. В качестве инструмента проектирования будет использоваться язык моделирования UML (Unified Modeling Language — унифицированный язык моделировании), предназначенный для визуализации, специфицирования, конструирования и документирования программных систем. Выразительных средств этого языка в совокупности с мощными механизмами расширения достаточно для того, чтобы описать любую программную систему со всех точек зрения, актуальных на различных этапах жизненного цикла. UML позволяет разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и др.) и больше сконцентрироваться на проектировании и архитектуре. Основные преимущества использования языка моделирования UML: UML – объектно-ориентированный язык, в результате чего методы описания результатов анализа и проектирования семантически близки к 25 методам программирования на современных объектно-ориентированных языках; UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы; диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом; UML получил широкое распространение и динамично развивается, он облегчает процесс проектирования и реализацию программ. По завершению этапа проектирования, необходимо будет приступить к разработке непосредственно самого пользовательского интерфейса (ПИ). ПИ является одним из важнейших конкурентных преимуществ любого программного продукта. ПИ является прослойкой, связующим звеном между человеком и программной начинкой продукта, через него конечный пользователь взаимодействует с продуктом [8]. При проектировании ПИ необходимо учитывать следующие основные принципы: удобство для пользователя; интуитивность; логичность; наличие информативной обратной связи; совместное наращивание функциональности – возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса; масштабируемость – возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, рабочих мест, объема и характеристик данных; адаптивность к действиям пользователя – приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства) и многовариативность доступа к прикладным функциям («иконки», «горячие клавиши», меню и т.д.), кроме того 26 программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации; независимость в ресурсах – для создания пользовательского интерфейса должны предоставляться отдельные ресурсы, направленные на хранение и обработку данных, необходимых для поддержки пользователя (пользовательские словари, контекстно-зависимые списки и прочее) [9]. После завершения этапа проектирования необходимо приступить к реализации непосредственно всех необходимых механизмов в спроектированной структуре. Для этого необходимо сгенерировать каркасный код по UML диаграмме классов (эта возможность реализована в среде проектирования UML Enterprise Architect 7.5 компании Sparx Systems), а затем приступить к его наполнению функциональным кодом. 3.2 Сравнение скорости языков программирования. Вопрос производительности (скорости работы) различных языков часто возникает в процессе работы. Встречаются статьи, в которых авторы приводят примеры, где выигрывает реализация на том или ином языке. Для тестирования производительности была напиан простейшая программа. Алгоритм синтетический, долгий, двухуровневый цикл и в нём вычисление математического выражения. Таким образом, оценивается вычислительная производительность самого языка (интерпретатора или скомпилированного кода), никаких привязок к качеству реализации тех или иных библиотек, никаких внешних сервисов, никаких системозависимых операций (диск, сеть, графика). Тесты запускались по 5 раз минимум, чтобы избежать случайных всплесков. Результаты тестирования программирования представлены в таблице 3.1. производительности языков 27 Таблица 3.1 – Соотношение производительности языков программирования. Java - C++, - Язык Java Время исполнения, сек 5,3 2,8 8,5 2,6 Производительность, % 160 303 100 327 server C++ O2 Python Python Perl 2.6 3.1 5.8 62 91 145 91 14 9 6 9 PHP В строке «Производительность» за норму взята скорость исполнения кода, написанного на С++. По результатам тестирования было принято решение реализовать фоновые вычислительные процессы на языке С++. 28 4 Разработка проекта 4.1 Проектирование БД Перед созданием базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, определить все необходимые источники информации для удовлетворения предполагаемых запросов пользователя и определить потребности в обработке данных. На основе такого описания на этапе проектирования базы данных определяется состав и структура данных предметной области, которые должны находиться в БД и обеспечивать выполнение необходимых запросов и задач пользователя. Структура данных предметной области может отображаться информационно-логической моделью. На основе этой модели легко создается реляционная база данных. При разработке модели данных могут использоваться два подхода. В первом подходе сначала определяются основные задачи, для решения которых строится база, выявляются потребности задач в данных и, соответственно, определяются состав и структура информационных объектов. При втором подходе сразу устанавливаются типовые объекты предметной области. Наиболее рационально сочетание обоих подходов. Это связано с тем, что на начальном этапе, как правило, нет исчерпывающих сведений обо всех задачах. В процессе разработки модели данных необходимо выделить информационные объекты, соответствующие требованиям нормализации данных, и определить связи между ними. Эта модель позволяет создать реляционную базу данных без дублирования, в которой обеспечивается однократный ввод данных при первоначальной загрузке и корректировках, а также целостность данных при внесении изменений. При определении логической структуры реляционной базы данных на основе модели каждый информационный объект адекватно отображается реляционной таблицей, а связи между таблицами соответствуют связям между 29 информационными объектами. Далее мы более подробно рассмотрим взаимосвязи между информационными объектами, т.е. таблицами. В результате анализа предметной области и задач, выполняемых на сервере, была спроектирована логическая модель для будущей базы данных (см. рисунок 4.1). Рисунок 4.1 – Логическая модель базы данных. На рисунке представлено шесть таблиц, на основе реализации которых, будет работать расчетное ядро программы. 4.2 Пользовательский интерфейс В качестве среды разработки приложения была выбрана среда проектирования Eclipce. Язык разработки – C++ и PHP. Такой выбор 30 объясняется, прежде всего, значительным преимуществом в скорости исполнения программного кода. Для того чтобы приступить к реализации задуманной системы, необходимо детально проработать её структуру, что позволит ускорить процесс её релизации. Изначально были проанализированы задачи, решаемые будущей программной системой. В результате анализа была получена UML-диаграмма вариантов использования (Use case), представленная в приложении А. На этой диаграмме представлены все возможные варианты использования проектируемой системы со стороны внешнего по отношению к системе пользователя. Структуру приложения планируется построить на основе классического в области проектировании пользовательских приложений шаблона проектирования Model-View-Controller. Веб-программирование как нельзя лучше отображает суть данного шаблона проектирования. Один и тот же набор данных может иметь несколько различных способов отображения. Данные не зависят от способов отображения, способ отображения зависит от структуры хранения данных. пользовательского Контроллер интерфейса осуществляет и обеспечивает обработку событий взаимодействие с пользователем. Общая схема шаблона MVC в виде UML-диаграммы пакетов представлена на рисунке 4.2. Рисунок 4.2 — Структура MVC-приложения 31 На основе описанной выше структуре будут выделены три модуля будущей программной системы: — модуль работы с базой данных – загрузка, модификация и анализ данных о пользователях данных; — расчётное ядро – структура виртуального тура, установка свойств отображения панорам, обеспечение внедрения эффектов интерактивности и др.; — каркас интерфейса пользователя – пользовательский интерфейс, построенный на библиотеке jQuwery обеспечивающей создаваемому приложению современный удобный интерфейс при относительно небольших трудозатратах разработчиков; UML-диаграмма приложении Б. классов модуля расчётного ядра приведена в 32 5 Реализация программной системы 5.1 Реализация базы данных На основе спроектированной логической модели базы данных была разработана и реализована физическая модель БД ( см. рисунок 5.1). Рисунок 5.1 – Физическая модель базы данных 5.2 Пользовательский интерфейс Пользовательский интерфейс представлен в программе в виде вебстраниц, написанных на PHP с использованием технологий Java и библиотекой jQuwery. На рисунке 5.2 представлен интерфейс регистрации в игре. 33 Рисунок 5.2 – Окно регистрации пользователя На рисунке 5.3 представлено основное меню игры. Оно включает в себя пункты, необходимые для управления все процессом игры. Так же обеспечивает навигацию по своим планетам, позволяет осуществлять переписку с игроками и составлять задания для игры. Рисунок 5.3 – Главное меню игры На рисунке 5.4 изображена поверхность пустой планеты с возможными местами для пострек. 34 Рисунок 5.4 – Отображение мест под постройки При выборе места под постройку возникает диалоговое окно, в котором отображены все возможные типы строений на данный момент (см рисунок 5.5) Рисунок 5.5 – Диалог выбора задания для постройки Расположение построек произвольное и зависит только от выбора пользователя. Пример окончательного представлен на рисунке 5.6. вида застроенной поверхности 35 Рисунок 5.6 – Примерный вид построек на планете При выборе уже готового здания слева на экране появляется диалоговое окно, отображающее состояние здания и возможные действия с ним. На рисунке 5.7 изображено окно параметров рудника. Оно отображает параметры здания, его краткое описание и параметры, достижение которых необходимо, чтобы увеличить «уровень» (качество) здания. Рисунок 5.7 – Всплывающее окно состояния постройки 36 6 Тестирование Тестирование пользовательского интерфейса для создания интерактивных виртуальных туров проводилось отдельном сервере, со средним числом пользователей 3000 – 4000 в сутки. При посещении главной страницы, сайт выдает предложение авторизироваться или пройти регистрацию (см рисунок 6.1). Рисунок 6.1 - Анкета регистрации новых пользователей После загрузки панорамного изображения, главное окно программы выглядит следующим образом (см. рисунок 6.2): 37 Рисунок 6.2 - Главное окно игры с изображение звездной системы игрока На данной странице можно осуществлять навигацию по звездным системам и задавать возможные действия. Так же возможно перемещение между своими планетами, и переход на одну из них. При переходе непосредственно на планету, загружается следующая страница (см. рисунок 6.3) 38 Рисунок 6.3 – Обзор планеты типа «пустыня» На данном рисунке изображена планета типа «пустыня» с текушими зданиями и сооружениями. При выборе здания, слева на странице возникает окно, описывающее его текущее состояние, условия его улучшения и краткое описание назначения постройки. При выборе свободного поля застройки возникает окно со списком зданий, возможных для строительства (см. рисунок 6.4) 39 Рисунок 6.4 – Меню выбора построек на планете типа «Океания» При выборе здания на планете начнется строительство. На месте постройки будет отображаться время до окончания строительства. По результатам тестирования можно cделать вывод, что интерфейс позволяет отображать все необходимые данные и осуществлять интерактивное взаимодействие пользователя с сервером. Время, затрачиваемое на выполнение фоновых процессов, обеспечивающих расчеты в игровом ядре исчисляется секундами, а не минутами, вследствие чего не происходит значимых задержек ответов сервера на запросы пользователя. 40 7 Технико-экономическое обоснование проекта Под технико-экономическим обоснованием стоимости (договорной цены) программной системы будем понимать методику оценивания трудовых, временных и финансовых ресурсов по созданию программной системы, соответствующей требованиям заказчика. В основу определения требуемых объемов ресурсов должны быть положены: совокупность бизнес-процессов, реализуемых в будущей программной системе и их относительная важность (приоритет) для заказчика; требования к функциональной полноте и качеству реализации каждого бизнес-процесса. В качестве основных показателей оценки стоимости программной системы используются: сложность (размеры) программной системы; трудозатраты на разработку; длительность разработки программной системы в целом и ее отдельных этапов; численность и квалификация специалистов, привлекаемых к созданию программной системы; фонд оплаты труда специалистов на создание программной системы в целом и по конкретному этапу жизненного цикла; прочие прямые затраты и накладные расходы, связанные с созданием программной системы. 7.1 Карта описания программного продукта Сервер вычислений для браузерной стратегии – программный комплекс для разбора действий пользователей и обсчета ядра игры. Программный комплекс разработан на кафедре компьютерных систем в управлении и проектировании ТУСУР. Адрес: 634034, г. Томск, ул. Вершинина, 74, корп. ФЭТ ТУСУРа, ауд. 328. тел. (3822) 414-717. 41 ПК «Сервер вычислений для браузерной стратегии» (далее Сервер, ПК) предназначен для расчета процессов, описывающих то или иное взаимодействие между игроками, а так же фоновые процессы протекающие в игре, такие как расчет статистики или «полетов» игроков. Программно-технические средства. Сервер вычислений разработан в среде программирования Eclipce, пользовательский интерфейс в среде NETBeans. Минимальное программно-аппаратное обеспечение: 2.0 GHz CPU, 4048 MB RAM, 12Gb HDD, 64 MB SVGA, Windows Server или Linux, Сервер Apache, MuSQL Server. Работа сервера организована с помощью связки Apache и MySQL, интерфейс представляет собой веб-страницы, написанные на PHP с использованием Java-библиотеки jQuwery. При сопровождении сервера программистам необходимы навыки настройки сервера, знание языков С++ и PHP, а так же опыт работ с базами данных. При игре предполагается, что пользователь знаком в общих чертах со стандартными браузерами и владеет базовыми навыками работы в них и сети интернет. Для размещения игры на сервере программист должен обладать навыками подключения и использования баз данных MYSQL на локальном сервере и умением настраивать домен имен игры. Эффективность использования сервера заключается в: уменьшении объема данных на сервере; уменьшении времени задержки обработки команд пользователя; снижении времени, затрачиваемого на обработку данных. Время отклика сервера на запрос пользователя при условии, что аппаратная конфигурация удовлетворяет рекомендуемым требованиям, не превышает: 1 сек. - при выполнении сохранения точек в файл; 0.05 сек. - при построении одного нагрузочного контура; системным 42 1 сек. - при вызове диалогового окна Модуля. Параметры будут рассчитаны на готовом сервере при 2-3 тысячах пользователей при различной загрузке сервера. Определим технико-экономические показатели (ТЭП) и структуру договорной цены на основании методики, изложенной в [1?].(список литературы пока не готов) 7.2 Определение технико-экономических показателей проекта методом функциональных точек Исходные данные: тип системы: программно-информационная; сложность системы: простая; языки программирования: С++, PHP; плановый срок разработки – 6 месяцев. Декомпозируем программный комплекс до уровня элементарных компонент и для оценки размеров каждой из них используем внешних экспертов (рисунок 7.1). Рисунок 7.1 — Декомпозиция бизнес-процессов Сервера В результате проведенного анализа получаем следующую структуру программных комплексов и компонент (рисунок 7.1). 43 Размеры программной системы (Сервера) оцениваются в терминах количества и сложности бизнес-процессов (функций), реализуемых в данном программном коде. Сервер, с использованием методологии структурного анализа и проектирования описывается в виде многоуровневой графической модели, представленной в виде совокупности пользовательских бизнес-процессов. Каждый из бизнес-процессов включает в себя входные и выходные данные, преобразования, внешние интерфейсы. Процедура оценивания размеров программного комплекса соотносится с одним из пользовательских бизнес-процессов и состоит из следующей последовательности этапов: ввод, вывод, опросы, структуры данных, интерфейсы): выделение множества бизнес-процессов; подсчет количества функциональных точек бизнес-процесса в разрезе каждой категории; определение весовых коэффициентов сложности каждой функции; учет факторов и требований среды разработки программной системы; вычислений интегральных показателей сложности; вычисление итогового количества функциональных точек; определение размеров программного комплекса бизнес-процесса в показателях LOC; определение размеров программной системы в целом. Рассчитаем количество функциональных точек по каждому бизнеспроцессу и заполним соответствующие таблицы. При этом используем весовые коэффициенты сложности выводов, вводов, опросов ввода, опросов вывода, сложности структурных данных (файлов), сложности интерфейсов. 44 Для разрабатываемого ПК «Сервер вычислений» получаем рабочую таблицу определения количества функциональных точек по бизнес-процессу «База данных» (таблица 7.1). Таблица 7.1 - Рабочая таблица определения количества функциональных точек по бизнес-процессу «База данных» База данных Категория функций Простые Средние Сложные Кол-во точек Количество выводов 4*2 0 0 8 Количество вводов 4*2 0 0 8 Количество опросов вывода 0 5*16 0 80 Количество опросов ввода 0 5*24 0 120 7*2 0 0 14 0 0 10*1 10 Количество файлов Количество интерфейсов Количество функциональных точек 240 Аналогичным образом заполняются таблицы по остальным бизнеспроцессам разрабатываемого программного комплекса (см. таблицы 7.2.– 7.5). Таблица 7.2 - Рабочая таблица определения количества функциональных точек по бизнес-процессу «Интерфейс» Интерфейс Категория функций Простые Средние Сложные Кол-во точек Количество выводов 4*8 0 0 32 Количество вводов 4*8 0 0 32 Количество опросов вывода 0 0 0 0 Количество опросов ввода 0 0 0 0 7*4 0 0 28 0 0 0 0 Количество файлов Количество интерфейсов Количество функциональных точек 92 45 Таблица 7.3 - Рабочая таблица определения количества функциональных точек по бизнес-процессу «Расчетное ядро» Расчетное ядро Категория функций Простые Средние Сложные Кол-во точек Количество выводов 0 5*2 7*2 24 Количество вводов 0 5*4 7*10 90 Количество опросов вывода 0 5*2 7*6 52 Количество опросов ввода 0 5*10 7*2 64 Количество файлов 0 0 10*17 170 Количество интерфейсов 0 0 9*11 99 Количество функциональных точек 499 Таблица 7.4 - Рабочая таблица определения количества функциональных точек по бизнес-процессу «Статистика пользователей» Статистика пользователей Категория функций Простые Средние Сложные Кол-во точек Количество выводов 4*1 0 0 4 Количество вводов 4*1 0 0 4 Количество опросов вывода 4*7 0 0 28 Количество опросов ввода 4*2 0 0 8 Количество файлов 3*2 0 0 6 0 0 0 0 Количество интерфейсов Количество функциональных точек 50 Таблица 7.5 - Рабочая таблица определения количества функциональных точек по бизнес-процессу «Обработчик очередей событий» Обработчик очередей событий Категория функций Количество выводов Простые 4*3 Средние 0 Сложные 0 Кол-во точек 12 46 Окончание таблицы 7.5 Обработчик очередей событий Количество вводов 4*5 0 0 20 Количество опросов вывода 0 0 0 0 Количество опросов ввода 0 0 0 0 7*3 0 0 21 0 0 0 0 Количество файлов Количество интерфейсов Количество функциональных точек 53 Общее количество функциональных точек по всем бизнес-процессам составит: F 92 240 499 50 53 934точек (7.1) Следующим этапом определения размерности программной системы является учет факторов и требований среды разработки (конечных пользователей системы), так как от этих факторов зависит сложность предметной области и качество создаваемого программного обеспечения. Влияние этих факторов на размеры программного обеспечения оценивается по ряду показателей. При этом каждый из показателей, в свою очередь, оценивается по пятибалльной шкале измерения (оценка существенности влияния факторов среды). Учитывая вышеизложенное, проводим оценку влияния данных факторов и заполняем таблицу 7.6. Таблица 7.6 - Факторы и требования среды разработки Факторы среды Значение Каналы передачи данных 5 Распределенные вычисления 0 Производительность системы 5 Конфигурирование 1 Частота транзакций 2 Интерактивная разработка 0 Пользовательский интерфейс 5 47 Продолжение таблицы 7.6 Интерактивное обновление БД 3 Сложность обработки запросов 4 Сложность установки ПО 4 Сложность эксплуатации системы 3 Степень распределенности системы 1 Гибкость изменения функций 1 Суммарное значение коэффициентов (N) 34 Рассчитаем влияние факторов внешней среды по формуле 7.2: Z 0.65 0.01 N (7.2) Z 0.65 0.01 39 0.99 где N – суммарное значение весовых коэффициентов факторов внешней среды - 39. Уточненное количество функциональных точек с учетом факторов внешней среды определим по формуле 7.3: R( F ) F Z (7.3) R( F ) 760 1.04 924 Размеры программной системы определяем в виде количества строк исходного кода в терминах Lines of code-LOC. В качестве базового показателя количества строк исходного кода используется число операторов языка ассемблер. Размерность программного обеспечения для конкретного языка программирования определим по формуле 7.4: R( LOC ) R( F ) LOC , где LOC – среднее количество операторов (7.4) конкретного языка программирования, требующегося для реализации одной функциональной точки. Для расчетов в нашем случае используется основной язык программирования – С++. Преобразовав размеры программной системы, 48 написанной на С++, получаем соответствие 6 строк кода ассемблер и 1 строки кода С++, при этом показатель LOC на 1 функциональную точку равен 53. R( LOC ) 924 53 48972строк Оценка трудозатрат проводится с помощью степенной функции вида T A R E (KLOG ) / 12 , (7.5) где T – трудозатраты, выраженные в человеко-месяцах; R (KLOC) размерность программной системы, выраженная в тысячах строк кода. Значения параметров A и E получим из таблицы коэффициентов математической модели оценки трудозатрат на основе базовой модели COCOMO в зависимости от типа программной системы A = 3, E = 1.12. T 3 48.9721.12 / 12 19.53чел месяцев Средняя численность сотрудников, занятых в проекте, составляет Z 19.53 / 6 3.25чел. Таким образом, метод функциональных точек определил следующие основные технико-экономические показатели: 1) трудозатраты на разработку системы составят 19.53 человеко-месяцев; 2) необходимые людские ресурсы = 3.25 чел. Вместе с тем, следует отметить, что используемый метод все-таки недостаточно корректно отражает реальный объем трудозатрат, что объясняется следующей спецификой представленной системы: это Web-приложение, которое содержит более сложную логику взаимодействия с клиентом; система интегрирует сразу несколько технологий, состоит из большого количества файлов; при разработке ПК Сервер использовались несколько языков программирования (С++, PHP, JavaScript, HTML, SQL), а при расчете трудозатрат был выбран только базовый – С++. 49 После расчета технико-экономических показателей проекта выбираем исходные данные (трудозатраты/длительность/средняя численность разработчиков) для определения стоимости (договорной цены) на создание программной системы. 7.3 Определение договорной цены на создание программной системы 7.3.1 Определение фонда оплаты труда на разработку и комплексные испытания программной системы В основу определения фонда оплаты труда положены: длительность реализации каждого этапа жизненного цикла проекта; количество и качественный состав специалистов, привлекаемых на каждом этапе проекта; базовая месячная ставка специалиста-программиста. Выбираем исходные данные, полученные с помощью метода функциональных точек: трудоемкость (Т) = 19.53 чел.-месяцев; длительность (Д) = 6 месяцев. Заполняем таблицу средней численности сотрудников, занятых на каждом из этапов создания ПС, используя статистические данные из таблицы [9.16] и получаем расчетную таблицу 7.7. Выполняем расчет средней численности сотрудников, занятых на каждом из этапов создания ПС. Zi ai * T / i * Д , (7.6) где i=1,4. Следующий шаг - распределение специалистов по этапам жизненного цикла программной системы, при этом численность каждого типа специалистов на каждом из этапов жизненного цикла создания ПС определяется с использованием статистического распределения таблицы [2.17] : Z ij Pij Z i , i 1,4 j 1,3 (7.7) 50 где Pij – относительная доля (%) специалистов J-го типа, привлекаемых для реализации проекта на i-ом этапе. Таблица 7.7 - Распределение трудозатрат и длительности по основным этапам жизненного цикла создания программных систем. Этапы жизненного Трудозатраты Длительность 3,26 0,6 Проектирование 2,39 1,8 Программирование 3,77 2,1 3,58 1,5 цикла Анализ предметной области и разработка требований Тестирование и комплексные испытания Данные заносим в таблицу 7.8: Таблица 7.8 - Численность каждого типа специалистов на каждом из этапов жизненного цикла создания программной системы Типы специалистов (Zij) Этапы жизненного цикла Аналитики Программисты Технические специалисты Анализ предметной 1,3 0,65 1,3 Проектирование 0,84 0,84 0,72 Программирование 0,38 2,45 0,94 Тестирование и 0,54 2,14 0,9 области и разработка требований комплексные испытания Фонд заработной платы для реализации i-го этапа проекта определим по формуле 7.9: 3 S i Z ij Д i S j , i 1,4 j 1 (7.9) 51 где Д i — длительность i-го этапа проекта; S i — месячный фонд заработной платы j-го типа специалиста. Примем размер ставки программиста = 8,5 тысяч рублей, как среднюю ставку программиста на кафедре КСУП ТУСУРа. Соотношение месячной ставки специалиста-программиста к месячной ставке системного аналитика составляет как 1:1,3, а к месячной ставке технического специалиста – как 1:0,7. , то есть: базовая ставка программиста = 8 500 руб. ставка аналитика = 11050 руб. ставка техника = 5950 руб. Общий фонд заработной платы на реализацию проекта определим по формуле 7.13: 4 S Si i 1 (7.10) Далее рассчитаем фонд зарплаты для каждого этапа и общий фонд зарплаты (таблица 7.9). Таблица 7.9 - Распределение фонда заработной платы по этапам жизненного цикла программной системы Этапы жизненного цикла Анализ предметной области и Аналитик Программист Техник ФЗП по этапу 8619 3315 4641 16575 Проектирование 16708 12852 7711 37271 Программирование 8818 43733 11745 64296 8950 27285 8032 44267 разработка требований Тестирование и комплексные испытания Итого общий фонд заработной платы 162409 Таким образом, фонд оплаты труда на разработку и комплексные испытания ПС составляет 162409 руб. 52 7.3.2 Определение фонда оплаты труда на проведение опытной эксплуатации программной системы. Численность сотрудников, привлекаемых к опытной эксплуатации определяется по формуле: Z оп t оп N , (7.11) где t оп — срок опытной эксплуатации. Установим срок опытной эксплуатации по договоренности с Заказчиком – 3 месяца. Норматив трудоемкости при проведении опытной эксплуатации N примем равным 0,0095 чел.-месяцев (когда количество пользователей не ограничено). Таким образом, численность сотрудников, привлекаемых к опытной эксплуатации, составит: Z оп 3 0.0095 0.0285чел. Фонд зарплаты сотрудников, привлекаемых для опытной эксплуатации определяется по формуле: S оп Z оп t оп S n 0.85 (7.12) где S п — месячная базовая ставка программиста. В нашем случае вышеуказанный фонд составит: S оп 0.0285 3 8500 0.85 620 руб. (7.13) Общий фонд зарплаты на разработку и внедрение системы равен 162409 + 620 = 163029 руб. 7.3.3 Структура договорной цены на программное обеспечение Договорная цена (стоимость) на разработку и внедрение программной системы имеет, в основном, типовую структуру. 53 Основополагающим элементом, из которого и будет произведен расчет стоимости проекта, является рассчитанный выше общий фонд заработной платы (163029 руб.). Дальнейшие разделы сметы затрат зависят от формы организации разработчика (государственное предприятие, коммерческое) и соответствующих форм налогообложения ее деятельности. Далее определяем необходимые виды основных расходов, из которых и складывается окончательная смета затрат (коммунальные услуги, прочие расходы, накладные расходы и т.д.). Стоимость приобретенной для выполнения проекта компьютерной техники составляет 25 тыс. рублей, при этом амортизационные отчисления для средств вычислительной техники, согласно действующему законодательству будут производиться в течение пяти лет, а за 6 месяцев, определенных Заказчиком на разработку системы, составят 25000/5*0,5 = 2500 рублей. Далее должны быть предусмотрены расходы на лицензионное программное обеспечение, если его приобретение необходимо для разработки и дальнейшей эксплуатации программного продукта. Процент накладных расходов также не имеет жестких нормативов и зависит от затрат на содержание АУП, бухгалтерии и т.д. в организации. С учетом нормативов составим смету затрат и определим общую стоимость проекта (таблица 7.10). Таблица 7.10 – Смета затрат на разработку и внедрение системы Наименование статей расходов Фонд оплаты труда Сумма (руб.) 163029 Страховые взносы ПФР, ФСС и ФОМС (34%) 55430 Увеличение стоимости основных средств (1 компьютер по цене 25 тыс. рублей) 25 000 Амортизация программно-аппаратного комплекса 2500 54 Продолжение таблицы 7.10 Коммунальные услуги, услуги связи (телефон, Интернет) (250р. * 6 мес.) 1500 Прочие расходы (100р. * 6 мес.) 600 Итого прямые расходы 248059 Накладные расходы (15% от прямых затрат) 37209 Итого договорная цена 285268 Окончательный результат: договорная цена на разработку и внедрение программной системы «Сервер вычислений» составляет: 285268 рублей. 7.4 Резюме Суть проекта состоит в разработке набора программ, объединенных под общим названием «Сервер вычислений» и предназначенных для обеспечения работы браузерной игры. Договорная цена на разработку и внедрение программного комплекса может составить порядка 285,3 тыс. рублей. Разработанный программный продукт носит экспериментальный характер, находится в стадии комплексной отладки и не предназначен для тиражирования, поэтому анализ рыночной стоимости не производился. 55 8 Безопасность жизнедеятельности Полностью безопасных и безвредных производств не существует. Задача охраны труда свести к минимуму вероятность поражения или заболевания работающего с одновременным обеспечением комфорта при максимальной производительности труда. Реальные производственные условия характеризуются, как правило, наличием некоторых опасных и вредных производственных факторов. Охрана труда - система сохранения жизни и здоровья работников в процессе трудовой деятельности, включающие в себя правовые, социальноэкономические, организационно-технические, санитарно-гигиенические, лечебно-профилактические, реабилитационные и иные мероприятия. 8.1 Анализ опасных и вредных производственных факторов, связанных с эксплуатацией ПЭВМ на рабочем месте Опасным называется производственный фактор, воздействие которого на работающего в определенных условиях приводит к травме или другому внезапному резкому ухудшению здоровья. Если же производственный фактор приводит к заболеванию или снижению работоспособности, то его считают вредным (ГОСТ 12.0.002-80). В зависимости от уровня и продолжительности воздействия вредный производственный фактор может стать опасным. В ГОСТ 12.0.003-74* «ССБТ. Опасные и вредные производственные факторы. Классификация» приводится классификация элементов условия труда, выступающих в роли опасных и вредных производственных факторов. Они подразделяются на четыре группы: физические, химические, биологические и психофизиологические. К физическим опасным и вредным производственным факторам относятся: повышенная или пониженная температура воздуха рабочей зоны; повышенные уровни шума, вибрации ультразвука, инфразвуковых колебаний; повышенное или пониженное барометрическое давление и его резкое изменение; 56 повешенная или пониженная влажность, подвижность, ионизация воздуха; повышенный уровень ионизирующих излучений; повышенное значение напряжения в электрической цепи; повышенные уровни статического электричества, электромагнитных излучений; повышенная напряженность электрического, магнитного полей; отсутствие или недостаток естественного света; недостаточная освещенность рабочей зоны; повышенная яркость света; пониженная контрастность; прямая и отраженная блесткость; повышенная пульсация светового потока. К опасным психофизиологическим и вредным производственным факторам относятся физические (статические и динамические) и нервнопсихические перегрузки (умственное перенапряжение, перенапряжение анализаторов, монотонность труда, эмоциональные перегрузки). Один и тот же опасный и вредные производственный фактор по природе своего действия может относиться одновременно к различным группам. 8.2 Требования безопасности к рабочему месту пользователя электронно-вычислительной машины (ЭВМ) 8.2.1 Допуск к работе и контроль здоровья К работе на персональном ЭВМ (ПЭВМ) допускаются лица не моложе 18 лет. Женщинам с момента установления беременности и период кормления ребенка грудью запрещены все виды работ на ПЭВМ и видеодисплейном терминале (ВДТ). Согласно документу Р 2.2.755-99 большинство работ на ПЭВМ отнесены к третьему классу (вредные условия труда). 8.2.2 Требование к ПЭВМ ПЭВМ должны соответствовать требованиям настоящих Санитарных правил и каждый их тип подлежит санитарно-эпидемиологичской экспертизе с оценкой в испытательных лабораториях, аккредитованных в установленном порядке. 57 Конструкция ПЭВМ должны обеспечивать возможность поворота корпуса в горизонтальной и вертикальной плоскости с фиксацией в заданном положении для обеспечения фронтального наблюдения экрана ВДТ. Дизайн ПЭВМ должен предусматривать окраску корпуса в спокойные мягкие тона с диффузным рассеиванием света. Корпус ПЭВМ, клавиатура и другие блоки должны иметь матовую поверхность. Конструкция ВДТ должна предусматривать регулирование яркости и контрастности. 8.2.3 Требования к помещениям для работы с ПЭВМ Помещение для эксплуатации ПЭВМ должно иметь естественное и искусственное освещение. Окна преимущественно должны быть ориентированны на север и северо-восток. Оконные проемы должны быть оборудованы регулируемыми устройствами типа: жалюзи, занавесей, внешних козырьков и др. Площадь на одно рабочее место пользователем ПЭВМ с ВДТ на базе электронно-лучевой трубки (ЭЛТ) должно составлять не менее 6 кв.м. Для внутренней отделки помещения, где расположена ПЭВМ, должны использоваться диффузно отражающие материалы с коэффициентом отражения для потолка – 0,7 – 0,8; для стен – 0,5 – 0,6; для пола – 0,3 – 0,5. Помещение, где размещена ПЭВМ, должно быть оборудовано защитным заземлением (занулением). Не следует размещать рабочие место с ПЭВМ вблизи силовых кабелей и вводов, высоковольтных трансформаторов, технологического оборудования, создающего помехи в работе ПЭВМ. В помещении, оборудованном ПЭВМ, проводится ежедневная влажная уборка и систематическое проветривание после каждого часа работы на ПЭВМ. С целью создания нормальных условий для работающего установлены нормы производственного микроклимата. Температура согласно этим нормам должна поддерживаться равной 20 - 22 °С в холодное и 20 - 25 °С в теплое 58 время года. Относительная влажность должна быть в пределах 40-60%. Система отопления должна обеспечивать постоянное и равномерное нагревание воздуха в холодный период года, а так же безопасность в отношении пожара и взрыва. Скорость движения воздуха не должна превышать 0.2 м/с в холодное время года и 0.5 м/с в теплое. 8.2.4 Требования к микроклимату Под оптимальными микроклиматическими условиями понимают такие сочетания параметров систематическом микроклимата, воздействии на которые человека при детальном обеспечивает и сохранение нормального функционального и теплового состояния организма. При работе с ПЭВМ влажность воздуха в помещении согласно санитарным правилам и нормам СанПиН 2.2.2.542-96 должна быть 40-60%. Понижение влажности вызывает у человека ощущение сухости слизистых оболочек верхних дыхательных путей, ухудшается самочувствие и снижается работоспособность. Температура воздуха не должна превышать в холодное время года 21 — 23 0С, в теплое — 22-24 0С. Таблица 8.1 — Оптимальные параметры микроклимата Сезон Температура воздуха, t, ºС Относительная влажность, % Холодный и переходный (средне суточная температура 22-24 60-40 21-23 60-40 меньше 10 ºС) Теплый (среднесуточная температура воздуха 10 ºС и выше) 59 8.2.5 Требования к уровню шума и вибрации С физиологической точки зрения шумом является всякий нежелательный, неприятный для восприятия человека шум. Шум ухудшает условия труда, оказывая вредное воздействие на организм человека. Согласно ГОСТ 12.1.003-83 «Шум. Общие требования безопасности» уровень шума на рабочем месте инженера – программиста не должен превышать 50 дБ. Требования к электробезопасности на рабочем месте ПЭВМ и ее части согласно ГОСТ 12.1.019 – 79 должны быть выполнены таким образом, чтобы работающие не подвергались опасным и вредным воздействиям электрического тока и электромагнитных полей. В целях безопасности должны обеспечиваться: защитное заземление. Это преднамеренное электрическое соединение с землей или её эквивалентом металлических нетоковедущих частей, которые могут оказаться под напряжением. Защитное действие основано на снижении напряжения прикосновения при переходе напряжения на нетоковедущие части, что достигается уменьшением потенциала корпуса относительно земли, как за счет малого сопротивления заземления, так и за счет повышения потенциала примыкающей к оборудованию поверхности земли. Является эффективной мерой защиты при питании оборудования от трехфазных сетей напряжением до 1000 В с изолированной нейтралью и трехфазных сетей выше 1000 В с любым режимом нейтрали; защитное зануление. Называют преднамеренное электрическое соединение с нулевым защитным проводником металлических нетоковедущих частей, которые могут оказаться под напряжением. Нулевой защитный проводник – это проводник, соединяющий зануляемые части с глухозаземленнной нейтральной точкой обмотки источника тока или ее эквивалентом (ГОСТ 12.1.009-76). Зануление применяется в четырехпроводных сетях напряжением до 1000 В с заземленной нейтралью; 60 защитное отключение. Обеспечивает быстрое, не более 0,2с, автоматическое отключение установки от питающей сети при возникновении в ней опасности поражения током. Такая опасность может возникнуть при замыкании фазы на корпусе электрооборудования, при снижении изоляции фаз относительно земли. При появлении в сети более высокого напряжения, при случайном прикосновении человека к токоведущим элементам, находящимся под напряжением; рабочая изоляция электроустановок. Это электрическая изоляция токоведущих частей электроустановки, обеспечивающая ее нормальную работу и защиту от поражения электрическим током (ГОСТ 12.1.009-76). В процессе эксплуатации электроустановок изоляция подвержена различным повреждениям, а так же старению, в результате чего ухудшаются ее свойства (в основном активное сопротивление); двойная изоляция. Это электрическая изоляция, состоящая из рабочей и дополнительной изоляции. Дополнительная изоляция предусмотрена дополнительно к рабочей для защиты от поражения электрическим током в случае повреждения рабочей изоляции. Может выполняться покрытием металлических конструктивных частей слоем изоляционного материала. Для защиты от поражения электрическим током согласно ГОСТ 12.4.01189 «Средства защиты работающих. Общие требования и классификация» должны быть соблюдены следующие основные виды средств защиты: недоступность токоведущих частей; устройства защиты заземления и зануления сопротивлением Rз=4 корпус компьютера должен быть обязательно заземлен с помощью Ом; медного провода сечением 4 мм2; предохранительные устройства; изолирующие устройства сопротивлением Rиз=500 кОм. Рабочие места должны быть оборудованы отдельными щитами с общим рубильником электропитания, который должен находиться в легкодоступном 61 месте, иметь закрытый зануленный металлический корпус и четкую надпись, указывающую величину номинального напряжения. В соответствии с Правилами устройства электроустановок (ПУЭ) – по степени опасности поражения людей электрическим током помещения делятся на три категории: а) помещения с повышенной опасностью, имеющие один из признаков повышенной опасности: сырости (относительная влажность воздуха длительно превышает 75%), токопроводящей пыли, токопроводящих полов, высокой температуры воздуха, возможности одновременного прикосновения человека к соединенным с землей металлическим конструкциям и к частям, находящимися или могущими оказаться под напряжением; б) помещения особо опасные, характеризующиеся наличием двух признаков повышенной опасности или одного из признаков особой опасности: особой сырости, химически активной среды, действующей разрушающе на изоляцию и токоведущие части электрооборудования; в) помещения отсутствием условий, без повышенной создающих опасности повышенную и характеризующиеся особую опасность. Электроустановки в наружных условиях или под навесами приравниваются к электроустановкам в особо опасных помещениях. 8.2.6 Требования к освещению помещений и рабочих мест с ПЭВМ Освещение рабочего места – важнейший фактор создания нормальных условий труда. Освещению следует уделять особое внимание, так как при работе с монитором наибольшее напряжение получают глаза. При организации освещения необходимо иметь в виду, что увеличение уровня освещенности приводит к уменьшению контрастности изображения на дисплее. В таких случаях выбирают источники общего освещения по их яркости и спектральному составу излучения. 62 Общая чувствительность зрительной системы увеличивается с увеличением уровня освещенности в помещении, но лишь до тех пор, пока увеличение освещенности не приводит к значительному уменьшению контраста. Рекомендуемые соотношения яркостей в поле зрения следующие: между экраном и документом 1:5 - 1:10; между экраном и поверхностью рабочего стола 1:5; между экраном и клавиатурой, а также между клавиатурой и документом - не более 1:3; между экраном и окружающими поверхностями 1:3 - 1:10. Согласно СанПиН 2.2.2/2.4.1340-03 «Гигиенические требования к ПЭВМ и организации работы», необходимо соблюдать нижеследующие требования: Помещения с ПЭВМ должны иметь естественное и искусственное освещение. Естественное освещение должно осуществляться через светопроемы, ориентированные преимущественно на север и северо-восток и обеспечивающие коэффициент естественной освещенности (КЕО) не ниже 1.2%. Искусственное освещение в помещениях эксплуатации ПЭВМ должно осуществляться системой общего равномерного освещения. Освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300 - 500 лк. Допускается установка светильников местного освещения для подсветки документов. Местное освещение не должно создавать бликов на поверхности экрана и увеличивать освещенность экрана более 300 лк. Следует ограничивать прямую блесткость от источников освещения, при этом яркость светящихся поверхностей (окна, светильники и др.), находящихся в поле зрения, должна быть не более 200 кд/кв.м., а также отраженную блесткость на рабочих поверхностях (экран, стол, клавиатура и др.) за счет правильного выбора типов светильников и расположения рабочих мест по 63 отношению к источникам естественного и искусственного освещения. При этом яркость бликов на экране дисплея не должна превышать 40 кд/кв.м и яркость потолка, при применении системы отраженного освещения, не должна превышать 200 кд/кв.м. Для внутренней отделки интерьера помещений с ПЭВМ должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка - 0.7 - 0.8; для стен - 0.5 - 0.6; для пола - 0.3 - 0.5. Показатель ослепленности для источников общего искусственного освещения должен быть не более 25. 8.2.6.1 Расчет искусственного освещения В помещении применяется общее равномерное искусственное освещение, расчет которого производится по методу светового потока. При расчете этим методом учитывается как прямой свет от светильника, так и свет, отраженный от потолка и стен. Согласно СНиП 23-05-95 освещенность рабочего места при комбинированном освещении должна составлять 300 — 500 лк. Помещение кабинета освещается лампами типа ЛБ40 Освещенность определяется по следующей формуле Е = (F*N*)/(S*K*z), (8.1) где F — световой поток каждой из ламп, лм; N — число ламп; — коэффициент использования светового потока; z — коэффициент неравномерности освещения, зависящий от расположения светильников, (z = 1,1); К — коэффициент запаса, (К=1,5); S — площадь помещения, S = А * В = 3*9 = 27 м2. В рабочем помещении установлено 4 светильника по 4 лампы, световой поток каждой из которых 4250 лм. Далее определяем показатель помещения по формуле: 64 i=(a*b)/( НС*(a+b)), (8.2) где a и b — соответственно длина и ширина помещения, м; НС — высота светильников над рабочей поверхностью, м. При a = 3 м, b = 7 м, НC = 3,5 м, получаем: i=(3*7)/(3.5*(3+7)) = 0.3, По найденному показателю помещения i и коэффициентам отражения потолка н и стен а определяем коэффициент использования светового потока (под которым понимается отношение светового потока, падающего на рабочую поверхность, к световому потоку источника света). Для нашего случая = 0.22. Тогда по формуле (8.1) освещенность равна: Е = (4250*16*0.22)/(27*1.5*1.1) =336 Расчет показывает, что освещенность в данном помещении удовлетворяет требованиям. 8.2.6.2 Расчет естественного освещения Расчет и нормирование освещения производится согласно санитарным нормам и правилам (СНиП 23-05-95). Исходные данные для расчета естественного освещения: боковое освещение; габариты кабинета LxDxH=9x3x3.5=94.5 м3 площадь оконного проема S 0 2.5 2 5 м 2 . Требуемая площадь светового проема: L Deh K K 0 З З0 , S 0 min 100 t r 0 1 где, (8.3) 65 h0 — световая характеристика окна, h0=10; e — нормированное значение коэффициента естественного освещения (КЕО); KЗ — коэффициент запаса; KЗ0 — коэффициент, учитывающий затенения окон соседними зданиями, t0 — общий коэффициент светопропускания (0,1÷0,8); r1 — коэффициент, учитывающий повышение КЕО за счет отражения света от поверхности помещения; Коэффициент KЗ определяем из таблиц: KЗ= 1,4. Нормированное значение КЕО, согласно СНиП 23-05-95, примем равным e=1,1%. Коэффициент светопропускания — t0=0,6. Коэффициент, учитывающий затенения окон соседними зданиями KЗ0=1. Коэффициент, учитывающий повышение КЕО за счет отражения света от поверхности помещения r1=1. По формуле (10.3) получаем следующее значение требуемой площади светового проема: S 0 min 9 3 1,1 10 1,4 1 7,7(м 2 ) 100 0,6 1 Учитывая, что в помещении площадь освещением оконным проемом составляет всего около 5,5м2, получаем, что использования лишь естественного освещения в помещении недостаточно. Следовательно, в помещении кроме естественного освещения необходимо использовать искусственное освещение. 8.2.7 Требования к уровням электромагнитных полей на рабочем месте, оборудованным ПЭВМ Временные допустимые уровни ЭМП, создаваемых ПЭВМ на рабочем месте пользователя представлены в таблице 8.2. 66 Таблица 8.2 – Временные допустимые уровни ЭМП, создаваемые ПЭВМ на рабочем месте Наименование параметров ВДУ Напряженность 25 В/м электрического поля в диапазоне частот 5Гц – 2Гц в диапазоне частот 2,5 В/м 2 кГц – 400к Гц Плотность в диапазоне частот магнитного потока 250 нТл 5Гц – 2Гц в диапазоне частот 25 нТл 2 кГц – 400 кГц Напряженность электрического поля 15 В/м 8.2.8 Требования к визуальным параметрам ВДТ, контролируемым на рабочем месте Предельно допустимые значения визуальных параметров ВДТ, контролируемые на рабочем месте, представлены в таблице 8.3. Таблица 8.3 – Визуальные параметры ВДТ, контролируемые на рабочем месте Параметры Допустимые значения 1 Яркость белого поля Не менее 35 кд/кв.м 2 Неравномерность яркости рабочего поля Не более +/- 20% 3 Контрастность (для монохромного режима) Не менее 3:1 4 Временная нестабильность изображения Не должно фиксироваться (мелькания) 5 Пространственная изображения (дрожание) нестабильность Не более 2 х 1Е(-4L), где L – проектное наблюдения, мм расстояние 67 Экран видеомонитора должен находится от глаз пользователя на расстоянии 600 – 700 мм, но не ближе 500 мм с учетом размеров алфавитноцифровых знаков и символов. Конструкция рабочего стола должна обеспечивать оптимальное разрешение на рабочей поверхности используемого оборудования с учетом его количества и конструктивных особенностей, характера выполняемой работы. При этом допускается использование рабочих столов различных конструкций, отвечающих современным требованиям эргономики. Поверхность рабочего стола должна иметь коэффициент отражения 0,5 – 0,7. Рабочий стул (кресло) должен быть подъемно-поворотным, регулируемым по высоте и углам наклона сидения и спинки, а также расстояние спинки от переднего края сидения, при этом регулировка каждого параметра должна быть независимой, легко осуществляемой и иметь надежную фиксацию. Поверхность сидения, спинки и других элементов стула (кресла) должна быть полумягкой, воздухопроницаемым с нескользящим, покрытием, слабо обеспечивающим электризующимся легкую очистку и от загрязнений. 8.2.9 Требования к организации и оборудованию рабочих мест с ПЭВМ взрослых пользователей Высота рабочей поверхности стола для взрослых пользователей должна регулироваться в пределах 680 – 800 мм; при отсутствии такой возможности высота рабочей поверхности стола должна составлять 725 мм. Модульными размерами рабочей поверхности стола для ПЭВМ, на основании которых должны рассчитываться конструктивные размеры, следует считать: ширину 800, 1000, 1200 и 1400 мм, глубину 80U и 1000 мм при нерегулируемой его высоте, равной 725 мм. 68 Рабочий стол должен иметь пространство для ног высотой не менее 600 мм, шириной – не менее 500 мм, глубиной на уровне колен – не менее 450 мм и на уровне вытянутых ног – не менее 650 мм. Конструкция рабочего стула должна обеспечивать: ширину и глубину поверхности сидения не менее 400 мм; поверхность сидения с закругленным переднем краем; регулировку высоты поверхности сидения в пределах 260 – 400 мм и углом наклона вперед 15 градусов, и назад до 5 градусов; высоту опорной поверхности спинки 300 +/- 20 мм, ширину – не менее 380 мм и радиус кривизны горизонтальной плоскости в пределах – 400 мм; внутреннее расстояние между подлокотниками в пределах 350 – 500 мм. Рабочее место пользователя ПЭВМ следует оборудовать подставкой для ног, имеющей ширину не менее 300 мм, глубину не менее 400 мм, регулировку по высоте в пределах до 150 мм по глубине наклон опорной поверхности подставки до 20 градусов. Поверхность подставки должна быть рифленой и иметь по переднему краю бортик высотой 10 мм. Клавиатуру следует располагать на поверхности стола на расстоянии 100 – 300 мм от края, обращенного к пользователю, или на специальной регулируемой по высоте рабочей поверхности, отдельной от основной столешницы. 8.3 Комплекс защитных мероприятий 8.3.1 Мероприятия по использованию ПЭВМ В целях обеспечения требований для дисплеев ПЭВМ, а также защиты от электромагнитных и электростатических полей допускается применение приэкранных фильтров, специальных экранов и других средств 69 индивидуальной защиты, прошедших испытания в аккредитованных лабораториях и имеющих соответствующий гигиенический сертификат. 8.3.2 Мероприятия по улучшению микроклимата Для обеспечения установленных норм микроклиматических параметров и чистоты воздуха в помещении применяют вентиляцию. В холодное время года предусматривается система отопления. Для повышения влажности воздуха в помещении с ПЭВМ следует применять увлажнители воздуха, заправляемые ежедневно прокипяченной питьевой водой. 8.3.3 Мероприятия по устранению шума Снижение шума, создаваемого на рабочих местах внутренними источниками, а также шума, проникающего извне, осуществляется следующими методами: уменьшением шума в источнике; рациональной планировкой помещения. В целях снижения шума в помещении с ПЭВМ используют звукопоглощающие материалы с максимальным и минимальным коэффициентами поглощения в области частот 63-8000 Гц для отделки помещений, подтвержденных специальными акустическими расчетами. Дополнительным звукопоглощением служат однотонные занавески из плотной ткани, гармонизирующие с окраской стен и подвешенные в складку на расстоянии 15-20 см от ограждения. 8.3.4 Мероприятия по снижению пожароопасности в рабочей зоне Противопожарную защиту обеспечивают следующие меры: 70 максимально возможное применение негорючих и трудно горючих материалов; ограничение количества горючих веществ и их надлежащее размещение; предотвращение распространения пожара за пределы очага; применение средств пожаротушения; эвакуация людей; применение средств коллективной и индивидуальной защиты; применение средств пожарной сигнализации. Организационными мероприятиями по обеспечению пожарной безопасности являются обучение людей правилам пожарной безопасности разработка и реализация норм и правил пожарной безопасности, инструкций о порядке работы с пожароопасными материалами, разработка путей эвакуации людей и извещение людей об этом, путем изготовления различных схем, плакатов. Важная мера предусматривающей – организация профилактическое пожарной и охраны оперативное объекта, обслуживание охраняемых объектов. 8.3.5 Мероприятия по контролю и гигиенической оценке уровня электромагнитных полей на рабочих местах Инструментальный контроль электромагнитной обстановки на рабочих местах пользователей ПЭВМ производится: при вводе ПЭВМ в эксплуатацию и организации новых и реорганизации рабочих мест; после проведения организационно-технических направленных на нормализацию электромагнитной обстановки; при аттестации рабочих мест по условиям труда; по заявкам предприятий и организаций. Требования к средствам измерений: мероприятий, 71 инструментальный осуществляться приборами контроль с к уровней допускаемой ЭМП основной должен относительной погрешностью измерений +/- 20%; следует отдавать предпочтение измерителям с изотропными антеннами-преобразователями. Измерение уровней переменных электрических и магнитных полей, статических электрических полей на рабочем месте, оборудованном ПЭВМ, производится на расстоянии 50 см от экрана на трех уровнях на высоте 0,5 м, 1 м, 1,5 м. Гигиеническая оценка результатов измерений должна осуществляться с учетом погрешности используемого средства метрологического контроля. 8.3.6 Мероприятия по обеспечению электробезопасности Основными мероприятиями по защите от электротравматизма являются: обеспечение недоступности токоведущих частей путем использования изоляции; применение устройств защиты заземления и зануления сопротивлением Rз=4 Ом, специальных розеток с заземляющими контактами; использование источников бесперебойного питания; оборудование рабочих мест отдельными щитами с общим рубильником электропитания, который должен находиться в легкодоступном месте, иметь закрытый зануленный металлический корпус и четкую надпись, указывающую величину номинального напряжения. Технические способы и средства применяют раздельно или в сочетании друг с другом так, чтобы обеспечивалась оптимальная защита. 72 8.4 Инструкция по технике безопасности для пользователей и операторов ЭВМ 8.4.1 Общие требования При работе с компьютерным оборудованием работник должен пройти первичный инструктаж по технике безопасности и расписаться в журнале. Перед непосредственной работой с аппаратурой необходимо изучить инструкцию по эксплуатации. К самостоятельной работе с ЭВМ и внешними устройствами ЭВМ допускаются лица, не имеющие медицинских противопоказаний и прошедшие: вводный инструктаж; инструктаж по пожарной безопасности; первичный инструктаж на рабочем месте; обучение безопасным методам труда и стажировку на рабочем месте. Пользователи и операторы ЭВМ должны проходить: повторный инструктаж по безопасности труда на рабочем месте не реже, чем через каждые три месяца; профилактический медицинский осмотр – ежегодно. Женщины со времени установления беременности и в период кормления ребенка грудью к выполнению всех видов работ, связанных с использованием ЭВМ, не допускаются. 8.4.2 Требования безопасности перед началом работы Проверить внешним осмотром и убедиться в исправности соединительных кабелей и шнуров, системного блока, монитора, клавиатуры, внешних устройств ЭВМ. Проверить состояние освещенности рабочего места. Запрещается после включения ЭВМ перемещать системный блок, монитор, внешние устройства ЭВМ, а также производить какой-либо ремонт. 73 8.4.3 Требования безопасности во время работы Штепсельные вилки, разъемы, шнуры и кабели должны быть в полной исправности. Продолжительность непрерывной работы с ЭВМ не должна превышать двух часов. При восьми часовой рабочей смене регламентированные перерывы следует устанавливать через 1.5 – 2 часа от начала работы и через 1.5 – 2 часа после обеденного перерыва продолжительностью 20 минут каждый или по 15 минут через каждый час. Во время работы запрещается: включать и выключать компьютер без необходимости; трогать разъемы соединительных кабелей, проводов, вилки и розетки; прикасаться к экрану и к тыльной стороне блоков компьютера; работать на ПЭВМ мокрыми руками; работать на ПЭВМ, имеющих нарушения целостности корпуса, нарушения изоляции проводов, неисправную индикацию включения питания, с признаками электрического напряжения на корпусе; класть на ПЭВМ посторонние предметы (кружки с жидкостями, жирные предметы, книги и предметы, излучающие электромагнитные поля); вешать что-либо на провода, закрашивать и белить шнуры и провода, закладывать провода и шнуры за газовые и водопроводные трубы, за батареи отопительной системы; техники под напряжением проводить ремонт средств вычислительной и периферийного оборудования; ремонт электроаппаратуры производится только специалистами-техниками с соблюдением необходимых технических требований. В помещениях запрещается: зажигать огонь; 74 хранить огнеопасные вещества; включать электрооборудование, если в помещении пахнет газом; курить; сушить что-либо на отопительных приборах; закрывать вентиляционные отверстия в электроаппаратуре. 8.4.4 Требования безопасности в аварийных ситуациях При обнаружении неисправности работник должен немедленно обесточить электрооборудование, оповестить руководителя. Продолжение работы возможно только после устранения неисправности. 8.4.5 Требования безопасности по окончании работы После окончания рабочего дня необходимо: привести в порядок рабочее место; отключить оборудование; в случае непрерывного производственного процесса необходимо оставить включенными только необходимое оборудование; обо всех неисправностях, замеченных во время работы, сообщить администрации. 8.4.6 Меры оказания первой медицинской помощи при поражении электрическим током При поражении электрическим током необходимо быстро освободить пострадавшего от действия электрического тока (отключить токоведущие части или провода, которых он касается: оторвать от контакта с землей или оттянуть от проводов). 75 Меры первой помощи зависят от состояния пострадавшего после освобождения от тока. Для определения этого состояния необходимо: немедленно уложить пострадавшего на спину; расстегнуть стесняющую дыхание одежду; проверить по подъему грудной клетки, дышит ли он; проверить наличие пульса (на лучевой артерии у запястья или на сонной артерии, на шее); проверить состояние зрачка (узкий или широкий). Широкий неподвижный зрачок указывает на отсутствие кровообращения мозга. Определение состояния пострадавшего должно быть проведено быстро, в течение 15 - 20 секунд. Если пострадавший в сознании, но до того был в обмороке или продолжительное время находился под электрическим шоком, то ему необходимо обеспечить полный покой до прибытия врача и дальнейшее наблюдение в течение 2-3 часов. В случае невозможности быстро вызвать врача необходимо срочно доставить пострадавшего в лечебное учреждение. При тяжелом состоянии или отсутствии сознания нужно вызвать врача (скорую помощь) на место происшествия. Ни в коем случае нельзя позволять пострадавшему двигаться: отсутствие тяжелых симптомов после поражения не исключает возможности последующего ухудшения его состояния. При отсутствии сознания, но сохранившемся дыхании, пострадавшего надо удобно уложить, создать приток свежего воздуха, давать нюхать нашатырный спирт, обрызгивать водой, растирать и согревать тело. Если пострадавший плохо дышит, очень редко, поверхностно или, наоборот, судорожно, как умирающий, надо делать искусственное дыхание. При отсутствии признаков жизни (дыхания, сердцебиения, пульса) нельзя считать пострадавшего мертвым. Смерть впервые минуты после 76 поражения - кажущаяся и обратима при оказании помощи. Пораженному угрожает наступление необратимой смерти в том случае, если ему немедленно не будет оказана помощь в виде искусственного дыхания с одновременным массажем сердца. Это мероприятие необходимо проводить непрерывно на месте происшествия до прибытия врача. Переносить пострадавшего следует только в тех случаях, когда опасность продолжает угрожать пострадавшему или оказывающему помощь. 8.4.7 Действия персонала в случае возникновения пожара При возникновении пожароопасной ситуации или пожара работник должен немедленно оповестить о пожаре руководителя, а также принять необходимые меры для его ликвидации: отключить электропитание на силовом щите; сообщить в МЧС по телефону 01. Далее действовать в соответствии с инструкцией по пожарной безопасности. 77 9 Заключение В результате выполнения данного дипломного проекта была спроектирована и реализована программная система для обеспечения работы браузерной игры «Космос-online». Были разработаны механизмы обеспечения сложных серверных вычислений без заметного снижения производительности. На их основе создана легко наращиваемая библиотека веб-страниц и классов, которые можно легко повторно использовать в разработке других игр при минимальной доводке исходного кода. В результате реализации было создано быстрое и качественное вычислительное ядро для обслуживания процессов протекающих на сервере. Кроме того был проведен анализ возможных подходов в программировании и технологий аппаратного ускорения. На их основе были реализованы фоновые процессы, протекающие на сервере, что обеспечило работу сервера без значительных задержек ответов пользователю даже во время архивации данных, а так же значительно сократило нагрузку во время работы системных процессов. Очевидно, что список функциональных возможностей системы не является полным и будут расширяться в процессе развития возможностей СУБД и языков разработки веб-приложений. В проекте был заложен большой потенциал для дальнейшего развития программной системы. Благодаря методам объектно-ориентированного проектирования была обеспечена гибкость структуры системы, в связи с чем модификация и адаптация к новым требованиям должны быть максимально облегчены. По результатам проделанной работы был сделан доклад на всероссийской научно-технической конференции студентов, аспирантов и молодых учёных — Научная сессия ТУСУР [--]. 78 Список использованных источников 1 GameDev.ru — Разработка игр [ Электронный ресурс ]. – Режим доступа : http://www.gamedev.ru (дата обращения: 12.05.2011) 2 Введение в базы данных [ Электронный ресурс ]. – Режим доступа : http://www.mstu.edu.ru/study/materials/zelenkov/toc.html. 3 Проектирование базы данных [ Электронный ресурс ]. – Режим доступа : http://Wikipedia.org. 4 Блок Хабрахабр [ Электронный ресурс ]. – Режим доступа : http://habrahabr.ru. 5 Официальный сайт разработчиков MySQL [ Электронный ресурс ]. – Режим доступа : http://www.mysql.ru. 6 Буч, Г. Объектно-ориентированное проектирование / Г. Буч ; пер с англ. — М. : Бином, 1998. — 560с. 7 Леоненко, А. В. Самоучитель UML, 2-е изд., перераб. и доп./ А. В Леоненко. – СПб.: БХВ-Петербург, 2006. – 432 с.: ил. 8 Буч, Г. UML. Классика CS. 2-е изд. / Г. Буч, А. Якобсон, Дж. Рамбо. СПб.: Питер, 2006. – 736 с. 9 Рыбалов, Б.А. Технико-экономическое обоснование стоимости программных систем. Методические указания по выполнению экономической части дипломного проекта для студентов специальности 230102 «Автоматизированные системы обработки информации и управления» / Ю.П. Ехлаков, Б.А. Рыбалов. – Томск: ТУСУР, 2011 – 86с. 10 Кодолова, Л.И. Пособие по охране труда. Учебное пособие для дипломников технических специальностей ТУСУРа / Г.В. Смирнов, Л.И. Кодолова. – Томск: ТУСУР, 2007. – 79 с. 11 Мурзин Е.С. Научная сессия ТУСУР-2011: Материалы докладов Всероссийской научно-технической конференции студентов, аспирантов и молодых учёных. Томск, 12-15 мая 2011г./ Мурзин Е. С. — Томск: Изд-во «ВСпектр», 2011. Ч. 2. – С.40-42. 79 Приложение А (справочное) UML диаграмма прецедентов 80 Приложение Б (справочное) UML диаграмма классов
