Пояснительная записка_1

Список использованных нормативных документов ...................................................................... 3
Определения ..................................................................................................................................... 4
Обозначения и сокращения ............................................................................................................. 5
Введение ................................................................................................................................................ 6
Краткое описание предметной области ......................................................................................... 6
Актуальность ...................................................................................................................................... 7
Схемы актуальности .......................................................................................................................... 8
Глава 1. Анализ предметной области ................................................................................................. 9
1.2 Определение учета ..................................................................................................................... 9
1.2 Способы представления информации .................................................................................... 10
1.3 Описание текущих бизнес-процессов ..................................................................................... 11
1.4 Минусы текущего подхода ....................................................................................................... 13
1.5 Обзор аналогов ......................................................................................................................... 14
1.6 Постановка задач ВКР ............................................................................................................... 20
Глава 2. Проектирование системы .................................................................................................... 22
2.1 Общее проектирование системы ............................................................................................ 22
2.2 Клиент-серверное взаимодействие ........................................................................................ 23
2.3 Шаблон Модель-Представление-Контроллер ....................................................................... 24
2.4 Варианты использования системы .......................................................................................... 25
2.5 Диаграмма пакетов ................................................................................................................... 26
2.6 Диаграммы последовательности ............................................................................................ 28
2.7 Выбор платформы и средств реализации .............................................................................. 30
2.8 Выбор базы данных .................................................................................................................. 32
2.9 Структура базы данных ............................................................................................................. 33
2.10 Описание таблиц ..................................................................................................................... 35
Глава 3. Разработка системы.............................................................................................................. 39
3.1 Технологии проекта .................................................................................................................. 39
3.2 Сервер приложений Tomcat..................................................................................................... 40
3.3 Модель данных системы .......................................................................................................... 40
3.4 ORM и Hibernate ........................................................................................................................ 42
3.5 Spring IoC Conteiner ................................................................................................................... 45
3.6 Spring DAO и Spring ORM ........................................................................................................... 46
3.7 Spring MVC.................................................................................................................................. 49
3.8 Spring Sequrity ............................................................................................................................ 51
3.9 Jasper Reports ............................................................................................................................. 53
3.10 Simile Timeline .......................................................................................................................... 54
Глава 4. Экономическое обоснование ВКР ....................................................................................... 57
4.1 Определение товарного типа объекта разработки ............................................................... 57
4.2 Расчет сметы затрат на разработку ......................................................................................... 57
4.2.1 Расчет стоимости расходных материалов ........................................................................... 58
4.2.2 Расчет стоимости специального оборудования и амортизации ....................................... 59
4.2.3 Расчет основной заработной платы разработчиков ........................................................... 60
4.2.4 Расчет дополнительной заработной платы ......................................................................... 61
4.2.5 Расчет единого социального налога .................................................................................... 61
4.2.6 Расчет затрат на электроэнергию для технических целей ................................................. 61
4.2.7 Расчет затрат на контрагентские работы ............................................................................. 62
4.2.8 Расчет затрат на командировки ............................................................................................ 62
4.2.9 Расчет прочих затрат .............................................................................................................. 62
4.2.10 Расчет накладных расходов ................................................................................................ 62
1
4.2.11 Общая сметная стоимость проекта .................................................................................... 63
4.3 Вывод ......................................................................................................................................... 63
Глава 5. Безопасность жизнедеятельности ...................................................................................... 64
5.1 Описание условий эксплуатации проектируемой программы ............................................. 64
5.2 Анализ и выявление потенциально опасных и вредных факторов ..................................... 64
5.2.1 Микроклиматические факторы ............................................................................................ 65
5.2.2 Факторы освещенности ......................................................................................................... 65
5.2.3 Факторы шума ........................................................................................................................ 65
5.2.4 Факторы электромагнитного поля........................................................................................ 66
5.2.5 Микроклимат рабочей зоны ................................................................................................. 67
5.3 Описание мероприятий, обеспечивающих безопасность программы ................................ 67
5.3.1 Освещение рабочей зоны ..................................................................................................... 67
5.3.2 Расчет искусственного освещения........................................................................................ 67
5.3.3 Защита от шума ...................................................................................................................... 68
5.3.4 Защита от повышенного уровня напряженности электромагнитного поля ..................... 69
5.3.5 Организация рабочего места ................................................................................................ 69
5.4 Пожарная безопасность ........................................................................................................... 70
5.4.1 Причины возникновения пожара ......................................................................................... 71
5.4.2 Профилактика возгораний .................................................................................................... 71
Выводы ............................................................................................................................................. 72
2
Список использованных нормативных документов
В настоящей пояснительной записке использованы ссылки на следующие стандарты:
1 ГОСТ 2.105-95 Единая система конструкторской документации. Общие требования к
текстовым документам.
2 ГОСТ 7.1-2003 Система стандартов по информации, библиотечному и издательскому
делу. Библиографическая ссылка. Общие требования и правила составления.
3 ГОСТ 7.32-2001 Система стандартов по информации, библиотечному и издательскому
делу. Отчет по научно-исследовательской работе. Структура и правила оформления.
4 ГОСТ 12.1.003-83 ССБТ Шум. Общие требования безопасности.
5 ГОСТ 12.1.004-91 Пожарная безопасность. Общие требования.
6 ГОСТ 12.1.006-84 Электромагнитные поля радиочастот. Допустимые уровни на
рабочих местах и требования к проведению контроля.
7 ГОСТ 12.1.010-76 Взрывобезопасность. Общие требования.
8 ГОСТ 12.1.005-88 Общие санитарно-гигиенические требования к воздуху рабочей
зоны.
9 ГОСТ Р 50.1.028 -2001 Методология функционального моделирования.
10 СНиП 23-03-2003 Защита от шума.
11 СНиП 23-05-95 Естественное и искусственное освещение.
12 СанПиН 2.2.2/2.4.1340-03 Гигиенические требования к персональным электронновычислительным машинам и организации работы.
3
Определения
В настоящей пояснительной записке применяются следующие термины с
соответствующими определениями:
Сервер/Хост – физическое аппаратное обеспечение, выделенное и/или
специализированное для выполнения на нем сервисного программного обеспечения.
Ресурс/Виртуальная машина – в рамках данной ВКР, программная среда, эмулирующая
работу реального компьютера, имеющая операционную систему, оперативную память, жесткий
диск.
Таймлайн – в рамках данной ВКР, графическая шкала времени, на которой возможно
расположение различных объектов в том или ином промежутке времени.
4
Обозначения и сокращения
В работе использованы следующие сокращения:
ВКР – выпускная квалификационная работа.
ПО – программное обеспечение.
CPU – центральный процессор (англ. central processing unit, CPU).
RAM – оперативная память (англ. random-access memory).
HDD – жесткий диск (англ. hard disk drive).
MVC – шаблон проектирования модель-представление-контроллер.
5
Введение
Краткое описание предметной области
В настоящее время, мир охватила повсеместная информатизация, от самых малых сфер
человеческой деятельности, до eё самых крупных. Разработка ПО стала довольно крупным и
прибыльным бизнесом, во всем мире открываются и создаются все больше и больше фирм по
созданию ПО, чтобы удовлетворить возрастающую потребность в программном обеспечении.
Цикл разработки готового и законченного продукта ПО очень сложный. Люди, играющие,
наверное, самую ключевую роль в этом цикле – это разработчики и программисты. Одним из
главных факторов производительности труда программиста является создание благоприятных
условий для разработки – удобное рабочее место, наличие соответствующей литературы,
наличие хорошего интернет-канала для доступа ко всемирной паутине, производительный
компьютер и необходимое установленное ПО для разработки.
Программисту часто требуется готовый ресурс (виртуальная машина), для процесса
разработки ПО. Он знает какие программные продукты ему необходимы, какой версии, какой
функциональности, каким требованиям они соответствуют. Естественно, он хочет получить
ресурс с уже предустановленным программным обеспечением, чтобы сразу начать выполнять
свою работу. Хочет всегда иметь доступ к этому ресурсу, возможно создавать какие-то события
на нем, управлять им. Встает проблема как программисту получить ресурс, соответствующий его
требованиям.
В компаниях, занимающихся разработкой ПО, всем серверным оборудованием занимается
специальный человек – системный администратор. Администратор должен иметь полное
представление по используемым и не используемым ресурсам компании, распределение их по
отдельным серверам, занятое и свободное дисковое пространство, процессорные мощности. Так
же он должен иметь информацию о пользователях ресурсов – кто использует, под какие нужды и
с какими целями. Также он должен иметь представление о программном обеспечении,
используемом программистами, его версиях.
Администратору часто сложно удерживать все информацию о просьбах, поступивших к
нему, о имеющихся ресурсах компании, о запрошенных ресурсах пользователями, о свободных
ресурсах на том или ином хосте, о тех или иных событиях. Вследствие этого в голове образуется
неразбериха, которая влияет на скорость создания или выделения ресурсов. А что если
системный администратор вдруг поменяется? Новому человеку на этой должности будет очень
сложно вникнуть в имеющуюся инфраструктуру, и таким образом процесс выделения/создания
новых ресурсов может надолго затянуться.
6
Актуальность
Актуальность темы выпускной квалификационной работы можно обусловить
следующими факторами:

современные разработчики для ведения эффективного процесса разработки, должны
работать с готовыми ресурсами, соответствующими всем их требованиям, как по
программной так и по аппаратной части. Перед ними встает проблема быстрого и
эффективного получения необходимых для разработки средств и ресурсов;

у разработчиков должна быть возможность подачи заявок на ресурсы того или иного
вида, с заданными характеристиками, временными рамками и целями использования
ресурса.

зачастую требуется внести те или иные изменения, в готовую конфигурацию –
добавить памяти, установить приложение и т.п. Необходимо решение, которое
позволит быстро сообщить о планируемых изменениях и своевременно уведомить
администратора. Средство коммуникации между пользователями и администратором;

администратору необходимо иметь всю информацию, по имеющимся ресурсам
компании, которые вовлечены в процесс разработки ПО. Иметь возможность общаться
с пользователями эффективным образом. Возможность создавать ресурсы, события,
отслеживать события пользователей;

у администратора должна быть возможность просмотра информации по тому или
иному ресурсу – кем использовался, под какой проект, какой промежуток времени.
Возможность получения данной информации в виде отчета.
Схемы актуальности представлены на рисунках 1 и 2 ниже.
7
Схемы актуальности
1. Повышение
сложности задач
разработчиков
2. Быстрая смена задач
разработчиков
Необходимо предоставлять
разработчикам полностью
сконфигурированное рабочее
место
3. Разграничение прав
доступа к ресурсам
Рисунок 1.
1. Меняющаяся
картина ресурсов
Необходимо эффективно
обслуживать входящие
запросы исходя
из текущей ситуации
2. Множество
поступающих просьб
3. Необходимость
получения актуальной
информации
Рисунок 2.
8
Глава 1. Анализ предметной области
1.2 Определение учета
Как говорит определение, учет – это регистрация и отображение деятельности в
показателях, характеризующих состояние функционирования и его результатов в учетных
документах и базах данных.
Учет бывает разный: бухгалтерский учет, управленческий учет, учет посещаемости в
университете, учет расходных материалов. Термин учет также применим и к компьютерным
ресурсам. Все виды учета преследую одну цель – сбор и отображение информации о некой
системе, в показателях характерных системе, над которой проводится процесс учета. Возможно,
с целью изучения, исследования, прогнозирования и естественно с целью получения информации
о системе.
Любая система учета, прежде всего, должна выдавать точную информацию о системе,
именно точность является, наверно, главным критерием оценки. Исходя из точности показаний
системы учета, часто делаются какие-то выводы и предположения, которые будут верными лишь
в том случае, если они основаны точной информацией.
Другим не менее важным показателем системы, является актуальность предоставляемой
информации. Помимо того, что пользователь данной системы должен видеть постоянно
актуальную информацию, он должен иметь возможность просмотреть/узнать информацию за
некий прошедший промежуток времени.
Полученная информация из системы влияет на некие действия и принятые
решения, поэтому чтобы решения и шаги были верными, информация должна быть актуальной.
От правильно принятых решений зависит многое.
Информационные технологии, как и многие другие сферы бизнеса и деятельности, могут
быть подвергнуты учету. Учитывать тут есть что. Множество компьютеров, программного
обеспечения, орг. техники, сотрудники компаний, партнеры, объемы информации и .т.д.
Как уже говорилось выше, одной из линий учета в IT, могут быть сами компьютеры и
сервера, вообще серверное пространство, его объемы и мощности, время использования,
активность использования и многое другое. Важно понимать, что учет важен для ведения
бизнеса, принятия решений и действий.
9
1.2 Способы представления информации
Помимо самого учета и хранения информации, важной чертой подобного рода систем
является представление информации конечному пользователю. Способы представления
информации бывают разными, вот основные из них:

текст;

видео;

аудио;

графика.
Наиболее распространенный способ – текстовый, именно он является самым простым.
Большинство информации, получаемой нами – это информация из различных текстовых
источников – книги, газеты, журналы, веб-страницы (рисунок 3).
Рисунок 3 – Текстовое представление информации.
Текстовый вариант информации, хоть и является самым распространенным, однако не
является самым эффективным. Куда эффективнее графическое представление информации.
Плюсы данного подхода:

с использованием графических схем можно представить весь проект целиком, увидеть
выбранную проблему «с высоты птичьего полета»;

графика помогает наглядно и понятно для себя и других слушателей (а впоследствии
для реальных учеников) представить структуру проекта;

когда информация представлена графически, легче генерировать новые идеи (а это
полезно и для преподавателя, и для учащихся);

повышается мотивация, окружающим легче воспринимать идеи проекта:
человеческого мозгу всегда нужны графические образы.
10
Чаще всего при представлении информации в графическом виде используют различные
графики и диаграммы, описывающие тот или иной процесс, то или иное состояние какой-либо
сущности (рисунок 4).
Рисунок 4 – Графическое представление информации.
1.3 Описание текущих бизнес-процессов
На настоящее время бизнес-процесс работы организации, занимающейся коммерческой
разработкой программного обеспечения очень сложен. Рассмотрим отдельную его часть, которая
нас интересует, а именно управление и учет информационной инфраструктурой организации,
процесс выделения ресурсов.
Рассмотрим типичную ситуацию. Программистам необходимо реализовывать достаточно
крупный проект, который будет базироваться на современных технологиях и платформах, в
процессе разработки задействована целая команда разработчиков, дизайнеров и тестировщиков.
Чтобы начать процесс разработки, программисту необходимо иметь все предустановленное
программное обеспечение, которое может понадобиться в процессе разработки:

сервер приложений;

СУБД;

среда разработки;

средства сборки проекта;

система контроля версий.
А теперь рассмотрим среднестатистическую клиентскую рабочую станцию:

процессор 2 GHz;

память 2 Gb;

жесткий диск 160 GB.
11
Согласно приведенным цифрам и приведенному списку необходимого программного
обеспечения, можно прийти к выводу, что на рабочей станции программиста, установить и
запустить все необходимое ПО для разработки не представляется возможным. Да и установка
данного списка ПО на каждой машине вообще бессмысленна, так как над проектом трудится
целая команда, которой необходимо иметь общий предмет разработки.
Под данные нужды выделяются специальные сервера, которые обладают гораздо большей
производительность и способны выдерживать гораздо большие нагрузки. Именно на сервер
устанавливается СУБД, к которой может обращаться каждый участник разработки, там же
устанавливается сервер приложений(специальное ПО), на котором будет работать
разрабатываемый продукт и .д. После этого начинается собственно сам процесс разработки.
В первую очередь программист должен решить, что ему необходимо для разработки,
какие системные требования у необходимого ПО, какой по производительности ресурс
необходим, на какой срок. После того как программист все выяснил, ему необходимо попросить
системного администратора выделить необходимые ресурсы. Теперь представим, что контора
большая, в штате около 1000 человек. Как найти в этой толпе людей системного
администратора? На месте ли он? Зачастую разработчики вообще лично не знают системного
администратора. К кому тогда подходить? К начальнику? К коллеге?
Предположим, что программиста нашел администратора и старается изложить ему свои
пожелания и требования. Как он будет их излагать? Если все на словах, то администратор просто
может что-то забыть и упустить. Если писать отдельное письмо, то оно может затерять в сотнях
других писем
Предположим, администратор принял сведения от программиста и хочет выделить ему
необходимые ресурсы. Что начинает делать администратор в первую очередь? Он начинает
перебирать в голове все свои сервера и начинает думать, где бы выделить место. Сколько
выделить? На каком сервере? А сколько на этом сервере свободных ресурсов?
Все эти вопросы могут на неопределенное время оттянуть решение поставленной задачи.
Нет средства, которое могло бы подсказать администратору, где целесообразнее всего
создать запрашиваемый ресурс.
Например, администратор знает, что есть сервер со следующей конфигурацией.
CPU 8 GHz, RAM 8 GB, HDD 750 GB
Пришла администратору заявка на создание очередной виртуальной машины,
необходимой для процесса разработки, конфигурация следующая:
CPU 1.2 GHz, RAM 2 GB, HDD 160 GB
12
Также администратор знает, что на этом сервере крутятся несколько виртуальных машин с
конфигурациями
CPU 1.6 GHz, RAM 1 GB, HDD 50 GB
CPU 2.8 GHz, RAM 4 GB, HDD 400 GB
CPU 2.0 GHz, RAM 2 GB, HDD 100 GB
Администратор начинает высчитывать.
CPU: 8 – (1.6 + 2.8 + 2.0) = 1.6 GHz свободно > заявленных 1.2 GHz. Подходит.
HDD: 750 – (50 + 400 + 100) = 200 GB свободно > запрошенных 160 GB. Подходит.
RAM: 8 – ( 1 + 4 + 2) = 1 GB свободно < запрошенных 2 GB. Не подходит.
В итоге администратор приходит к выводу, что на данном сервере не разместить
запрашиваемую виртуальную машину. Начинаются обсчеты следующего сервера. А на сервере
может быть расположено гораздо больше трех виртуальных машин. Представьте как тогда может
затянуться процесс, в процессе которого могут быть совершены ошибки.
Предположим администратор выделил программисту необходимый ресурс, и теперь ему
необходимо просмотреть текущую ситуацию по всем ресурсам – кому выделено, под какие
нужды, на какой срок и т.д. Администратор начинает смотреть все сервера, все виртуальные
машины, начинает что-то высчитывать, составлять какие-то таблицы. В итоге в голове каша.
1.4 Минусы текущего подхода

проблемы коммуникации;

проблема отсутствия единого реестра ресурсов;

проблема представления информации;

проблема доступа.
13
1.5 Обзор аналогов
phpMyInventory - http://phpmyinventory.sourceforge.net/index.php
Программа представляет из себя веб-приложение, которое призвано отслеживать все ваши
системы, программное обеспечение и периферию. Системы включают в себя компьютеры,
сервера, ноутбуки, принтеры и так далее. Для работы приложения необходима платформа с PHP
4, СУБД MySql и веб-сервером Apache.
Приложение предоставляет простое меню, для доступа к основным функциям. Каждый
пункт меню представлен отдельной веб-страницей. Присутствует управление пользователями,
которых создает администратор системы и на которых сам же назначает созданные ресурсы.
Также имеются различные формы для создания различного рода систем – рабочих станций,
периферии, программного обеспечения и т.д. Вся информация в системе представлена в виде
таблиц.
Рисунок 5 – Интерфейсы программы phpMyInventory.
Плюсы:

гибкая система прав. Например, вы можете дать пользователя права только
просматривать информацию, или просматривать и обновлять, просматривать и
удалять;

система учета лицензий. Вы можете соотнести количество имеющихся лицензий на
компьютерах пользователей, с количество имеющихся лицензий. Система
предупредит вас, когда число свободных лицензий будет приближаться к нулю;
14

свободная система с открытым исходным кодом.
Минусы:

нет возможности регистрации пользователей в системе;

нет возможности подавать заявки;

представление информации в не самом лучшем виде;

нет возможности взаимодействия пользователей;

нет общего представления информации по всем ресурсам.
GLPI - http://www.glpi-project.org/
GLPI – это информационная система для учета ресурсов. Вы можете использовать ее для
построения базы данных компьютерных ресурсов компании (компьютеры, программное
обеспечение, принтеры и т.д) Приложение имеет широкий функционал, чтобы облегчить
повседневную работу системного администратора, такой как система учета работ, с
уведомлениям от системы, различные методы построения информационной базы ресурсов.
Помимо точного учета ресурсов, приложение способно принимать заявки различного рода от
пользователей, отправляя их техническим специалистам. Заявки обладают разным приоритетом,
который выставляет администратор/технический специалиста. Приоритет в дальнейшем будет
выделен характерным цветом.
Представление информации в основном табличное. Имеется множество форм для
занесения различной информации о ресурсах, программах, пользователях в базу данных. Имеется
администраторская часть и пользовательская. Также присутствует возможность управления
правами того или иного пользователя.
Имеется система контактов и система генерации отчетов различного характера.
Рисунок 6 - Интерфейсы программы GLPI.
15
Плюсы:

возможность подачи заявок пользователями;

широкий спектр ресурсов, обслуживаемых системой;

система отчетов;

управление пользователями и ролями;

база знаний по тому или иному вопросу;

широкие возможности сортировки при просмотре данных.
Минусы:

в основном табличное представление данных;

отсутствие подсказок администратору, по тому или иному вопросу;

местами перегруженный интерфейс;

нет общего представления информации по всем ресурсам.
Network Inventory Advisor - http://www.clearapps.com/
Network Inventory Advisor – это приложение для инвентаризации компьютерной сети.
Основным функционалом является сканирование сети и сбор данных о компьютерах,
находящихся в этой сети. Сканирование и сбор информации происходят полностью в
автоматическом режиме. Собирается информация о программном и аппаратном обеспечении
каждого компьютера. После сканирования данные по каждому компьютеру в сети группируются
по разделам и уже готовы к анализу или экспорту.
Всю информацию о программном или аппаратном обеспечении можно представить в виде
отчета, выбрав любую комбинацию параметров.
Программа дает некого радо предупреждения администратору на основе собранных
данные, например на таком-то компьютере заканчивается дисковое пространство.
Рисунок 7 - Интерфейсы программы Network Inventory Advisor.
16
Плюсы:

автоматическое сканирование и сбор информации;

интуитивно понятный интерфейс;

гибкость при составлении отчетов;

предупреждения от программы.
Минусы:

сугубо инвентарное назначение;

не рассчитана на взаимодействие пользователей и администратора;

платная;

нет общего представления информации по всем ресурсам.
ServiceDesk Plus - http://www.manageengine.com/products/service-desk/
ServiceDesk Plus представляет собой веб-приложение с достаточно широким
функционалом. Приложение служит для обработки различного рода запросов от пользователей –
проблемы при использовании того или иного ПО, проблемы пользования системой. Уведомления
о всех обработанных запросах отсылаются обратно пользователю. Также приложение
используется для инвентаризации компьютерной техники, предоставляя детальную информацию
по каждому обнаруженному в сети устройству. Помимо учета аппаратных средств, присутствует
и учет установленного программного обеспечения, а так же управление лицензиями. Имеется
шедулер, для создания разного рода задач и напоминаний. Присутствует так называемая база
знаний, в которой собраны решения типичных проблем. База доступная для пользователей, они
могут ознакомиться с ней перед тем как отправиться заявку. Имеются большие возможности по
настройке системы: настройка самой системы помощи, настройка пользователей, групп и прав
доступа, настройка управлениями ресурсами и ПО. Помимо всего этого имеется подсистема
отчетов, с широкими возможностями выбора, которая предоставляет информацию по тому или
иному вопросу. Возможны отчеты в разных форматах – текст, html, pdf, xls, графический вид.
Представление информации в системе текстовое и графическое.
Рисунок 8 - Интерфейсы программы ServiceDesk Plus.
17
Плюсы:

широкий спектр решаемых задач;

база знаний;

хорошая система отчетов;

планировщик задач по расписанию.
Минусы:

местами перегруженный интерфейс;

медленность работы;

платность;

нет общего представления информации по всем ресурсам.
SysAid - http://www.ilient.com/
SysAid – это большое web-приложение, позволяющее выполнять широкий круг задач.
Предназначено приложение как для мелких фирм, так и для крупных, имеющих хоть какой парк
компьютерных ресурсов. Подача заявок от пользователей по различным проблемам. Система
автоматизирует процессы помощи сотрудникам, при возникновении проблем, автоматизирует
процессы сбора информации об аппаратных ресурсах и программном обеспечении. Также
приложение позволяет управлять лицензиями ПО, предоставляет средство мониторинга
ресурсов, средство управления проектами и задачами. Приложение хоть и веб ориентированное,
но предоставляет удаленный доступ к просканированным рабочим станциям, это может быть
эффективно при возникновении какой-либо трудности у сотрудника, требующей вмешательства
технического специалиста. Система так же как и многие предоставляет базу знаний по тому или
иному вопросу, поднимавшемуся ранее кем-либо. Есть система шаблонов использования
ресурсов для рабочих станций и серверов. После создания шаблона, шаблон назначается на
несколько машин, при возникновении на машинах ситуаций, описанных в шаблонах, система
сигнализирует об этом администратору. Также присутствует система уведомлений, которая
оповещает о тех или иных событиях системы. Присутствует система отчетов. Представление
информации в основном табличное.
18
Рисунок 9 - Интерфейсы программы SysAid.
Плюсы:

решение широкого круга задач;

база знаний;

автоматический сбор информации по сети;

удаленный доступ;

система отчетов.
Минусы:

платность полной версии;

нет общего представления информации по всем ресурсам.
Сводная таблица преимуществ и недостатков рассмотренных систем представлена ниже
(таблица 1).
19
Таблица 1 – Сравнение аналогов
Email уведомления
Сбор информации о
ресурсах
База знаний
Система отчетов
Информативность
интерфейса
Система подсказок
Общее
представление всей
информации
Бесплатность
phpMyInventory
+
–
–
–
–
–
–
–
–
+
GLPI
+
+
+
–
+
+
–
–
–
–
Network
Inventory
Advisor
–
–
–
+
–
+
+
–
–
+
ServiceDesk
Plus
+
+
+
–
+
+
–
–
–
–
SysAid
+
+
+
+
+
+
–
–
–
–
Webориентированность
Система подачи
заявок
Система
1.6 Постановка задач ВКР
Проведенный анализ показал, что необходимо приложение, которое позволит системному
администратору хоть и не управлять всеми ресурсами, но следить за ними и их текущим
состоянием, а пользователю в свою очередь, позволит получать такие ресурсы.
Содержательно требования к такой системе можно описать следующим образом.
Слежение это надо сделать максимально простым и понятным для системного
администратора. А что человек просто воспринимает? Скорее всего это не бесконечные цифры,
меняющиеся каждую минуту, это простая графическая информация в виде графиков и
таймлайнов, на которых четко и ясно будет обозначено какие ресурсы сейчас в использовании,
кем используются, под какие нужды, в каком проекте, какая у ресурса конфигурация, какой IPадрес и т.п. Приложение не призвано управлять и следить за всеми машинами в реальном
времени, приложение представляет собой простую информационную систему, позволяющую
20
просматривать текущую ситуацию, делать выводы, запрашивать необходимые ресурсы и
подбирать их, получать информацию в виде отчетов.
Разработчики же могут пользоваться приложением, чтобы уведомлять администратора о
своих нуждах, всегда иметь информацию о выделенных для них ресурсов. В несколько шагов
подать ту или иную заявку. Помимо всего этого приложение должно полностью обрисовывать
текущую ситуацию по ресурсам компании, иметь понятный интерфейс и графическое
представление информации. Пользоваться приложением могут различные группы пользователей,
с заранее определенными правами доступа.
Современный рынок программного обеспечения предлагает широкий спектр
программных продуктов по инвентаризации компьютерных ресурсов. В то же время
инвентаризация ресурсов и техники – это простая база данных, содержащая информацию о
технике, не дающая общего представления с точки зрения использования ресурсов персоналом,
командами разработчиков, с точки зрения временных рамок использования, с точки зрения
интеллектуальных подсказок и взаимодействия пользователей.
Формальную постановку цели и задач ВКР можно описать следующим образом.
Необходимо создать систему, реализующую заявленные требования и полностью
сопровождающую бизнес–процесс создания ресурсов для разработки, как с пользовательской,
так и с администраторской стороны.
Для выполнения поставленной задачи необходимо:

провести анализ понятия учета и способов представления информации;

провести анализ бизнес–процесса предоставления ресурсов для разработчиков как
есть, как он происходи сейчас;

рассмотреть существующие аналоги и выявить сильные и слабые стороны
рассмотренных продуктов;

cформировать требования к информационной системе, выбрать необходимые средства
реализации;

cформулировать рекомендации по внедрению системы в конкретном бизнес–процессе
после ее технической реализации, учитывая особенности работы конечного
пользователя, эксплуатирующего информационную систему;

сформулировать рекомендации по дальнейшему развитию системы и внедрению её в
смежные виды деятельности.
21
Глава 2. Проектирование системы
2.1 Общее проектирование системы
Проектирование информационных систем всегда начинается с определения цели проекта.
Основная задача любого успешного проекта заключается в том, чтобы на момент запуска
системы и в течение всего времени ее эксплуатации можно было обеспечить:

требуемую функциональность системы и степень адаптации к изменяющимся
условиям ее функционирования;

требуемую пропускную способность системы;

требуемое время реакции системы на запрос;

безотказную работу системы в требуемом режиме, иными словами - готовность и
доступность системы для обработки запросов пользователей;

простоту эксплуатации и поддержки системы;

необходимую безопасность.
После того, как начальные требования к разрабатываемой системе определены,
начинается процесс детального проектирования. Именно на этом этапе разработки
закладываются основные механизмы работы системы, интерфейсы и точки взаимодействия
компонентов системы. Помимо всего этого проектируется база данных, которая собственно и
будет определять модель данных в системе.
Для проектировании системы была выбрана поэтапная (итерационная) модель разработки
с промежуточным контролем (рисунок 10).
Рисунок 10 – Итерационная модель разработки.
Выбор можно обусловить невозможностью определения всех требований к системе на
соответствующем этапе. Разработка ИС ведется итерациями с циклами обратной связи между
этапами. Межэтапные корректировки позволяют учитывать реально существующее
взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов
растягивается на весь период разработки.
22
2.2 Клиент-серверное взаимодействие
Сетевые приложения, в том числе и приложения, работающие через интернет,
реализуются по технологии «клиент-сервер». Это означает, что программное обеспечение
делится на две части: клиентскую, устанавливаемую на компьютере пользователя, и серверную,
устанавливаемую на компьютере-сервере.
Клиентское программное обеспечение предназначено для формирования запросов
пользователя к серверной части и для отображения пользователю получаемых от сервера
ответов. Клиентская часть обеспечивает удобство пользовательского интерфейса. Основную же
нагрузку несет серверная часть, которая обычно обслуживает запросы множества клиентов,
производит сложные расчеты, формирует результаты ответов. Нередко серверная часть помимо
самого сервера приложений использует дополнительные сервера – сервер баз данных, файловый
сервер, почтовый сервер.
Клиентская часть бывает представлена в виде «толстого» или «тонкого» клиента. В
настоящей ВКР клиентским программным обеспечением является веб-браузер, который является
тонким клиентом для доступа к приложению.
Все взаимодействие между клиентским программным обеспечением и серверным
происходит по сетевому протоколу TCP/IP. На его прикладном уровне работает большинство
сетевых приложений. Эти программы имеют свои собственные протоколы обмена информацией,
например, HTTP для WWW, FTP (передача файлов), SMTP (электронная почта), SSH (безопасное
соединение с удалённой машиной), DNS (преобразование символьных имён в IP-адреса) и
многие другие.
Клиент
База
данных
Сервер
Клиент
Рисунок 11 – Клиент-серверная архитектура.
23
2.3 Шаблон Модель-Представление-Контроллер
При разработки ядра системы был выбран популярный шаблон проектирования (design
pattern) модель-представление-контроллер (model-view-controller) как основная концепция для
создания информационной системы. Модель-представление-контроллер - архитектура
программного обеспечения, в которой модель данных приложения, пользовательский интерфейс
и управляющая логика разделены на три отдельных компонента, так, что модификация одного из
компонентов оказывает минимальное воздействие на другие компоненты. Шаблон MVC
позволяет разделить данные, представление и обработку действий пользователя на три
отдельных компонента:

модель (Model). Модель представляет собой данные, которыми оперирует приложение. Она
предоставляет данные для View, а также реагирует на запросы от контроллера, изменяя свое
состояние;

представление (View). Представляет собой компонент системы для отображения состояния
модели в понятном человеку представлении. Представление не изменяет данные напрямую
(режим только чтение), данные изменяются при помощи контроллера;

контроллер (Controller). Является средством, при помощи которого пользователи
взаимодействуют с системой, а также является управляющим элементом для обмена данными
между представлением и моделью.
Рисунок 12 – Шаблон модель-представление-контроллер.
24
2.4 Варианты использования системы
Исходя из начальных требований к системе, удалось выделить несколько вариантов
использования для разрабатываемой системы. Данные варианты иллюстрируют основную
функциональность системы, доступную для различных акторов системы – пользователя и
администратора. Изображенные варианты использования не окончательные и будут дополняться
в процессе разработки. Цель варианта использования заключается в том, чтобы определить
законченный аспект или фрагмент поведения некоторой сущности без раскрытия её внутренней
структуры. В качестве такой сущности может выступать система или любой элемент модели,
который обладает собственным поведением.
Каждый вариант использования соответствует отдельному сервису, который
предоставляет моделируемая сущность по запросу актера, то есть определяет способ применения
этой сущности. Сервис, который инициализируется по запросу актера, представляет собой
законченную неделимую последовательность действий. Это означает, что после того как система
закончит обработку запроса, она должна возвратиться в исходное состояние, чтобы быть готовой
к выполнению следующих запросов.
Варианты использования могут применяться как для спецификации внешних требований к
проектируемой системе, так и для спецификации функционального поведения уже
существующей системы. Множество вариантов использования в целом должно определять все
возможные стороны ожидаемого поведения системы. Кроме этого, варианты использования
неявно устанавливают требования, определяющие, как актеры должны взаимодействовать с
системой, чтобы иметь возможность корректно работать с предоставляемыми сервисами. Для
удобства множество вариантов использования может рассматриваться как отдельный пакет.
Примерами вариантов использования могут являться следующие действия: проверка
состояния текущего счета клиента, оформление заказа на покупку товара, получение
дополнительной информации о кредитоспособности клиента, отображение графической формы
на экране монитора и другие действия.
В текущей ВКР основными акторами системы являются пользователь и администратор
системы, для каждого из них доступен определенный набор действий, который представлены на
диаграмме вариантов использования (рисунок 13, 14).
25
Рисунок 13 –Варианты использования для пользователя системы.
Рисунок 14 –Варианты использования для администратора системы.
2.5 Диаграмма пакетов
Диаграмма пакетов, Package diagram — структурная диаграмма, основным содержанием
которой являются пакеты и отношения между ними. Жёсткого разделения между разными
структурными диаграммами не проводится, поэтому данное название предлагается
исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов
могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую
26
очередь, для организации элементов в группы по какому-либо признаку с целью упрощения
структуры и организации работы с моделью системы.
При проектировании приложения удалось выделить следующие пакеты (рисунок 15):

Diplom – основной пакет приложения, содержащий все остальные пакеты;
o Dao – пакет содержащий основные интерфейсы системы для взаимодействия с
хранилищем данных;

Impl – пакет содержащий классы, реализующие интерфейсы
взаимодействия с хранилищем данных;

Services – пакет содержащий бизнес-логику – сервисные классы. Данные
классы, как правило, предоставляют доступ к методам интерфейсов, ничего
не зная об их реализации;
o Entity – пакет содержащий объекты модели данных;
o Util – пакет с утилитарными классами различного назначения, необходимых для
функционирования приложения;
o Web – пакет, содержащий основную логику приложения;

Controllers – пакет содержащий набор контроллеров, ответственных за
логику работы системы и взаимодействия модели данных с представлением;

Validators – пакет содержащий набор валидаторов, ответственных за
проверку и контроль создаваемых сущностей системы;

Servlets – пакет с сервлетама, предназначенных для обработки ajaxзапросов;

Ajax – пакет, содержащий модифицированный контроллер, предназначен
для обработки ajax запросов и взаимодействия с javascript библиотекой
jQuery;

Exceptions – пакет, содержащий объекты собственных исключений.
27
Рисунок 15 –Диаграмма пакетов.
2.6 Диаграммы последовательности
Диаграмма последовательности (англ. sequence diagram) — диаграмма, на которой
показаны взаимодействия объектов, упорядоченные по времени их проявления.
Основными элементами диаграммы последовательностей являются обозначения объектов
(прямоугольники), вертикальные линии, отображающие течение времени при деятельности
объекта, и стрелки, показывающие выполнение действий объектами.
На диаграмме ниже представлен процесс подачи пользователем новой заявки на ресурс
(рисунок 16). Как видно из схемы, в процессе участвуют несколько объектов, выполняющих свои
задачи на том или ином промежутке времени. Форма является объектом, с которым
взаимодействует пользователь. После заполнения формы и нажатия кнопки «Отправить» в
действие вступает серверная сторона приложения, ответственная за проверку введенных данных
и сохранение заявки в базе данных.
28
Рисунок 16 – Подача заявки на ресурс.
На следующей диаграмме (рисунок 17) представлен процесс просмотра администратором
системы полной информации по ресурсам, зарегистрированным в системе. На данном
изображении с клиентской стороны выступают объект формы и TimeLine Engine –
ответственный за построение таймлайнов на странице. На серверной стороне стоит отметить
объект Json Generator, который модифицирует полученные данные от системы в формат json и
перелает их на клиентскую сторону.
Рисунок 17 – Просмотр ресурсов.
29
На данном изображении (рисунок 18) представлена диаграмма последовательности
действий системы при аутентификации пользователя в системе. После отправки пользователем
идентификационных данных, эти данные попадают в объект autentification-provider, который
формирует так называемы User Token из полученных данных. После чего выполняется запрос к
базе данных, где происходит выборка информации о пользователе, в частности о его роли в
системе. Из полученных данных формируется объект User Detail, который передается обратно
объекту autentification-provider, который в свою очередь отправляет пользователя на
соответствующую страницу, в зависимости от его роли.
Рисунок 18 – Аутентификация в системе.
2.7 Выбор платформы и средств реализации
В настоящее время в мире разработки программного обеспечения развиваются и
прогрессируют множество средств и платформ для создания веб-приложений. Как правило, чаще
всего с помощью данных средств создаются клиент-серверные приложения, доступ к которым
осуществляется либо посредством локальной сети, либо через глобальную сеть интернет,
взаимодействие пользователей и приложения происходит через браузер. Среди активно
развивающихся технологий наиболее популярны следующие:

php;

java;

.NET;

ruby;
30

groovy.
В качестве платформы и языка для разработки исследуемой информационной системы
был выбран язык Java. Выбор можно обусловить множеством факторов:

огромные возможности языка;

множество сторонних библиотек и платформ;

полностью открытое и свободное ПО;

внушительное сообщество разработчиков;

наличие бесплатных средств разработки;

популярность и развитие;

множество подробной документации.
Рассматриваемая информационная система базируется на новейших и мощных JavaEE
технологиях, как от самой Sun, так и от множества сторонних разработчиков (Apache, JBoss,
Spring Source). Данные технологии предоставляют полный набор средств для разработки
современной клиент-серверной информационной системы.
Благодаря почти полной открытости кода, разработка приобретает совершенно иной
характер, разработчик всегда может заглянуть в код используемой библиотеки и понять как она
работает, как взаимодействует с другими компонентами системы. При необходимости можно
изменить логику работы, подстроив ее под свои нужды.
Наличие огромного множества документации тоже значительно упростило процесс
разработки. Так как используемые технологии довольно популярны среди JavaEE разработчиков,
то авторы постарались предоставить исчерпывающую информацию по своим продуктам, при это
значительно облегчив процесс разработки для конечных пользователей. Большинство
документации на английском языке.
У такой популярной технологии как java и других java платформ имеется огромное
сообщество разработчиков. Участие в данных сообществах может значительно облегчить
процесс изучения новых технологий - позволяет обмениваться опытом между разработчиками,
предоставляет получить профессиональный ответ на поставленный вопрос.
В процессе создания информационной системы использовались бесплатные средства
разработки, упрощающие непосредственно сам процесс разработки, процесс сборки приложения,
предоставляющие средства рефакторинга кода, упрощающие процесс установки приложения на
сервер.
31
2.8 Выбор базы данных
При выборе реляционной СУБД были проанализированы следующие параметры
различных баз данных:

архитектура доступа к БД;

кроссплатформенность;

наличие оптимального драйвера для Java;

производительность;

поддержка необходимых типов данных;

лицензирование.
Среди всех рассматривавшихся СУБД (MySQL, InterBase, Firebird, PostgreSQL, Oracle,
MSSQL Server, Sybase, Access) наиболее отвечающей необходимым требованиям была
определена СУБД MySQL версии 5.1.х. Среди недостатков внедрения прочих продуктов в проект
отмечены факторы:

достаточно высокая стоимость лицензии (MSSQL Server, Oracle);

кроссплатформенность (MSSQL Server - под Windows, Oracle отходит от неё);

архитектура (Access полноценно не поддерживает архитектуру «клиент-сервер»);

отсутствие полноценной поддержки работы с Java.
Основным критерием выбора СУБД являлась наиболее оптимальная поддержка Java при
достаточно небольшом количестве одновременных подключений. Существует несколько JDBCдрайверов для MySQL:

MySQL Connector/J - родной драйвер для Java. Версия 5.1 выпускается под двойным
лицензированием (GPL и коммерческая лицензия);

драйвер Resin: коммерческий JDBC-драйвер, распространяющийся как ПО с открытым
кодом;

драйвер gwe: Java-интерфейс, разработанный компанией GWE technologies (более не
поддерживается).
Среди прочих параметров, определивших выбор СУБД MY SQL, стоит отметить:

независимые типы таблиц (MyISAM и InnoDB);

транзакции, полнотекстовый поиск, использование индексов, сегментирование таблиц,
представления данных, триггеры, временные таблицы;

расширенные возможности работы с XML документами;

быстродействие:
32
o поддержка многопоточности (на многопроцессорных серверах);
o быстрая работа с файловой структурой хранимых данных на диске;
o индексация выполненных SQL запросов;

полноценная поддержка Transact SQL (собственная специфика синтаксиса):
o полная поддержка операторов и функций в SELECT- и WHERE- частях
запросов;
o возможности сортировки и группировки данных (Group и Order – By),
использование агрегирующих функций;
o подзапросы, псевдонимы;
o просмотр системной информации и отладка ошибок (команды SHOW и
EXPLAIN);

масштабируемость:
o размер одной таблицы до 8 миллионов Tb (с ограничениями используемой
файловой системы ОС);
o до 50 млн. записей в таблице;
o до 32 индексов в каждой таблице.
2.9 Структура базы данных
Важнейшая цель проектирования информационной модели - выработка непротиворечивой
структурированной интерпретации реально существующей информации изучаемой предметной
области и взаимодействия между ее структурными компонентами.
Понятие концептуальной модели данных связано с методологией семантического
моделирования данных, т.е. с представлением данных в контексте их взаимосвязей с другими
данными.
Методология IDEF1X - один из подходов к семантическому моделированию данных,
основанный на концепции "сущность-связь" (Entity-Relationship). Это инструмент для анализа
информационной структуры систем различной природы. Информационная модель, построенная с
помощью IDEF1X-методологии, отображает логическую структуру информации об объектах
системы
Таким образом, концептуальная модель, представленная в соответствии со стандартом
IDEF1X, является логической схемой базы данных для проектируемой системы
Основными объектами концептуальной модели являются сущности и связи.
Сущность - некоторый обособленный объект или событие моделируемой системы,
имеющий определенный набор свойств - атрибутов. Отдельный элемент этого множества
33
называется "экземпляром сущности". Сущность может обладать одним или несколькими
атрибутами, которые однозначно идентифицируют каждый образец сущности, и может обладать
любым количеством связей с другими сущностями.
Правила для атрибутов сущности:

каждый атрибут должен иметь уникальное имя;

сущность может обладать любым количеством атрибутов;

сущность может обладать любым количеством наследуемых атрибутов, но
наследуемый атрибут должен быть частью первичного ключа сущности-родителя;

для каждого экземпляра сущности должно существовать значение каждого его
атрибута (правило необращения в нуль - Not Null) ;

ни один из экземпляров сущности не может обладать более чем одним значением для
ее атрибута.
Сущность изображается на ER-диаграмме в виде прямоугольника, в верхней части
которого приводится ее название; далее следует список атрибутов. Ключевые атрибуты могут
быть выделены подчеркиванием или иным способом.
Стандарт IDEF1X описывает способы изображения двух типов сущностей - независимой и
зависимой, и связей - идентифицирующих и неидентифицирующих.
Каждая сущность может обладать любым количеством связей с другими сущностями.
Сущность является независимой, если каждый ее экземпляр может быть однозначно
идентифицирован без определения его связей с другими сущностями.
Сущность называется зависимой, если однозначная идентификация ее экземпляра зависит
от его связей с другими сущностями.
Сущность может обладать атрибутами, которые наследуются через связь с родительской
сущностью. Последние обычно являются внешними ключами (FK) и служат для организации
связей между сущностями. Если внешний ключ сущности используется в качестве ее
первичного ключа (PK) или как часть составного первичного ключа, то сущность является
зависимой от родительской сущности. Если внешний ключ не является первичным и не входит в
составной первичный ключ, то сущность является независимой от родительской сущности.
Если сущность является зависимой, то связь ее с родительской сущностью называется
идентифицирующей, в противном случае - неидентифицирующей.
Связи дается имя, выражаемое грамматической формой глагола. Для связи дополнительно
может присутствовать указание мощности: какое количество экземпляров сущности-потомка
может существовать для сущности-родителя. Имя связи всегда формируется с точки зрения
34
родителя, так что может быть образовано предложение, если соединить имя сущности родителя,
имя связи, выражение мощности и имя сущности-потомка
Ниже на изображении представлена концептуальная модель базы данных
разрабатываемой информационной системы в нотации IDEF1X:
Рисунок 18 – Структура базы данных.
2.10 Описание таблиц
Таблица 2 - Данные, хранимые в полях таблицы и их форматы
Формат
Таблица
Поле
Данные
statuses
statusId (PK)
уникальный идентификатор статуса
int
statusName
Имя статуса
varchar
данных
35
appCategories
applications
alias
Псевдоним статуса
varchar
categoryId (PK)
уникальный идентификатор категории
int
categoryName
Имя категории
varchar
description
Описание категории
varchar
statusId (FK)
уникальный идентификатор статуса
int
уникальный идентификатор приложения
int
applicationName
Имя приложения
varchar
description
Описание приложения
varchar
categoryId (FK)
уникальный идентификатор категории
varchar
statusId (FK)
уникальный идентификатор статуса
varchar
orderId (PK)
уникальный идентификатор заявки
int
CPU
Величина CPU в ГГц
float
HDD
Величина HDD в ГБ
float
RAM
Величина RAM в ГБ
float
description
Описание заявки
varchar
startDate
Дата начала использования ресурса
timestamp
finishDate
Дата конца использования ресурса
timestamp
userId (FK)
уникальный идентификатор пользователя
int
resourceId (FK)
уникальный идентификатор ресурса
int
projectId (FK)
уникальный идентификатор проекта
int
statusId (FK)
уникальный идентификатор статуса
int
priorityId (FK)
уникальный идентификатор приоритета
int
roleId (PK)
уникальный идентификатор роли
int
roleName
Имя роли
varchar
alias
Псевдоним роли
varchar
userId (PK)
уникальный идентификатор пользователя
int
firstName
Имя пользователя
varchar
lastName
Фамилия пользователя
varchar
login
Логин
varchar
password
Пароль
varchar
email
Адрес электронной почты
varchar
roleId (FK)
уникальный идентификатор роли
int
statusId (FK)
уникальный идентификатор статуса
int
applicationId
(PK)
orders
roles
users
36
messages
resources
projects
hosts
events
messageId (PK)
уникальный идентификатор сообщения
int
fromUser
уникальный идентификатор пользователя
int
toUser
уникальный идентификатор пользователя
int
title
Заголовок сообщения
varchar
body
Текст сообщения
varchar
date
Дата отправки сообщения
varchar
statusId (FK)
уникальный идентификатор статуса
int
resourceId (PK)
уникальный идентификатор ресурса
int
hostName
Имя ресурса
varchar
ipAddress
IP-адрес ресурса в сети
varchar
CPU
Величина CPU в ГГц
float
RAM
Величина RAM в ГБ
float
HDD
Величина HDD в ГБ
float
description
Описание ресурса
varchar
startDate
Дата начала использования ресурса
timestamp
finishDate
Дата конца использования ресурса
timestamp
login
Имя пользователя для входа на ресурс
varchar
password
Пароль для входа на ресурс
varchar
statusId (FK)
уникальный идентификатор статуса
int
hostId (FK)
уникальный идентификатор хоста
int
projectId (PK)
уникальный идентификатор проекта
int
projectName
Имя проекта
varchar
description
Описание проекта
varchar
statusId (FK)
уникальный идентификатор статуса
int
hostId (PK)
уникальный идентификатор хоста
int
hostName
Имя хоста
varchar
ipAddress
Ip-адресс хоста в сети
varchar
CPU
Величина CPU в ГГц
float
RAM
Величина RAM в ГБ
float
HDD
Величина HDD в ГБ
float
description
Описание хоста
varchar
statusId (FK)
уникальный идентификатор статуса
int
eventId (PK)
уникальный идентификатор события
int
eventName
Имя события
varchar
37
stats
order_applications
description
Описание события
varchar
startDate
Время начла события
timestamp
finishDate
Время окончания события
timestamp
resourceId (FK)
уникальный идентификатор ресурса
int
userId (FK)
уникальный идентификатор пользователя
int
statusId (FK)
уникальный идентификатор статуса
int
statId (PK)
уникальный идентификатор статистики
int
action
действие
varchar
description
описание
varchar
date
Время и дата
timestamp
resourceId (FK)
уникальный идентификатор ресурса
int
userId (FK)
уникальный идентификатор пользователя
int
orderId (FK)
уникальный идентификатор заявки
int
hostId (FK)
уникальный идентификатор хоста
int
orderId (PK)
int
applicationId
int
(PK)
users_projects
projects_resources
userId (PK)
уникальный идентификатор пользователя
int
projectId (PK)
уникальный идентификатор проекта
int
projectId (PK)
уникальный идентификатор проекта
int
resourceId (PK)
уникальный идентификатор ресурса
int
38
Глава 3. Разработка системы
3.1 Технологии проекта
Как уже отмечалось ранее, для разработки исследуемой информационной системы были
выбраны новейшие java и javaEE технологии. В javaEE входят различные технологии, который
применялись во время разработки проекта, среди них:

cервлеты (javax.servlet и javax.servlet.http);

cтраницы JSP (Java Server Pages);

enterprise JavaBean (javax.ejb.*);

J2EE Connector;

java Message Service (javax.jms.*);

интерфейс для обработки XML;

java Authorization Contract for Containers;

javaServer Faces (javax.faces.component.html);

java Persistence API (javax.persistence).
Помимо упомянутых технологий и стандартов от компании Sun Microsystems
применялись java-библиотеки и компоненты от сторонних разработчиков. Среди них:

Hibernate - https://www.hibernate.org/;

Spring Famework - http://www.springsource.org/;

Apache Jakarta Project - http://jakarta.apache.org/;

JasperReports - http://jasperforge.org/.
Так же использовалась библиотека Simile Timeline для построения динамических
таймлайнов на странице http://www.simile-widgets.org/timeline/
39
3.2 Сервер приложений Tomcat
Tomcat представляет собой программу-контейнер сервлетов, написанная на языке Java и
реализующая спецификацию сервлетов и спецификацию JavaServer Pages (JSP), которые
являются стандартами для разработки веб-приложений на языке Java.
Tomcat позволяет запускать веб-приложения, содержит ряд программ для самоконфигурирования, администраторское приложение, позволяющее управлять установленными
приложениями, пользователями и пр.
Tomcat не является полноценным сервером приложений в понятии javaEE, так как е него
отсутствует поддержка следующих стандартов: EJB, JTA, Web Services и др. Однако
перечисленные стандарты не использовались в проекте, поэтому Tomcat является достаточным
сервером приложений для развертывания и запуска разрабатываемой системы.
3.3 Модель данных системы
На диаграмме классов ниже (рисунок 19) представлена модель данных в системе. Как
видно из диаграммы многие сущности находятся в состоянии ассоциации, что говорит о
взаимосвязанности классов системы.
40
Рисунок 19 – Модель данных системы.
41
3.4 ORM и Hibernate
ORM(Object/Relational Mapping) - это способ сохранения объектов в реляционную базу
данных. Другими словами ORM освобождает нас от работы с SQL и позволяет сосредоточиться
на ООП.
ORM-решением для языка Java, является технология Hibernate, которая не только
заботится о связи Java классов с таблицами базы данных (и типов данных Java в типы данных
SQL), но также предоставляет средства для автоматического построения запросов и извлечения
данных и может значительно уменьшить время разработки, которое обычно тратится на ручное
написание SQL и JDBC кода. Hibernate генерирует SQL вызовы и освобождает разработчика от
ручной обработки результирующего набора данных и конвертации объектов, сохраняя
приложение портируемым во все SQL базы данных.
Для работы технологии Hibernate необходимо специальным образом описать классы,
реализующие модель данных системы. На сегодняшний день возможно два варианта описания
классов – xml файлы и аннотации. При разработке системы использовались аннотации для
описания, которые представляют собой некоторые метаданные, которые могут добавляться в
исходный код программы и только косвенно влияют на нее, но могут использоваться в процессе
анализа кода, компиляции и во время выполнения.
Вот основные варианты использования аннотаций:

предоставлять необходимую информацию для компилятора;

предоставлять метаданные различным инструментам для генерации кода;

использоваться в коде во время выполнения программного кода (reflection).
@Entity
@Table(name = "applications")
public class Application {
@Id
@GeneratedValue(strategy= GenerationType.IDENTITY)
@Column(name = "applicationId", nullable = false)
private Long applicationId;
@Column(name = "applicationName", nullable = false)
private String applicationName;
@Column(name = "description", nullable = true)
private String description;
@ManyToMany(cascade = CascadeType.REFRESH, fetch = FetchType.LAZY)
@JoinTable(name = "orders_applications",
42
joinColumns = @JoinColumn(name = "applicationId"),
inverseJoinColumns = @JoinColumn(name = "orderId"))
private Set<Order> orders = new HashSet<Order>();
@ManyToOne(cascade = CascadeType.REFRESH, fetch = FetchType.LAZY)
@JoinColumn(name="statusId", nullable = false)
private Status status;
@ManyToOne(cascade = CascadeType.REFRESH, fetch = FetchType.LAZY)
@JoinColumn(name="categoryId", nullable = false)
private Category category;
Аннотации описывают поля класса в терминах базы данных, определяя на какое поле
таблицы будет отображаться то или иное поле. Определяют саму таблицу, на которую будет
отображаться класс, отношения между полями, типы связей и другие вещи.
Как уже говорилось выше, технология Hibernate позволяет нам забыть о непосредственной
работе с базой данных и позволяет совершать все операции по работе с данными в терминах
объектов.
Рассмотрим как выполняются простые операции типа создания, удаления, обновления
сущности на примере сущности Application
public class ApplicationDAOImpl implements IApplicationDAO {
private HibernateTemplate template;
public void setTemplate(HibernateTemplate template) {
this.template = template;
}
public void create(Application application) {
template.save(application);
}
public void update(Application application) {
template.saveOrUpdate(application);
}
public void delete(Application application) {
template.delete(application);
}
public Application getById(Long applicationId) {
return (Application) template.get(Application.class, applicationId);
}
}
Из примера видно, что простые CRUD-операции выполняются достаточно просто и не
требуют написания каких-либо запросов, достаточно лиши вызвать метод у экземпляра
специального класса.
43
Помимо таких простых операций возможно выполнение и более сложных действий. Для
этих целей в Hibernate присутствует два способа:

HQL (Hibernate Query Language) – язык запросов Hibernate, чем-то похож на обычный
SQL, но в отличии он него позволяет работать с сущностями в терминах объектов.
Полностью объектно-ориентированный, соответствует таким понятиям как
наследование и полиморфизм.

Criteria API – набор классов и интерфейсов для создания и выполнения объектноориентированных запросов. Используется как альтернатива HQL.
Пример HQL:
public List<Application> getAll() {
return template.find("from Application order by applicationName");
}
public Application getByName(String applicationName) {
return (Application) (template.find("from Application a where
a.applicationName = ?", applicationName).get(0));
}
Тут как мы видим, происходят две несложные операции – выборка всех объектов данного
класса и выборка объекта по его имени.
В рассмотренном примере использовался экземпляр класса HibernateTemplate, который
собственно и выполняет все запросы к базе данных, данный объект относится к специальным
классам Spring Framework, который будет рассмотрен далее.
44
3.5 Spring IoC Conteiner
В основе Spring лежит паттерн Inversion of control. Применительно к легковесным
контейнерам, основная идея этого паттерна заключается в устранении зависимости компонентов
или классов приложения от конкретных реализаций вспомогательных интерфейсов и
делегировании полномочий по управлению созданием нужных реализаций IoC контейнеру.
Рассмотрим UML диаграмму
Рисунок 19 – работа IoC контейнера.
IoC контейнер отвечает за создание нужной реализации Product для Consumer. При
использовании класса Consumer в других проектах мы сможем заменить реализацию интерфейса
Product на более подходящую, не внося изменений в код.
Основные преимущества IoC контейнеров:

управление зависимостями;

упрощение повторного использования классов или компонентов;

упрощение unit-тестирования;

более "чистый" код (Классы больше не занимаются инициализацией
вспомогательных объектов.) В IoC контейнер лучше всего выносить те
интерфейсы, реализация которых может быть изменена в текущем проекте или в
будущих проектах.).
Все объекты и зависимости между этими объектами описываются через специальный xmlфайл applicationContext.xml.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
45
<bean name="applicationDAO" class="my.diplom.dao.impl.ApplicationDAOImpl">
<property name="template" ref="hibernateTemplate"/>
</bean>
<bean name="applicationService" parent="abstractTransactionProxy" >
<property name="target">
<bean name="ApplicationService"
class="my.diplom.dao.service.ApplicationService">
<property name="applicationDAO" ref="applicationDAO"/>
</bean>
</property>
</bean>
…
</beans>
Как видно из данного куска файла, описаны зависимости между тремя объектами:
hibernateTemplate – класс, который предоставляет доступ к данным.
applicationDAO – класс, зависящий от класса hibernateTemplate и реализующий
интерфейс для работы с сущностью Application
applicationService – класс, относящийся к бизнес-логике приложения, зависит от класса
applicationDAO и делегирует его методы для работы с сущность Application
Данный подход очень удобен при написании больших приложений, описание
зависимостей между классами избавляет от написания лишнего кода. Описав зависимости,
система при инициализации сама проинстанциирует зависящие классы и предоставит ним
доступ.
3.6 Spring DAO и Spring ORM
Поверх IoC-контейнера работают библиотеки, обеспечивающие следующую
функциональность:
— DAO (Data Access Objects) — отвечает за доступ к данным в БД. Включает в себя набор
шаблонов для работы с JDBC и менеджер транзакций.
— ORM (Object-Relation mapping) — содержит классы для взаимодействия с наиболее
популярными ORM-фреймворками, такими как Hibernate, TopLink, iBatis и некоторыми
другими.
46
Основная цель среды Spring DAO и Spring Hibernate заключается в стандартизации и
упрощении работы с технологиями доступа к данным, например, с JDBC, Hibernate или JDO.
Поэтому при использовании среды Spring DAO можно довольно легко сменить одну технологию
доступа к данным на другую.
В конечном итоге пользователю предоставляется набор классов, которыми он может
оперировать при создании приложения, выбрав ту или иную реализацию, в зависимости от
технологии доступа к данным.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean name="diplomDS"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost:3306/diplom"/>
<property name="username" value="root"/>
<property name="password" value="root"/>
</bean>
<bean name="sessionFactory"
class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean"
id="sessionFac">
<property name="dataSource" ref="diplomDS"/>
<property name="annotatedClasses">
<list>
<value>my.diplom.entity.Application</value>
<value>my.diplom.entity.Category</value>
<value>my.diplom.entity.Event</value>
<value>my.diplom.entity.Message</value>
<value>my.diplom.entity.Order</value>
<value>my.diplom.entity.Project</value>
<value>my.diplom.entity.Resource</value>
<value>my.diplom.entity.Role</value>
<value>my.diplom.entity.Stat</value>
<value>my.diplom.entity.Status</value>
<value>my.diplom.entity.User</value>
<value>my.diplom.entity.Host</value>
<value>my.diplom.entity.Priority</value>
</list>
</property>
<property name="hibernateProperties">
<value>
hibernate.dialect=org.hibernate.dialect.MySQLInnoDBDialect
hibernate.show_sql=true
hibernate.format_sql=true
</value>
</property>
</bean>
<bean name="txManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
47
<bean name="abstractTransactionProxy"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
abstract="true">
<property name="transactionManager" ref="txManager"/>
<property name="transactionAttributes">
<props>
<prop key="find*">PROPAGATION_REQUIRED, readOnly
</prop>
<prop key="get*">PROPAGATION_REQUIRED, readOnly
</prop>
<prop key="create*">PROPAGATION_REQUIRED,-Exception
</prop>
<prop key="update*">PROPAGATION_REQUIRED,-Exception
</prop>
<prop key="delete*">PROPAGATION_REQUIRED,-Exception
</prop>
</props>
</property>
</bean>
<bean name="hibernateTemplate"
class="org.springframework.orm.hibernate3.HibernateTemplate">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
</beans>
DriverManagerDataSource – класс характеризующий источник данных приложения,
реализует интерфейс javax.sql.DataSource. Реализация этого интерфейса создает пул коннектов к
базе данных и может быть использована в системе JNDI какого-либо сервера Содержит такие
свойства как url до базы данных, имя пользователя и пароль. Используется для установления
соединения с базой данных.
AnnotationSessionFactoryBean - этот класс используется для создания SessionFactory от
Hibernate.
HibernateTransactionManager – используется для создания транзакций Hibernate.
TransactionProxyFactoryBean - это специальный интерсептор, который умеет открывать
транзакции и закрывать их в нужное время. Важно обратить внимание на параметры тэга
transactionAttributes. Они указывают, какие методы (точнее, какие маски) будут окружаться
транзакциями. Причем надо отметить, что есть транзакции только для чтения (readOnly) и есть
транзакции, которые будут реагировать на появление исключений - в случае генерации
исключения транзакция будет отменена. Надо обратить внимание, что этот бин объявлен как
абстрактный (смотрите атрибут abstract="true"). Данный класс используется как родитель у
классов-сервисов, описанных ранее.
НibernateTemplate – выполняющий запросы к базе данных через Hibernate. Используется
как член классов, реализующих работу с сущностями системы.
48
3.7 Spring MVC
Как уже говорилось выше, в основу концепции создания приложения лег паттерн МодельВид-Контроллер. Spring Framework предоставляют свою реализацию данного шаблона
проектирования, которую было и решено использовать при реализации системы.
В Spring MVC реализованы основные понятия MVC, готовые к применению. Модуль
содержит контроллеры и обработчики множества функций, связанных с данным шаблоном.
Добавление к MVC инверсии управления (IoC) делает приложение в значительной степени
развязанным, что обеспечивает гибкость изменения компонентов на лету при простых
изменениях конфигурации. Spring MVC предоставляет эффективное полное управление каждым
аспектом приложения.
Модуль Web MVC среды Spring разработан на основе DispatcherServlet.
DispatcherServlet
управляет запросами к обработчикам, выполняет построение представлений
и обрабатывает локальные и тематические представления, а также предоставляет поддержку для
выгружаемых файлов.
С помощью сопоставлений обработчиков DispatcherServlet определяет, какой
обработчик будет обрабатывать входящий запрос. Сопоставление обработчиков представляет
собой не что иное, как сопоставление, определяющее, какой обработчик использовать для
определенного шаблона URL. Обработчик представляет собой реализацию интерфейса Controller,
имеющего всего один метод ModelAndView handleRequest(request,response). В среде Spring
также имеются некоторые дополнительные реализации обработчиков, готовых к применению;
одним из важных обработчиков является SimpleFormController, предназначенный для работы с
формами, предоставляющий возможности и пр.
Рисунок 20 – Архитектура Spring MVC.
49
Конфигурация Spring MVC производится так же в отдельном файле, который называется
dispatcher-servlet.xml. В данном файле описываются все контроллеры, URL-маппинг,
показывающий, какой контроллер будет обрабатывать запрос согласно URL, описываются
валидаторы, которые проверяют объект во время его создания или изменения.
<bean name="createOrder" class="my.diplom.web.controllers.CreateOrderController">
<property name="orderService" ref="orderService"/>
<property name="projectService" ref="projectService"/>
<property name="statusService" ref="statusService"/>
<property name="userService" ref="userService"/>
<property name="categoryService" ref="categoryService"/>
<property name="priorityService" ref="priorityService"/>
<property name="applicationService" ref="applicationService"/>
<property name="hostService" ref="hostService"/>
<property name="resourceService" ref="resourceService"/>
<property name="formView" value="createOrder"/>
<property name="successView" value="createOrder"/>
<property name="validator">
<bean class="my.diplom.web.validators.CreateOrderValidator"/>
</property>
</bean>
<bean id="simpleUrlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/home.htm">home</prop>
<prop key="/register.htm">register</prop>
<prop key="/captcha.htm">captcha</prop>
<prop key="/admin/createOrder.htm">createOrder</prop>
<prop key="/user/createOrder.htm">createOrder</prop>
<prop key="/admin/createMessage.htm">createMessage</prop>
<prop key="/user/createMessage.htm">createMessage</prop>
</props>
</property>
</bean>
<bean id="viewResolver"
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass"
value="org.springframework.web.servlet.view.JstlView"></property>
<property name="prefix" value="/jsp/"></property>
<property name="suffix" value=".jsp"></property>
</bean>
Из примера видно, что описываемый контроллер использует в качестве членов своего
класса множество сервисов, необходимых в процессе работы. К Spring MVC так же применима
концепция IoC, которая позволяет описывать зависимости между объектами. В
конфигурационном файле достаточно указать, какие сервисы будет использовать контроллер.
50
Spring сам проинициализирует все объекты сервисов при создании объекта контроллера,
программисту не надо об это заботиться. Описал и пользуйся.
Помимо самого контроллера в примере описан экземпляр класса
SimpleUrlHandlerMapping, который устанавливает, какой URL будет обрабатываться каким
контроллером.
Описан экземпляр класса InternalResourceViewResolver, который отвечает за работу с jspстарницами, т.е. видом, на который контроллер передает данные.
3.8 Spring Sequrity
Spring Security это Java/Java EE фреймворк, предоставляющий механизмы построения
систем аутентификации и авторизации, а также другие возможности обеспечения безопасности
для промышленных приложений, созданных с помощью Spring Framework.
В разрабатываемой системе Spring Sequrity применяется для механизмов аутентификации
в приложений, механизмов доступа к данным и доступа к страницам приложения.
Конфигурация описывается в отдельной файле security-applicationContext.xml
<http access-denied-page="/jsp/403.jsp">
<intercept-url
<intercept-url
<intercept-url
<intercept-url
<intercept-url
pattern="/jsp/index.jsp" access="ROLE_ADMIN, ROLE_USER"/>
pattern="/user.htm*" access="ROLE_ADMIN, ROLE_USER"/>
pattern="/user/**" access="ROLE_ADMIN, ROLE_USER"/>
pattern="/admin.htm*" access="ROLE_ADMIN"/>
pattern="/admin/**" access="ROLE_ADMIN"/>
<form-login
login-page="/jsp/login.jsp"
default-target-url="/jsp/index.jsp"
authentication-failure-url="/jsp/401.jsp"
/>
<logout
logout-url="/jsp/logout.jsp"
logout-success-url="/jsp/login.jsp"
invalidate-session="true"
/>
</http>
<beans:bean id="authenticationDao"
class="org.springframework.security.userdetails.jdbc.JdbcDaoImpl">
<beans:property name="dataSource" ref="diplomDS"/>
<beans:property name="usersByUsernameQuery">
<beans:value>
SELECT login, password, 'true' as enabled
FROM users
WHERE login = ?
</beans:value>
</beans:property>
<beans:property name="authoritiesByUsernameQuery">
<beans:value>
51
select login, rolename from users
inner join statuses ON users.statusId = statuses.statusId
inner join roles ON users.roleId = roles.roleId
where statuses.statusName = 'active' and users.login = ?
</beans:value>
</beans:property>
</beans:bean>
Стоит так же сказать, что Spring Sequrity, это sequrity на уровне приложения, а не на
уровне сервера приложений и его realm’ов. Данный выбор обусловлен наличием множества
готовых классов и фильтров, для обеспечения требуемого уровня безопасности.
Чтобы Spring Sequrity вообще заработал, в дескрипторе развертывания приложения
указывается специальный фильтр, который через себя будет пропускать все запросы, проверяя,
соответствует ли роль пользователя запрошенной информации и.п.
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>
org.springframework.web.filter.DelegatingFilterProxy
</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
В приведенной конфигурации особенно хочется отметить отображение URL страниц на
роли пользователей, которым разрешен доступ к данным страницам. Если роль пользователя не
соответствует запрашиваемой странице, тогда систем а его отправляет на страницу, на которой
система отображает код 403, говорящий что доступ к данной странице запрещен.
В конфигурации также стоит отметить объект authenticationDao, который отвечает за
получение информации о пользователе, его роли из базы данных.
Ограничение доступа к данным на страницах осуществляется с помощью специальных
тегов, входящих в библиотеку тегов Spring.
<security:authorize ifAllGranted="ROLE_ADMIN">
<c:if test="${statuces ne null}">
<tr>
<td>Status <span class="required">*</span></td>
<td><form:select path="status">
<form:options items="${statuces}" itemValue="statusId"
itemLabel="alias"/>
</form:select>
</td>
<td><form:errors path="status" cssStyle="color:red"/></td>
</tr>
</c:if>
</security:authorize>
52
3.9 Jasper Reports
JasperReports – это Java-библиотека для создания отчетов. На основе XML-шаблонов
отчетов генерируются готовые для печати документы, консолидирующие данные из различных
источников, в т.ч. JDBC. Отчеты могут выводиться на экран, принтер либо в форматы PDF,
HTML, XLS, CSV и XML. Есть система подотчетов для вывода дополнительной информации.
В рассматриваемой ВКР данная библиотека была успешно проинтегрирована с
платформой Spring, на которой базируется все приложение, это позволило избежать написания
лишнего кода и сохранить единообразие приложения. Возможно получение отчетов о
пользователях и ресурсах, занесенных в систему (Рисунок 21):
Рисунок 21 – Пример отчета в формате PDF.
Пример кода отчета:
<textField>
<reportElement x="138" y="53" width="200" height="20"/>
<textElement>
<font fontName="DejaVuSans"
pdfEncoding="Cp1251"
isPdfEmbedded="true"/>
</textElement>
<textFieldExpression class="java.lang.String"><![CDATA[$F{lastName} + "
" + $F{firstName}]]></textFieldExpression>
</textField>
53
3.10 Simile Timeline
Simile Timeline представляет из себя javascript библиотеку для создания и отображения
различных событий на полосе времени (timeLine). События могут быть как продолжительными,
так и точечными. При щелчке на событие доступно описание, куда можно вставить и текстовую
и графическую информацию. На таймлайне доступна шкала времени, на которой собственно и
отображаются события. Что хорошо, данная шкала может масштабироваться начиная от минут и
заканчивая десятилетиями.
Для построения таймлайна (рисунок 20) библиотеке необходимо передать данные либо в
формате xml, либо в формате json.
В процессе разработки системы били предприняты попытки модификации библиотеки,
для того, чтобы появилась возможность вставлять одно событие с другое.
При этом внешнее событие изображенное в виде линии позиционируется как ресурс в
понятиях системы, внешнее событие позиционируется как событие на ресурсе.
Событие
Ресурс
Рисунок 20 – Таймлайн.
Функция построения таймлайна.
function onLoad(f1, div, hostId, value) {
var eventSource = new Timeline.DefaultEventSource();
var theme = Timeline.ClassicTheme.create('ru'); // create the theme
theme.event.bubble.width = 300;
// popup window width
theme.event.bubble.height = 300; // popup window height
theme.event.track.height = 15;
theme.event.tape.height = 18; // line height
var bandInfos = [
Timeline.createBandInfo({
54
eventSource:
width:
intervalUnit:
intervalPixels:
theme:
layout:
eventSource,
"70%",
f1,
200,
theme,
'original'
}),
Timeline.createBandInfo({
overview:
true,
eventSource:
eventSource,
width:
"30%",
intervalUnit:
SimileAjax.DateTime.YEAR,
intervalPixels: 300
}),
];
bandInfos[1].syncWith = 0;
bandInfos[1].highlight = true;
eventSource.loadJSON(value, url);
tl.layout();
}
Подготовкой данных в формате json занимается специальный утилитарный класс,
которому на вход подается информация о ресурсах хоста, а на выходе получается json вида:
{
"wiki-url":"http://simile.mit.edu/shelf/",
"wiki-section":"Simile JFK Timeline",
"dateTimeFormat":"Gregorian",
"events":[
{
"start":"Tue Nov 3 2009 00:00:00 +0300",
"end":"Sat Mar 27 2010 00:00:00 +0300",
"trackNum":"1",
"title":"Pskov",
"description":"Firewall 172.16.215.19<br/><strong>CPU:</strong>2.0 GHz<br/
><strong>RAM:</strong>2.0 GB<br/><strong>HDD:</strong>200.0 GB<br/><strong>Involved
projects:</strong><br>",
"color":"red",
"durationEvent":true
},
{
"start":"Tue Dec 8 2009 04:08:18 +0300",
"end":"Sat Dec 12 2009 01:04:23 +0300",
"trackNum":"1",
"title":"Backup",
"description":"xffvzxc",
"color":"green",
"isChild":"true",
"classname":"my-event",
"durationEvent":true
},
{
"start":"Mon Sep 1 2008 00:52:56 +0400",
"end":"Sat Apr 17 2010 07:56:08 +0400",
"trackNum":"2",
"title":"vrnpwpsr2",
"description":"Тупо описание 172.12.18.250<br/><strong>CPU:</strong>2.0 GH
z<br/><strong>RAM:</strong>2.0 GB<br/><strong>HDD:</strong>100.0 GB<br/><strong>Inv
olved projects:</strong><br>Voronezh<br>",
"color":"blue",
"durationEvent":true
55
}
]
}
Модифицированная часть библиотеки
Timeline.OriginalEventPainter.prototype.paint = function() {
var C = this._band.getEventSource();
if (C == null) {
return;
}
this._eventIdToElmt = {};
this._fireEventPaintListeners("paintStarting", null, null);
this._prepareForPainting();
var I = this._params.theme.event; // theme
var G = Math.max(I.track.height, I.tape.height + this._frc.getLineHeight());
var F =
{trackOffset:I.track.offset,trackHeight:G,trackGap:I.track.gap,trackIncrement:G +
I.track.gap,icon:I.instant.icon,iconWidth:I.instant.iconWidth,iconHeight:I.instant.
iconHeight,labelWidth:I.label.width,maxLabelChar:I.label.maxLabelChar,impreciseIcon
Margin:I.instant.impreciseIconMargin};
var D = this._band.getMinDate();
var B = this._band.getMaxDate();
var J = (this._filterMatcher != null) ? this._filterMatcher : function(K) {
return true;
};
var A = (this._highlightMatcher != null) ? this._highlightMatcher : function(K)
{
return -1;
};
var E = C.getEventReverseIterator(D, B);
var t = Timeline.ClassicTheme.create(); //создание новой темы для событий
t.event.bubble.width = 300;
t.event.bubble.height = 300;
t.event.track.height = 15;
t.event.tape.height = 9;
while (E.hasNext()) {
var H = E.next();
if (J(H)) {
if (H._obj.classname) {
// если событие наше, то применяем другую
тему
this.paintEvent(H, F, t, A(H));
} else {
this.paintEvent(H, F, this._params.theme, A(H));
}
}
}
this._highlightLayer.style.display = "block";
this._lineLayer.style.display = "block";
this._eventLayer.style.display = "block";
this._band.updateEventTrackInfo(this._tracks.length, F.trackIncrement);
this._fireEventPaintListeners("paintEnded", null, null);
};
56
Глава 4. Экономическое обоснование ВКР
4.1 Определение товарного типа объекта разработки
Товарный тип объекта разработки устанавливается путем анализа рыночной цели его
создания. С этой точки зрения выделяются следующие типы:

Разработки, выполняемые с коммерческой целью, то есть предназначенные для
реализации на рынке. Общей характерной чертой таких разработок является более или
менее широкий спрос на их результаты на рынке (наличие нескольких потребителей).
Такие разработки могут быть двух типов: имеющие рыночный аналог и не имеющие
рыночного аналога. Аналогом объекта разработки считается объект, имеющий
аналогичное функциональное назначение и являющийся лучшим по своим техникоэксплуатационным характеристикам на данный момент времени.

Разработки, выполняемые с некоммерческой целью, то есть не предназначенные для
прямой или косвенной реализации на рынке.
Целью данной ВКР является создание программного продукта, предназначенного для
учета и сопровождения распределенных ресурсов организации.
Продукт не предназначен для прямой или косвенной реализации на рынке товаров и
услуг, ввиду экспериментального характера разработки, а так же большого упора на
расширяемость приложения с помощью сторонних разработчиков. Предназначен для
внутреннего использования. Таким образом, разработка относится к некоммерческому типу.
Отнесение разработки к некоммерческому типу служит основанием для определения
состава расчетов в экономической части. Согласно данному определению, может быть выполнен
только лишь расчёт сметы затрат на разработку проекта.
4.2 Расчет сметы затрат на разработку
В состав сметной стоимости разработки входят следующие статьи затрат:

материалы, покупные изделия и полуфабрикаты;

специальное оборудование для проведения разработки;

основная заработная плата разработчиков;

дополнительная заработная плата;

отчисления на социальные нужды;

затраты на электроэнергию для технологических целей;

контрагентские работы;
57

затраты на командировки;

прочие затраты;

накладные расходы.
Сметная стоимость определяется методом сметного калькулирования, основанном на
прямом определении затрат по отдельным статьям.
4.2.1 Расчет стоимости расходных материалов
Стоимость расходных материалов (Cn) рассчитываются по действующим рыночным
ценам, следующим образом:
n
Сп   N i  Ц i
i1
,
где n – номенклатура примененных расходных материалов, Ni – количество расходных
материалов данного вида, Цi – цена расходных материалов данного вида.
Затраты, связанные с покупными изделиями, представлены в таблице 3 и 4.
Таблица 3 - Стоимость расходных материалов
№
п/п
1
2
Наименование
материалов,
покупных изделий и
полуфабрикатов
Бумага д/принтера
Картридж для
принтера (ч/б)
Ед.
измерения
Кол-во
Цена
единицы
(руб.)
Сумма
(руб.)
Итого
материальных
затрат (руб.)
упак. (500 л.)
1
300
300
300
шт.
1
600
600
600
Итого:
900
Затраты на материалы, покупные изделий и полуфабрикаты составляют:
С м  1 300  1 600  900  руб
Стоимость программных продуктов не учитывается, т.к. при разработке данного проекта
использовались бесплатные программы, либо программы, имеющие бесплатные версии
–
NetBeans IDE, Eclipse IDE
–
Notepad++
–
Visual Paradigm for UML
–
MySql Manager
58
4.2.2 Расчет стоимости специального оборудования и амортизации
Стоимость специального оборудования для проведения разработки (Соб) рассчитывается в
зависимости от его наличия. При использовании наличного оборудования в смету включаются
автоматизированные отчисления по нормативам.
Амортизация оборудования (Соб) рассчитывается прямым способом исходя из стоимости
оборудования, срока службы оборудования и времени его использования.
m
C   ( Н а Ц )tn
oб i1
об
,
где m – количество видов специально оборудования;
НA – годовая норма амортизационных отчислений;
Цоб – цена единицы i-го вида оборудования;
tn – время использования оборудования для работы.
Таблица 4 – Амортизация оборудования
№
п/п
1
2
Номенклатура
специального
оборудования
Ноутбук Dell
Inspiron 1520
Принтер
Canon
LBP3000
Кол-во
Цена
единицы
(руб.)
Время
использ.
(лет)
Годовая
норма
амортизац.
отчислений
(руб)
Итого
стоимость
специального
оборудования
(руб.)
4
1
32000
0.33
8000
2666
3
1
3200
0.2
1066
213
Срок
службы
(лет)
Итого:
2879
Стоимость специального машинного времени, затраченного на разработку проекта (Смаш)
рассчитывается по следующей формуле:
Смаш = Сi * t0,
где Сi – стоимость одного часа машинного времени, t0 - время на разработку программы.
Стоимость одного часа времени на момент расчетов составляет 40 рублей (Сi =40), а
стоимость одного часа доступа к Internet – 2 рубля (Сi =2).
Работа за компьютером около 4 месяцев, в месяце в среднем 23 рабочих дня, что при
работе разработчика по 3 часа в день составляет 276 часов машинного времени, включая 100
часов доступа к Интернету.
59
При подстановке этих данных получаем:
Смаш = 276 *40 + 100*2 =11240 , т.о. Соб= 11240 + 2879= 14119 руб.
4.2.3 Расчет основной заработной платы разработчиков
Основная заработная плата (Сос) вычисляется по следующей формуле:
k
Coc   П pj  Зmj  P ,
j 1
где k –номенклатура категорий разработчиков, Прi – количество разработчиков, Зmi –
среднечасовая заработная плата данной категории разработчиков, Рi – продолжительность
работы, выполненной работником определенной категории (часов).
Разработчиками будут считаться автор проекта и руководитель данного проекта.
Ежемесячная заработная плата автора проекта принята в размере 18000 рублей. Таким
образом, из соображений того, что стандартный рабочий день – 8-часовой, а рабочих дней в
каждом месяце по 23, среднечасовая заработная плата автора проекта рассчитывается
следующим образом:
Зm1 = 20000/(8*23) = 109 руб.
Среднечасовая заработная плата руководителя проекта рассчитывается с учетом того,
что его средняя ежемесячная заработная плата составляет 20000 рублей. Если его рабочий день
тоже считать 8- часовым, а количество рабочих дней в месяц принять равным 23, то получим
такую среднечасовую заработную плату:
Зm2 = 25000/(8*23) = 136 руб.
Данные по часовой нагрузке разработчиков представлены в таблице 5.
Таблица 5 - Список задач и их трудоемкости
№
Программист
Наименование задачи
Руководитель
Время исполнения, ч.
1
Уточнение и анализ задачи
23
15
2
Анализ существующих подобных решений.
19
18
3
Разработка архитектуры приложения
31
25
4
Расчет себестоимости реализации проекта
7
-
5
Разработка и проектирование базы данных
48
-
6
Изучение новых технологий
29
-
7
Разработка системы
90
-
8
Оценка «пилотного» внедрения и документирование
13
11
9
Разработка рекомендаций по внедрению проекта, а
16
-
60
также по обеспечению безопасности жизнедеятельности
Итого:
276
69
Значит,
2
Сос   Зmi  Pi = 109*276 + 136*69 = 39468
i1
руб.
4.2.4 Расчет дополнительной заработной платы
Дополнительная заработная плата (Сдоп) определяется по следующей формуле:
C d
C
 oc ,
доп 100
где d- норматив затрат на дополнительную заработную плату от основной, причем
d=10…15%. Примем d=12%. Значит, имеем:
Сдоп = 39468 *12/100 = 4736 руб.
4.2.5 Расчет единого социального налога
Единый социальный налог (Ссн) определяется по формуле:
Cсн 

С
 oс

С
r
доп  ,
100
где r- суммарная величина единого социального налога (на данный момент составляет
26%). Следовательно,
Ссн = (39468 +4736)*26/100 = 11493 руб.
4.2.6 Расчет затрат на электроэнергию для технических целей
Затраты на электроэнергию для технологических целей определяются по формуле:
l
С эн   Wi Ti C kr ,
i 1
где l – номенклатура оборудования, используемого для разработки;
Wi – мощность оборудования по паспорту, кВт;
Ti– время использования для проведения разработки, час;
Ckr – стоимость одного кВт/час электроэнергии, руб.;
61
Kwi – коэффициент использования мощности (Kwl<1).
Мощность оборудования по паспорту Wi составляет 90 Вт или 0,09 кВт
Стоимость одного кВт/час электроэнергии Ckr составляет 1,85 руб.
Время использования оборудования для проведения разработки рассчитывается
следующим образом:
Ti = 3*23*4 = 276 часов
Затраты на электроэнергию для технологических целей составляют:
Сэн  0,09  276 1,85  0,8  37 руб
4.2.7 Расчет затрат на контрагентские работы
Затраты по данному пункту равны нулю.
4.2.8 Расчет затрат на командировки
Затраты по данному пункту равны нулю.
4.2.9 Расчет прочих затрат
К прочим затратам (Спр) относятся затраты, связанные с оплатой консультаций, экспертиз,
арендой помещений и т.д. Опираясь на статистическую информацию, накопленную в ходе
выработки рекомендаций, эти затраты составляют 8% от суммарной величины предыдущих
статей и равняются:
Спр = 70753*0,08 = 5660 руб.
4.2.10 Расчет накладных расходов
Накладные расходы (Сн) начисляются в процентах к основной заработной плате, и в
процессе разработки они составили 25% от неё.
Сн =39468 *25/100 = 9867 руб.
62
4.2.11 Общая сметная стоимость проекта
Общая сметная стоимость разработки (Ср) определяется суммированием всех ее
составляющих, то есть: Ср =Сn + Соб + Сос + Сдоп +Ссн + Сэн + Спр +Сн
В таблице 6 приведены все статьи расходов и затраты по ним.
Таблица 6 – Общая сметная стоимость разработки
№
п/п
1
2
3
4
5
6
7
8
9
10
Статьи расходов
Условные
Затраты по статьям
обозначения
(руб)
См
Материалы
Специальное оборудование
Соб
+ амортизация
Сос
Основная з/п
Сдоп
Дополнительная з/п
Соф
Отчисления в соц. Фонды
Сэн
Затраты на электроэнергию
Сн
Прочие затраты
Сп
Накладные расходы
Контрагентские работы
Ск
Затраты на командировки
Ском
Общая сметная стоимость:
900
14119
39468
4736
11493
37
5660
9867
0
0
86280
Стоимость данной разработки составляет примерно 86280 рублей.
4.3 Вывод
В данной главе рассмотрены основные экономические характеристики проекта, и сделан
расчет сметы затрат на его разработку, составляющий 86280 рублей.
В связи с тем, что разработка данного проекта требует относительно небольших денежных
затрат, она является достаточно экономичной, выгодной и рациональной.
63
Глава 5. Безопасность жизнедеятельности
5.1 Описание условий эксплуатации проектируемой программы
Работа администратора/пользователя системы подразумевает продолжительную работу с
компьютером, при которой осуществляется просмотр выводимой на экран графической и
текстовой информации, а также создание и редактирование текста стандартными устройствами
ввода (мышь, клавиатура). При этом излучение монитора воздействует на его органы зрения,
использование клавиатуры и мыши увеличивает нагрузку на суставы рук, шумы монитора
повышают раздражительность человека и воздействуют на его центральную нервную систему.
Таким образом, пользователь приложения подвергается всем вредным воздействиям, типичным
для стандартного пользователя ПК. В данной ситуации особенно актуальным становится
контроль равномерной работы за компьютером с соответствующими перерывами.
5.2 Анализ и выявление потенциально опасных и вредных факторов
В этом разделе дана оценка безопасным условиям труда в соответствии с нормативнотехнической документацией на стадиях разработки и эксплуатации программного комплекса.
К основным типам потенциально опасных и вредных факторов относятся:

физические;

химические;

психофизиологические;

биологические.
За окружающую среду разработчиков и пользователей системы приняты офисные
аудитории. В помещениях негативное воздействие оказывают следующие физические факторы:

микроклиматические факторы (температура, относительная влажность, скорость
движения воздуха);

факторы освещенности;

шум;

электромагнитное излучение.
К химически опасным факторам, постоянно действующим в условиях работ в помещении,
относятся активные частицы, возникающие в результате ионизации воздуха вследствие работы
компьютера.
К вредным психофизиологическим факторам, действующим на человека в течение его
рабочего времени, можно отнести:
64

нервно-эмоциональные перегрузки;

умственное напряжение;

перенапряжение зрительного анализатора.
Вредные биологические производственные факторы в офисных аудиториях отсутствуют.
5.2.1 Микроклиматические факторы
Микроклимат офисных помещений – это климат внутренней среды этих помещений,
определяющийся действующими на организм человека сочетаниями температуры, влажности и
скорости движения воздуха. Требования к микроклиматическим факторам для офисных
аудиторий устанавливает ГОСТ 12.1.005-88.
Офисные аудитории относятся к помещениям 1 категории (в них выполняются легкие
физические работы), поэтому соблюдаются требования, приведенные в таблице 7:
Таблица 7 – Требования к микроклиматическим факторам
Фактор
Температура воздуха
Оптимальное значение
22оС
Допустимое значение
20-24 оС
Относительная влажность
Скорость движения воздуха
40-60%
не более 0.1 м/сек
не более 75%
не более 0.1 м/сек
5.2.2 Факторы освещенности
Работа, выполняемая с использованием вычислительной техники, имеет следующие
недостатки:

вероятность появления прямой блесткости;

ухудшенная контрастность между изображением и фоном;

отражение экрана.
5.2.3 Факторы шума
В помещениях с низким уровнем общего шума, какими являются офисные аудитории,
источниками шумовых помех могут стать вентиляционные установки, кондиционеры и
периферийное оборудование для ЭВМ (плоттеры, принтеры и т.д.). Длительное воздействие этих
шумов отрицательно сказывается на эмоциональном состоянии персонала. Согласно ГОСТ
12.1.003-83 ССБТ, эквивалентный уровень шума не должен превышать 50 дБА.
65
5.2.4 Факторы электромагнитного поля
Электромагнитные
поля,
характеризующиеся
напряженностями
электрических
и
магнитных полей, наиболее вредны для организма человека. Основным источником этих
проблем,
связанным
с
охраной
здоровья
людей,
использующих
в
своей
работе
автоматизированные информационные системы на основе персональных компьютеров, являются
дисплеи (мониторы), особенно дисплеи с электронно-лучевыми трубками. Они представляют
собой источник наиболее вредных излучений, неблагоприятно влияющих на здоровье
пользователя.
ПЭВМ являются источниками таких излучений как:

мягкого рентгеновского;

ультрафиолетового;

видимого;

ближнего инфракрасного;

радиочастотного;

электростатического.
Предельно допустимые значения характеристик ЭМП в соответствии с ГОСТ 12.1.006-84
указаны в таблице 8:
Таблица 8 - Предельно допустимые значения характеристик ЭМП
Параметр
Значение
Напряженность электромагнитного поля по электрической
составляющей на расстоянии 50 см от поверхности монитора
Напряженность электромагнитного поля по магнитной
составляющей на расстоянии 50 см от поверхности монитора
10 В/м
0.3 А/м
Напряженность электростатического поля
20 кВ/м
Напряженность электромагнитного поля на расстоянии 50 см
25 В/м
вокруг ВДТ по электрической составляющей
2.5 В/м
Плотность магнитного потока:
250 нТл
- в диапазоне частот 5 Гц – 2 кГц;
- в диапазоне частот 2 – 400 кГц.
Поверхностный электростатический потенциал
25 нТл
66
500 В
5.2.5 Микроклимат рабочей зоны
Для создания и автоматического поддержания в помещении
соответствии с ГОСТ
12.1.005-88 независимо от наружных условий оптимальных значений температуры, чистоты и
скорости движения воздуха, в холодное время года используется водяное отопление, а в теплое
время года применяется кондиционирование воздуха. Кондиционер представляет собой
вентиляционную установку, которая с помощью приборов регулирования поддерживает в
помещении заданные параметры воздушной среды.
5.3 Описание мероприятий, обеспечивающих безопасность программы
5.3.1 Освещение рабочей зоны
Степень освещенности рабочей зоны устанавливает СНиП 23-05-95. На основе
поверхности рабочей зоны, задания и вида деятельности, рабочие условия могут быть отнесены к
категории «Задания со средними требованиями и условиями зрительного восприятия». Разряд
работ и тип рабочей зоны представлены в таблице 9:
Таблица 9– Разряд работ и тип поверхности рабочей зоны
Разряд работ
Высокой точности
Контраст
Большой
Фон
Светлый
В соответствии с ГОСТ, минимальной освещенностью для данной категории является
освещенность в 300 лк, т.к. минимальный размер объекта различения составляет 0.15-0.3 см.
Естественного освещения не достаточно, и на рабочем месте должно применяться искусственное
освещение.
5.3.2 Расчет искусственного освещения
Размещение светильников определяется следующими размерами:

высота помещения, H (H= 3м);

расстояние светильников от перекрытия, hc (hc = 0.25м );

высота светильников над полом, hn (hn= H-hc = 2.75м);

для помещений, связанных с работой ПЭВМ - высота расчетной поверхности hp, (hp =
0.7м);

расчетная высота, h (h = hn – hp = 2.05м).
67
Для освещения применяются два светильника типа ЛДР (2x40Вт), длина которых равна 1.24 м, ширина 0.27 м, высота - 0.1 м.
При этом рассматриваются следующие параметры:

L –
расстояние между соседними
светильниками (рядами люминесцентных
светильников);

La (по длине помещения) = 1.76 м;

Lb (по ширине помещения) = 3 м;

l – расстояние от крайних светильников или рядов светильников до стены;

la=0.5La=0.88 м;

lb=0.3Lb=0.73 м.
Светильники с люминесцентными лампами в помещениях для работы установлены
рядами. Метод коэффициента использования светового потока предназначен для расчета общего
равномерного освещения горизонтальных поверхностей при отсутствии крупных затемняющих
предметов. Расчет потребного потока ламп в каждом светильнике определяется по формуле:

ErS Z
,
N 
(11)
где E – нормируемая минимальная освещенность равная 300 лк;
r – коэффициент запаса, равный 1.3 (для помещений связанных с работой ПЭВМ);
S – освещаемая площадь равная 30 м2;
z – коэффициент, характеризующий неравномерное освещение; принимается равным
1.1 в связи с превышением допустимого значения параметра λ.
N – число светильников.
Первоначально намечается число рядов, которое подставляется вместо N, тогда φ - поток
ламп одного ряда, η – коэффициент использования. Для нахождения η выбирают индекс
помещения i, и предположительно оцениваются коэффициенты отражения поверхностей
помещения
ρп(потолка)=70%,
ρс(стен)=50%,
ρр(пола)=30%.
Для
обеспечения
общей
освещенности применяются светильники с общим потоком 5700 лм. Светильники помещаются в
ряд длиной 4 метра. Рассчитанная норма потребного потока ламп
- 21450 лм,
тогда как
используемые светильники обеспечивают поток 22100 лм. Таким образом, искусственное
освещение обеспечивает требуемую степень освещенности рабочих мест.
5.3.3 Защита от шума
В качестве мер по снижению шума можно предложить следующее:

облицовка потолка и стен звукопоглощающим материалом (снижение шума
на 6-8 дБ);
68

экранирование рабочего места (постановкой перегородок, диафрагм);

установка в компьютерных помещениях оборудования, производящего минимальный
шум;

рациональная планировка помещения.
Защиту от шума следует выполнять в соответствии с ГОСТ 222/2.4.1340-03, а
звукоизоляция ограждающих конструкций должна отвечать требованиям главы СНиП 23-03-2003
«Защита от шума и акустика».
5.3.4 Защита от повышенного уровня напряженности электромагнитного поля
Для предупреждения внедрения опасной техники все дисплеи должны проходить
испытания на соответствие требованиям безопасности (например, международные стандарты
MRP 2, TCO 03).
Так как работа программиста и пользователей по виду трудовой деятельности относится к
группе «В» (творческая работа в режиме диалога с ЭВМ), а по напряженности работы ко II
категории тяжести (СанПиН 2.2.2/2.4.1340-03), предлагается сократить время работы за
компьютером, делая перерывы, суммарное время которых должно составлять 50 минут при 8
часовой смене. Своевременные перерывы в работе можно контролировать с помощью
специализированных программ, таких как EyesRelax, EyeLoveU и т.д. Программы каждые 30
минут закрывают «Рабочий стол» компьютера на 5 минут, в течение которых рекомендуется
посидеть с закрытыми глазами. Об окончании перерыва пользователь информируется звуковым
сигналом.
5.3.5 Организация рабочего места
Антропологические характеристики человека определяют габаритные и компоновочные
параметры его рабочего места, а также свободные параметры отдельных его элементов.
Производственная
деятельность
заставляет
сотрудников
продолжительное
время
находиться в сидячем положении, поэтому организм постоянно испытывает недостаток в
подвижности и активной физической деятельности. При выполнении работы в сидячем
положении большую роль играет плечевой пояс. Перемещение рук в пространстве влияет не
только на работу мышц плечевого пояса и спины, но и на положение позвоночника, таза и даже
ног.
По условиям работы рабочее место оператора ЭВМ относится к индивидуальному
рабочему месту для работы сидя.
69
В соответствии с ГОСТ 12.1.003-83 ССБТ, рабочее место занимает площадь не менее 6 м²,
высота помещения не менее 4 м, а объем – не менее 20 м3 на одного человека. После проведения
анализа рабочего места в офисном помещении было выяснено, что площадь данного рабочего
места составляет 4 м2, а объем 12 м3, что не соответствует приведенным требованиям. Также в
результате анализа были выявлены нарушения в организации непосредственно самого рабочего
места. В связи с этим изменена организация рабочего места следующим образом:

высота над уровнем пола рабочей
поверхности, за которой работает оператор,
составляет 720 мм;

рабочий стол оператора регулируется по высоте в пределах 680 – 780 мм (оптимальные
размеры поверхности стола 1600х1000 мм2);

под
столом
имеется
пространство
для
ног
с
размерами
по
глубине
650 мм;

рабочий стол оператора имеет подставку для ног, расположенную под углом 15° к
поверхности стола (длина подставки 400 мм, ширина - 350 мм);

удаленность клавиатуры от края стола не более 300 мм, что обеспечивает оператору
удобную опору для предплечий;

расстояние между глазами оператора и экраном видеодисплея составляет 40 – 80 см;

рабочий стул снабжен подъемно-поворотным механизмом;

высота сиденья регулируется в пределах 400 – 500 мм;

глубина сиденья составляет больше 380 мм, а ширина – больше 400 мм;

высота опорной поверхности спинки больше 300 мм, ширина – не меньше 380 мм;

угол наклона спинки стула к плоскости сиденья изменяется в пределах 90 – 110°.
5.4 Пожарная безопасность
Пожарная безопасность обеспечивается системой предотвращения пожара и системой
пожарной защиты. В служебных помещениях вывешены «Планы эвакуации людей при пожаре»,
регламентирующие действия персонала в случае
возникновения очага возгорания и
указывающие места расположения пожарной техники.
Противопожарная защита достигается применением следующих способов в соответствии
с ГОСТ 12.1.004—91 «Пожарная безопасность. Общие требования» и ГОСТ 12.1.010—76
«Взрывобезопасность. Общие требования».
Общие требования:

применение средств пожаротушения и соответствующих видов пожарной техники,
применение автоматических установок пожарной сигнализации и пожаротушения;
70

применение основных строительных конструкций и материалов, в том числе
используемых для облицовок конструкций, с нормированными показателями
пожарной опасности;

применение пропитки конструкций объектов антипиренами и нанесением на их
поверхности огнезащитных красок (составов);

устройства, обеспечивающие ограничение распространения пожара;

организация
с
помощью
технических
средств,
включая
автоматические,
своевременного оповещения и эвакуации людей;

применение средств коллективной и индивидуальной защиты людей от опасных
факторов пожара;

применение средств противодымной защиты.
5.4.1 Причины возникновения пожара
Причинами возникновения пожара могут быть:

неисправность электропроводки, розеток и выключателей, которые могут привести к
короткому замыканию или пробою изоляции;

использование поврежденных (неисправных) электроприборов;

использование
в
помещении
электронагревательных
приборов
с
открытыми
нагревательными элементами;

возникновение пожара вследствие попадания молнии в здание;

возгорание здания вследствие внешних воздействий;

неаккуратное обращение с огнем и несоблюдение мер пожарной безопасности.
5.4.2 Профилактика возгораний
Пожарная профилактика представляет собой комплекс организационных и технических
мероприятий, направленных на обеспечение безопасности людей, на предотвращение пожара,
ограничения его распространения, а так же создания благоприятных условий для его успешного
тушения. Для профилактики пожара крайне важна правильная оценка пожарной опасности
здания, определение опасных факторов и обоснование способов и средств предупреждения и
защиты. Одно из условий обеспечения пожарной безопасности - ликвидация возможных
источников возгорания, которые были рассмотрены выше.
В целях предотвращения пожара, инженерами, работающими в офисных аудиториях,
проводится противопожарный инструктаж, а так же обучение использованию первичных средств
пожаротушения.
71
В случае возникновения пожара, первым делом необходимо обесточить электроприборы,
вызвать по телефону пожарную команду, эвакуировать людей из здания согласно плану
пожарной эвакуации. При наличии небольшого очага возгорания можно использовать подручные
средства для предотвращения поступления воздуха к объекту возгорания.
Выводы
В данном разделе выявлены вредные, опасные факторы, способные привести к риску для
здоровья и жизни человека (а так же профессиональным заболеваниям):

факторы освещенности;

микроклиматические факторы;

факторы электромагнитного поля.
Обозначены меры устранения потенциально опасных и вредных факторов.
Был произведен расчет освещения. Рассчитанная норма потребного потока ламп
составляет 21450 лм; используемые светильники обеспечивают 22100 лм, что отвечает
вышеуказанной норме.
Таким образом, обеспечиваемое искусственное освещение
обеспечивает требуемую степень освещенности рабочих мест.
Рассмотрены вопросы пожарной безопасности, выявлены вероятные источники
возгорания и описаны меры противопожарной безопасности и профилактики возгораний.
72
Заключение
В процессе работы над выпускной квалификационной работой была спроектирована и
разработана система учета и сопровождения распределенных ресурсов, предназначающаяся для
организаций, разрабатывающих программное обеспечение.
Разработанный программный продукт позволил существенно облегчить работу
системного администратора и разработчиков в области выделения/получения ресурсов для
разработки, в области наблюдения за ресурсами, весь процесс стал проще и прозрачнее. Был
разработан достаточно широкий функционал.
Для пользователя доступен следующий функционал:

средство подачи заявок на ресурсы;

средство обмена сообщениями;

средство наблюдения выделенных ему ресурсов;

возможность создания разного рода событий на ресурсах.
Для администратора доступен более широкий функционал:

просмотр, удовлетворение, отклонение заявок;

средство наблюдения всех за всеми ресурсами, занесенными в систему;

средства управления ресурсами/пользователями/ПО;

средство получения отчетов в различных форматах;

возможность создания разного рода событий на ресурсах;

возможность сохранения информации о физических хостах.
Кроме того, в процессе работы были подготовлены рекомендации по оборудованию
рабочего места оператора компьютера, соблюдению норм и правил техники безопасности при
работе на компьютере, подсчитаны экономические характеристики разработки.
В перспективе планируется работать над общей интеллектуальность системы, которая
будет выдавать некие рекомендации при создании ресурсов, уведомлять пользователей при
изменении чего-либо и т.п. Также планируется создать базу знаний по характерным вопросам,
которые могут возникнуть в процессе работы.
Таким образом, можно считать, что актуальность ВКР раскрыта полностью, поставленные
цели достигнуты.
73
Список использованных источников
1 В.И. Грекул. Проектирование информационных систем [Электронный ресурс].
Интернет университет информационных технологий, 2005.
2 Craig Walls, Ryan Breidenbach. Spring in action. Second edition. Manning, 2007.
3 Matt Raible. Spring Live. SourceBeat LLC, 2004.
4 Christian Bauer, Gavin King. Java Persistence with Hibernate. Manning, 2006.
5 Артеменко Ю.Н., MySql справочник по языку. Издательский дом «Вильямс», 2005.
6 Леоненков А.В. Самоучитель UML второе издание. «БХВ-Петербург», 2006.
7 Bear Bibeault, Yehuda Katz. jQuery in Action. Manning, 2008.
8 Spring Framework reference. [Электронный ресурс].
http://static.springsource.org/spring/docs/2.5.5/reference/index.html
9 Spring Security Reference. [Электронный ресурс].
http://static.springsource.org/spring-security/site/docs/2.0.x/reference/springsecurity.html
10 Справочное руководство по MySQL [Электронный ресурс].
http://linux.yaroslavl.ru/docs/www/mysql/doc/Compare_mSQL.html
11 Simile Timeline Documentation. [Электронный ресурс].
http://code.google.com/p/simile-widgets/wiki/Timeline
12 Jasper Reports Documentation [Электронный ресурс].
http://jasperforge.org/website/jasperreportswebsite/trunk/documentation.html?group_id=252
13 Кей С. Хорстманн, Гари Корнелл. Java. Том 2. Тонкости программирования.
Издательский дом «Вильямс», 2007
14 Марк Гранд. Шаблоны проектирования в Java. Москва «Новое звание». 2004.
74