Разработка программного средства автоматизации обслуживания заявок пользователей локальной вычислительной сети филиала РГУ нефти и газа имени И.М. Губкина в г. Оренбурге
Аннотация
Пояснительная записка содержит 91 страницы, в том числе 27
рисунок, 28 таблиц, 40 источников, 2 приложения. Графическая часть выполнена на
10 листах формата А4.
Представленная дипломная работа рассматривает задачу разработки
программного средства автоматизации обслуживания заявок пользователей локальной
вычислительной сети филиала РГУ нефти и газа имени И.М.Губкина в г. Оренбурге.
Пояснительная записка содержит описание всех стадий
разработки программного продукта. Она включает математическую модель, анализ
решения задачи, архитектуру программного средства, функциональное назначение,
проектирование базы данных, алгоритм работы программного средства.
Работа состоит из пяти глав. Нумерация формул, таблиц и
рисунков ведется в каждой главе самостоятельно.
Работа содержит обоснование выбора языка программирования. Описание
программы включает описание схемы работы программы и описание структуры
программы. В работе представлено руководство пользователя. Рассмотрены вопросы,
касающиеся безопасности производства. Произведен расчет экономической
эффективности.
Внедрение проекта позволит повысить эффективность работы
исследуемого предприятия.
The Summary
Explanatory note contains 92 pages including 27 figures, 28
tables, 40 sources, 2 applications. The graphical part is made of 10 sheets of
A4.degree work considers the problem of the development software automation
service of user’s requests from the local area network at the branch RSU of oil
and gas of a name of I.M.Gubkina in Orenburg are consideredexplanatory note
contains a description of all stages of software development. It includes a
mathematical model, the analysis solution of the problem, the architecture of
software tools, functionality, database design, algorithm software.work
consists of five chapters. The numbering of formulas, tables and figures are in
each chapter independently.paper contains a rationale for the choice of
programming language. Description of the program includes a description of the
scheme of the program and describes the structure of the program. The paper
presents the user manual. Address issues related to production safety. The
calculation of economic efficiency.of the project will improve the efficiency
of the investigated companies.
Содержание
Введение
.
Аналитический раздел
.1 Анализ
предметной области
.2
Организационно-производственная структура
.3 Анализ
существующих программных продуктов
.4 Выбор
математического аппарата
.5 Постановка
задачи
.5.1
Назначение программного продукта
.5.2
Требования к программному средству и техническому оборудованию
. Проектный
раздел
.1
Инструментальные средства
.1.1 Выбор
языка программирования
.1.2
Технология клиент/сервер. Принцип работы Java Web-приложения
.1.3
Архитектура платформы Tandem.
.1.4 Выбор
СУБД
.1.5
Структурированный язык запросов SQL
.2 Разработка
базы данных проектируемого программного средства
.2.1
Формализованное описание предметной области
.2.2
Разработка инфологической модели БД
.2.3
Разработка даталогической модели БД
.2.4
Нормализация отношений
.2.5
Физическая модель БД
.2.5.1
Техническое описание объектов БД
.2.5.2
Реализация ограничений целостности БД
.3 Разработка
программного средства автоматизации обслуживания заявок
.
Технико-эксплуатационный раздел
.1
Руководство для пользователей
.2
Руководство для серверной части
.3
Руководство администратора
.4
Руководство программиста
. Обоснование
экономической эффективности проекта
.1 Расчет
трудоемкости разработки программного продукта
.2 Расчет
себестоимости программного продукта
.3 Расчет
экономического эффекта от внедрения программного продукта
.
Безопасность труда
.1 Анализ
условий труда
.2 Расчет
искусственного освещения
.3 Возможные
чрезвычайные ситуации
.3.1 Расчет
зоны заражения
.3.2 Расчет
времени эвакуации
Заключение
Список
использованных источников
Приложение А
Приложение Б
Введение
В настоящее время большое внимание уделяется автоматизации человеческой
деятельности в различных сферах производства. Это связано с тем, что количество
информации, которое человек должен воспринимать и перерабатывать растет экспоненциально.
Вычислительная техника в значительной мере способствует увеличению
производительности труда за счёт уменьшения времени выполнения одной и той же
задачи. Невозможно себе представить современную организацию без
компьютеризированного управления. Компьютеры все чаще и чаще помогают нам во
многих сферах жизнедеятельности: облегчают сложные вычисления, следят за
оборудованием, выводят в космос спутники и даже советуют при решении некоторых
вопросов. Индустрия компьютеризации не обошла стороной и документооборот,
продвигая его в сторону уменьшения ручного труда и переход от бумажных
носителей информации на электронные. Это связано с тем, что электронные
носители (компакт-диски, жесткие диски серверов и персональных компьютеров) по
своей структуре гораздо компактнее бумажных картотек, и поиск нужной информации
на них занимает доли секунд, что значительно повышает эффективность труда.
Из-за повсеместного применения компьютерной техники, любая организация
стремиться к автоматизации процессов за счет неё. Современный темп развития
информационных технологий позволяет автоматизировать практически любой вид
человеческой деятельности. В основном это отражается в структуризации данных и
создание баз данных, которые значительно упрощают поиск, хранение, добавление и
чтение информации. Но этого зачастую недостаточно для успешного ведения дел,
так как большое количество баз данных тоже усложняет работу и необходим
механизм управления ими. Таким образом, вся задача автоматизации сводится к
тому, что необходимо найти и создать такой механизм управления, который в
максимальной степени упростит и ускорит работу человека. Вообще грамотно
разработанная информационная система позволит автоматизировать наиболее широкий
спектр деятельности сотрудников предприятия.
Основными задачами по обслуживанию и настройке компьютерного оборудования
в организациях занимается отдел информационных технологий (далее ОИТ). От
качественной работы этого отдела зависит работа всего учреждения в целом.
Поэтому очень важно автоматизировать все процессы связанные с этим отделом.
Одной из подзадач этого отдела является обслуживание заявок от пользователей
локальной вычислительной сети (далее ЛВС). В филиале РГУ нефти и газа имени
И.М. Губкина (далее Филиал) вопрос автоматизации процессов оформления, приема,
обработки и исполнения заявок от пользователей является одним из важных
вопросов автоматизации образовательной деятельности. Все заявки в Филиале
заносятся пользователями в журнал, либо принимаются вербально, что в свою
очередь не гарантирует их выполнение в установленные сроки ввиду загруженности
сотрудников другой работой. Данные о неисправном оборудовании хранятся в этом
же журнале, что не позволяет одновременное использование этих данных
несколькими специалистами отдела информационных технологий, а также затрудняет
внесение изменений в список оборудования. В Филиале действует
автоматизированная система управления образовательной деятельности (АСУОД) Tandem.
В связи с этим появилась необходимость разработки программного средства
по обслуживанию заявок от пользователей ЛВС Филиала, в котором будет
осуществляться сбор, обработка, контроль исполнения заявок и составление
отчётности.
Дипломная работа посвящена разработке программного средства автоматизации
обслуживания заявок пользователей локальной вычислительной сети филиала РГУ
нефти и газа имени И.М.Губкина в г. Оренбурге.
1.
Аналитический раздел
.1 Анализ
предметной области
Филиал государственного образовательного учреждения высшего
профессионального образования "Российский государственный университет
нефти и газа имени И.М. Губкина" в г. Оренбурге создан приказом
Министерства общего и профессионального образования от 30.06.98 № 1758.
Для создания программного и информационного обеспечения, составляющих
информационной системы Филиала, необходимо понимание существующей
информационной системы, знание ее структуры и основных информационных потоков -
то есть необходим ее анализ. В ходе анализа предметной области будут получены
необходимые знания, будут выявлены недостатки (если таковые имеются) в существующей
информационной системе, дано обоснование в необходимости создания программного
и информационного обеспечения.
Основными задачами Филиала являются:
- удовлетворение потребностей личности в интеллектуальном,
культурном и нравственном развитии посредством приобретения высшего или второго
высшего профессионального образования;
- удовлетворение потребностей общества, государства, предприятий и
организаций регионов в квалифицированных специалистах с высшим образованием;
формирование у обучающихся гражданской позиции, способности к
труду и жизни в условиях современной цивилизации и демократии;
организация и проведение научных исследований, а также иных
научно-технических и опытно-конструкторских работ, направленных на решение
проблем нефтегазовой отрасли;
активное содействие в повышении общеобразовательного уровня
молодежи Оренбургской области
обеспечение государства высококвалифицированными кадрами в
области геология нефти и газа разведка месторождений, бурение скважин на нефть
и газ, разработка и обустройство месторождений, транспорт нефти и газа,
переработка нефти и газа, сбыт нефти и газа, а также обеспечивающие
специальности: экономика нефтегазового производства, автоматизация
нефтегазового производства, производство нефтегазового оборудования, экология
нефтегазового производства, юридическое обеспечение нефтегазового бизнеса [1].
Целью данного дипломного проектирования является разработка программного
средства автоматизации обслуживания заявок пользователей ЛВС Филиала. Процесс
принятия и выполнения заявок связан непосредственно с отделом информационных
технологий, поэтому целесообразно рассмотреть общие положения, структуру,
задачи и информационные потоки этого отдела.
Общими положениями отдела информационных технологий являются:
- отдел информационных технологий является самостоятельным
структурным подразделением Филиала;
- отдел создается и ликвидируется приказом директора Филиала;
отдел подчиняется непосредственно директору Филиала;
отдел возглавляет начальник, назначаемый на должность приказом
директора Филиала;
начальник ОИТ имеет одного заместителя;
обязанности заместителя определяются начальником ОИТ.
Структура ОИТ Филиала:
- структуру и штатную численность отдела утверждает директор
Филиала исходя из условий и особенностей деятельности Филиала по представлению
начальника информационного отдела и по согласованию с отделом кадров;
- ОИТ имеет в своем составе структурные подразделения;
положения о подразделениях отдела информационных технологий
утверждаются начальником ОИТ, а распределение обязанностей между сотрудниками
подразделений производится заместителем начальника хозяйственного отдела.
Основными задачами ОИТ являются:
- обеспечение бесперебойного
функционирования вычислительных сетей, компьютерной оргтехники, копировальных
аппаратов, серверов, средств и среды передачи данных, а также программного
обеспечения компьютеров;
- вынесение предложений по
улучшению и модернизации существующих средств передачи данных, оргтехники и
компьютерной техники, а также предложений по приобретению и внедрению новых
систем;
- обеспечение сохранности,
разграничения и контроля доступа к информации электронно-вычислительными и
программными средствами;
- осуществлять мероприятия по
повышению безопасности и сохранению конфиденциальности информации в
информационных системах общества.
Схема информационных потоков отдела информационных технологий филиала РГУ
нефти и газа имени И.М. Губкина представлена на рисунке 1.1.
Рисунок 1.1 - Схема информационных потоков
На схеме информационных потоков под буквами подразумевается следующее:
а) пользователь библиотеки сообщает о проблемах в работе компьютерного
оборудования, либо о необходимости мультимедиа оборудования;
б) сотрудник ОИТ выполняет заявку;
в) пользователь бухгалтерии сообщает о проблемах в работе программного
обеспечения, либо о неисправности компьютерного оборудования;
г) сотрудник ОИТ выполняет заявку;
д) пользователь общего отдела сообщает о проблемах в работе компьютерного
оборудования, либо о необходимости мультимедиа оборудования;
е) сотрудник ОИТ выполняет заявку;
ж) сотрудники учебно-организационного отдела передают сведения о
материально-ответственных лицах, работниках, ответственных за противопожарную
безопасность, охрану труда, списки лиц, имеющих доступ в помещения отделения;
з) сотрудник ОИТ заполняет базу данных работников Филиала;
и) сотрудник ОИТ запрашивает сведения об имеющемся мультимедиа и
компьютерном оборудовании на складе;
к) сотрудник хозяйственного отдела передаёт нужное оборудование, либо
оповещает, что такого оборудования нет на складе;
л) пользователи отделений и отделов по вопросам образовательной, научной
и воспитательной деятельности сообщают о неполадках в работе компьютерного
оборудования и программного обеспечения, а так же о необходимости в консультации
специалиста;
м) пользователь ОИТ выполняет заявку или консультирует.
1.2
Организационно-производственная структура
Любой производственный процесс требует строгой, четкой его организации.
Структура предприятия зависит от характера и особенностей производственного
процесса. Она характеризуется наличием руководителя, его заместителей,
функциональных отделов. Структурные подразделения действуют в соответствии с
установленным положением и должностными инструкциями, утвержденными начальником
управления. Организационная структура предприятия представлена в приложении.
Филиал имеет в своей структуре дирекцию, отделения,
учебно-организационный отдел, научно - техническую библиотеку, хозяйственный
отдел, отдел информационных технологий.
Структуру Филиала, создание, реорганизацию, ликвидацию его подразделений
утверждает ректор Университета.
Штатное расписание работников Филиала утверждается ректором Университета.
Управление Филиалом осуществляется в соответствии с Уставом РГУ нефти и
газа имени И.М. Губкина, настоящим Положением и действующим законодательством
РФ.
Директор Филиала осуществляет руководство организацией учебной и
учебно-методической работы в Филиале; обеспечивает выполнение решений органов
управления Университета, относящихся к учебному процессу; руководит работой
Учёного совета Филиала; принимает на работу и увольняет работников Филиала,
осуществляет их аттестацию и тарификацию; выполняет другие управленческие
функции.
Заместитель директора Филиала по учебной работе подчиняется директору
Филиала. Заместитель директора филиала по учебной работе разрабатывает
семестровые планы и делает сводную ведомость планируемой по представленным
заведующими отделениями плановым нагрузкам, а затем и выполненной нагрузки
профессорско-преподавательского состава, а также выполняет иные должностные
обязанности. Заместитель директора филиала по набору абитуриентов и аттестации
филиала подчиняется директору Филиала и руководит приемной комиссией, готовит
приказы о зачислении, а также другие должностные обязанности.
Ведущий библиотекарь подчиняется непосредственно директору Филиала и
руководит научно-технической библиотекой.
Заведующие отделениями подчиняются замдиректора по учебной работе
Филиала, координируют и контролируют деятельность
профессорско-преподавательского состава отделений.
Заведующий учебно-организационного отдела подчиняется заместителю
директора Филиала по учебной работе и распределяет обязанности работников
учебно-организационного отдела [2].
.3 Анализ
существующих программных продуктов
Необходимо проанализировать существующие аналоги программ технической
поддержки пользователей. Среди них выделим "Обработка заявок Service
Desk" и "Help Desk", разработанный на базе Microsoft SharePoint.
"Обработка заявок" Service Desk - система, предоставляющая
возможности для регистрации, обработки, контроля исполнения и поиска заявок
пользователей, а также для создания формализованных автоматизированных
бизнес-процессов и контроля над ходом их выполнения. Работая в системе, каждый
сотрудник вовремя получает задание на выполнение своего этапа работ и
оперативный доступ ко всей необходимой информации. Из особенностей данного
программного продукта можно выделить следующее:
возможность автоматической маршрутизации заявок согласно задаваемым
правилам бизнес-процесса;
обеспечение совместной работы над документами процесса поддержки
пользователей;
обеспечение обратной связи посредством оповещений по e-mail и
"прозрачности" прохождения заявки для ее заказчика;
повышение качества анализа работы корпоративной службы поддержки.
К минусам данного программного продукта можно отнести следующее:
пользователь имеет возможность оставлять заявку только по телефону. Это в
значительной мере нагружает телефонную линию предприятия, увеличивает время
поступления и обработки заявки;
пользователь не имеет возможности сам формировать свою заявку, за него
это должен делать диспетчер. Это также увеличивает время принятия и обработки
заявки, а также подразумевает наличия дополнительного штата работников, что
увеличивает затраты предприятия;
данное программное средство не имеет возможности автоматического
распределения заявок между специалистами в зависимости от их загруженности.
"Help Desk" - разработанное на базе SharePoint решение для
службы технической поддержки, позволяющее внедрить в организациях процессы
управления инцидентами, изменениями и уровнем сервиса.
Выделяются следующие положительные аспекты:
классификация и диспетчеризация приходящих заявок, в том числе для
назначения исполнителей, категории, приоритета и т.д.;
отслеживание текущего статуса заявки;
протоколирование работ, выполняемых по заявке, а также всех вносимых в
нее изменений;
построение отчетов.
Недостатки следующие:
громоздкость приложения, что в значительной мере ухудшает его
быстродействие;
большое количество окон, вкладок и кнопок. В связи с этим пользователь
вынужден тратить больше времени на изучение интерфейса программы, а также это
ведет к снижению концентрации внимания на каком-либо одном объекте;
также как и в случае с Service Desk "Обработка заявок",
предприятию необходим дополнительный штат работников, что увеличит расходы.
Данные программные продукты способны работать как на локальном
компьютере, так и в составе корпоративной сети предприятия.
Сравнительная характеристика разрабатываемого модуля и его аналогов
рассмотрена в таблице 1.1.
Как видно из таблицы, разрабатываемое программное средство имеет ряд
преимуществ перед своими аналогами. Весомым показателем является время
развертывания разрабатываемого программного продукта, что важно для организаций
с большим количеством рабочих станций. Также оно имеет возможность создавать
отчеты в формате MS Excel.
Таблица 1.1 - Сравнительная характеристика программных средств
|
"Help Desk"
|
"Обработка
заявок"
|
Программное средство
автоматизации обслуживания заявок
|
|
Поддерживаемые операционные
системы
|
Windows
9x/NT/2000/XP/ Vista/Seven
|
Windows
9x/NT/2000/XP/ Vista/Seven
|
Windows
9x/NT/2000/XP/ Vista/Seven
|
|
Язык разработки
|
C++
|
C#
|
Java
|
|
Проверка корректности ввода
данных
|
-
|
+
|
+
|
|
Создание отчета в MS Excel
|
-
|
-
|
+
|
|
Протоколирование выполнения
заявки
|
+
|
+
|
+
|
|
Быстрое развертывание
|
-
|
-
|
+
|
|
Необходимость сервисного
обслуживания
|
+
|
+
|
-
|
Программные продукты "Help Desk" и
"Обработка заявок" обладают несколькими общими недостатками: для их
полного функционирования необходим дополнительный штаб работников для
обслуживания данных систем сбора и обработки заявок, что влечет за собой
дополнительные расходы предприятия; они не способны создавать отчеты в формате MS Excel; не обладают возможностью быстрого развертывания, что
крайне неудобно. Программное средство "Обработка заявок" не является
серверным, что не позволяет работать с ним одновременно нескольким
пользователям. Кроме того, пользователь оставляет свою заявку по телефону, что
никак не отличается от текущей ситуации в Филиале. Программное средство "Help Desk" не имеет возможности следить за корректностью
вводимых данных пользователем, что может приводить к различным конфликтам.
Разрабатываемое программное средство будет иметь возможность создания
отчетов в MS Excel, является серверным решением, что позволит работать с
ним сразу нескольким пользователям. Ввод данных будет осуществляться
посредством выбора соответствующего пункта из выпадающего меню, что исключит
ошибку при вводе. Запуск программного средства будет производиться
непосредственно через встроенный в операционную систему браузер, без
предварительной установки его на компьютеры пользователей. Программа также
будет иметь простой интерфейс, не перегруженный дополнительными окнами, что
позволит сократить время изучения элементов программы.
Рассмотрев аналоги разрабатываемого средства, можно сделать вывод, что
разрабатываемый программный продукт в полной мере позволит автоматизировать
процессы подачи заявки, контроля ее исполнения, увеличить оперативность
работников, вести учет выполненных заявок. Также он позволит избавить Филиал от
постоянных расходов на его обслуживание и сэкономит бюджет и время на обучение
работы с программой.
1.4 Выбор
математического аппарата
Разрабатываемое программное средство по автоматизации обслуживания заявок
пользователей локальной вычислительной сети филиала РГУ нефти и газа имени
И.М.Губкина в г. Оренбурге будет осуществлять работу с базой данных
пользователей и отправку заявок на обслуживание компьютерной оргтехники по
локальной сети.
Для оценки выполнения или не выполнения заявок необходимо проводить
исследования, результатами которых будут параметры, характеризующие состояния
заявок. На основе этих параметров можно построить модель исследования и
провести прогнозирование значений параметров для последующих значений времени.
Для этого используем регрессионный метод.
Для построения нелинейных регрессионных моделей с автоматическим выбором
степени аппроксимирующих полиномов в настоящей главе рассматривается
ступенчатый регрессионный метод.
Первым этапом исследования многопараметрических процессов является отбор
параметров, ответственных за процесс. Из полного списка всех возможных
параметров ранговыми методами производят их ранжирование и априорное отсеивание
[3].
Математическая обработка результатов наблюдения за оставленными на первом
этапе исследования параметрами включает в себя проверку гипотезы о нормальности
распределения результатов наблюдения в выборке по каждому параметру, получение
корреляционной матрицы и регрессионный анализ.
Обработку целесообразно вести, производя предварительно центрирование и
нормирование результатов наблюдений, т. е. переходя к стандартизованным
переменным.
При решении задач, связанных с отысканием оптимальных условий протекания
сложных многопараметрических процессов, широкое распространение получили
полиномиальные математические модели процесса
|
|
(1.1)
|
где y
- параметр оптимизации;
b0,bi,bij,bii - выборочные коэффициенты регрессии,
полученные по результатам эксперимента;
,
- параметры и их взаимодействия, i,j=1,2…
Теоретически коэффициенты уравнения регрессии можно определить из системы
линейных нормальных уравнений, используя метод наименьших квадратов относительно
этих коэффициентов.
Однако для вычисления коэффициентов уравнений регрессии
многопараметрических процессов (m>2) и высокого порядка полинома (К>2)
система нормальных уравнений практически оказывается малопригодной ввиду
большой потери точности при ее решении (причем потеря точности сказывается тем
сильнее, чем больше количество переменных и выше порядок полинома). Не решенным
остается и вопрос оптимального порядка полинома.
Упрощенный метод определения коэффициентов уравнения регрессии (1.1) предложен
в работе Д. Брандона.
Этот метод заключается в том, что уравнение (1.1) записывается в виде
(1.2)
где 
- любая функция величины 
.
В случае нелинейной зависимости вид функции определяется с помощью
корреляционного поля, потом по виду определяется тип зависимости и способом
наименьших квадратов рассчитываются коэффициенты.
При числе параметров более трех и порядка полиномов 
более второго уравнение (1.2)
становится весьма громоздким и малоэффективным в использовании, оно излишне
перегружено суммой произведений различных комбинаций факторов. Поэтому был
разработан упрощенный метод описания многофакторных процессов.
Рассмотрим алгоритм метода.
Точность математического описания в конечном итоге определяет коэффициент
детерминации. Приемлемым может быть тот алгоритм описания, который позволяет
получить аппроксимирующую функцию процесса с удовлетворительной
предсказательной способностью (т. е. если коэффициент детерминации более 0,8).
Более удобным в данном случае может оказаться метод так называемого
"последовательного разглаживания гиперповерхности отклика". Идея
этого метода заключается в последовательном снятии эффектов всех переменных
полиномиального уравнения (1.1).
В основу положен ступенчатый регрессионный метод при множественной
линейной регрессии [4].
В этом случае уравнение (1.1) можно записать в виде
|
|
(1.3)
|
где 
- полиномы возрастающих степеней переменной 
.
Перед вычислением полиномов jj необходимо проводить предварительное
ранжирование переменных по степени влияния их на параметр оптимизации y.
Начинать вычисление полинома нужно для наиболее сильно влияющей
переменной. Расчет коэффициентов полинома и оптимальный порядок его
целесообразно производить, используя ортогональные многочлены Чебышева [5,6].
Путь задан процесс в виде матрицы наблюдений
где m - число независимых параметров;
n
- число наблюдений;
y
- зависимый параметр;
- матрица наблюдений независимых параметров.
Последовательно для всех пар массивов y -
, y
-
,...,
y -
вычислить остаточную дисперсию 
, 
,...,
, характеризующую степень влияния
независимого параметра на зависимый y.
Для этого воспользуемся ортогональными многочленами Чебышева.
Искомая зависимость условного среднего y от Хj имеет вид
|
|
(1.4)
|
где 
- ортогональный многочлен Чебышева k-го
порядка;
- полином нулевой степени.
Общая дисперсия вычисляется по формуле
|
|
(1.5)
|
Где 
.
Остаточная дисперсия определяется по формуле
где k =1.
Если 
, где 
- табличное значение для
распределения Фишера, то осуществляется переход к следующему j.
Иначе 
и переход к следующим вычислениям.
Вычисляем ортогональный многочлен Чебышева k-го порядка
|
|
(1.6)
|
Где 
Если 
, то запоминается 
, иначе k=k+1 и возврат к предыдущим вычислениям и так до
тех пор, пока 
для всех j=1,2,...,m.
Выбрать из всех минимальное,
где j=1,2,...,m.
Если минимальных остаточных дисперсий получится несколько равных между
собой, то выбрать последнюю при переборе.
Если =Dn,начальной промежуточной дисперсии, то конец решения. Иначе перейти к
следующим вычислениям.
Произвести как бы разглаживание поверхностей отклика в направлении
переменной Хj,
вычитая из выборочных значений yi величины, рассчитанные по jj(Xj).
Сформировать массив
по формуле
Заменить в матрице наблюдений массив yi на y1i.
Повторить вычисления сначала и до конца для матрицы наблюдений с учетом
замененных массивов yi на
y1i до тех
пор, пока последняя остаточная дисперсия =
уменьшится в r раз по
сравнению с начальной общей дисперсией величины y.
Такая процедура продолжается до тех пор, пока не будет осуществлено
элиминирование всех переменных.
В общем математическую модель можно представить в виде работы дискретного
автомата, графическая интерпретация которого показана на рисунке 1.3
Рисунок 1.3 - Математическая модель в виде дискретного автомата
Каждая заявка может иметь четыре состояния: 1 - не выполнена, 2 - в
работе, 3 - выполнена, 4 - удалена. Значение состояния "не выполнена"
на выходе дискретного автомата будет равно 0 (х1=0), состояния
"в работе" - 
, состояния "выполнена" - х3=1,
состояния "удалена" - 
.
Данная модель будет описываться полиномом четвертой степени
.5
Постановка задачи
За время прохождения преддипломной практики на базе ООО
"Оренбургская Буровая Компания" была изучена система электронного
документооборота и управления взаимодействием "Directum" и составлен типовой маршрут
"Заявка в отдел ИТ". Эта система соответствует концепции ECM
(Enterprise Content Management) и поддерживает полный жизненный цикл управления
документами. При этом традиционное "бумажное" делопроизводство
органично вписывается в электронный документооборот. Одной из подзадач данной
системы является составление и исполнение заявок в отделы. Все заявки
основываются на типовых маршрутах. С помощью типового маршрута автоматически
задается список исполнителей (в том числе на основе ролей), могут заполняться
любые поля задачи (например, текст или тема), считывается информация из
вложений и связанных объектов (задач, подзадач, электронных документов,
справочников). Механизм типовых маршрутов является мощным инструментом для
автоматизированного создания задач в соответствии с заданными бизнес-правилами
любой сложности [7]. Изучив схему бизнес-процессов, был создан типовой маршрута
заявок в ИТ отдел. Опираясь на опыт работы с заявками, и исследовав
бизнес-процессы в филиале Российского государственного университета нефти и
газа имени И.М. Губкина в городе Оренбург, было установлено следующее: в
филиале имеется значительный поток заявок в ОИТ от остальных пользователей
каждый день. Все заявки записываются пользователями в журнал на вахте. Журнал
состоит из нескольких разделов: заявки на технические средства обучения и
заявки неполадок компьютерного оборудования по различным аудиториям. Этот
способ подачи заявок очень неудобен, так как занимает много времени, структура
таблицы не позволяет в полной мере описать проблему или неполадку оборудования,
и процесс выполнения заявки мог быть очень долгим, так как сотруднику тех
поддержки необходимо периодически приходить на вахту и проверять журнал.
В связи с этим не всегда сразу удавалось найти правильное решение на
описанную проблему. Также процесс выполнения заявки никем не контролировался, а
сам факт выполнения или невыполнения заявки нигде не фиксировался.
Невозможно было вести подсчет выполненных заявок за каждым работником
отдела ИТ, т.к. это опять же нигде не фиксировалось. Вести отчетность за
определенный период времени не представлялось возможным. В связи с этим встала
необходимость разработки программного средства автоматизации обслуживания
заявок в ОИТ, которое позволит автоматизировать процессы подачи, принятия,
исполнения заявок, а также вести отчетность для всего отдела ИТ в целом.
Целью данной дипломной работы является разработка программного средства
автоматизации обслуживания заявок пользователей локальной вычислительной сети
Филиала.
Задачами данной дипломной работы являются:
разработка базы данных учета и хранения заявок пользователя;
разработка программного средства на основе клиент/серверной технологии;
разработка интерфейса программного средства;
Подзадачами данных задач являются:
выбор СУБД;
выбор языка программирования;
углубленное ознакомление с платформой Tandem Framework;
математическое описание решения задачи предметной области;
первичное апробирование и дальнейшая отладка программного средства
автоматизации обслуживания заявок предметной области.
.5.1
Назначение программного продукта
Данный программный продукт предназначен для автоматизации процессов
обслуживания заявок пользователей и ведение реестра отчетности сотрудников ОИТ.
Разработанное средство позволит:
хранить данные централизованно;
осуществлять контроль за исполнением заявок;
оперативно генерировать отчеты;
снизить временные затраты на принятие, обработку и исполнение заявок.
Пользователями данного программного средства выступают сотрудники отделов
и отделений Филиала согласно схеме информационных потоков, представленной на
рисунке 1.1.
.5.2
Требования к программному средству и техническому оборудованию
Данный программное средство должно решать следующие задачи:
подача и принятие заявок на обслуживание и установку компьютерной
оргтехники;
осуществление контроля за исполнением заявок;
контроль ввода необходимой информации;
генерирование отчетов по выполненным заявкам;
создание удобного и понятого интерфейса;
обеспечить целостность данных, хранящихся в БД.
Для нормального функционирования программного средства необходимо
следующее аппаратное обеспечение с минимальными требованиями:
компьютер Pentium
II 400 MHz или ему подобный;
256 Мб оперативной памяти;
30 Мб свободного места на жестком диске;
монитор VGA с разрешением 800х600 пикселей;
клавиатура, мышь;
струйный, лазерный принтер либо МФУ.
Требования к программному обеспечению:
операционная система Windows
98/2000/XP/Vista/Seven;
- Java Runtime Environment (JRE);
сервер
Tomcat 7;
- СУБД PostgreSQL 8.4;
Microsoft Office 2007/2010.
В состав сопровождающей документации должны входить:
пояснительная записка;
руководство для клиентской части средства;
руководство администратора;
руководство программиста.
В первом разделе проведена следующая работа:
проведен анализ предметной области Филиала;
исследованы информационные потоки рассматриваемой предметной области;
проанализированы существующие аналоги разрабатываемому программному
средству;
сформулирована постановка задачи на разработку программного средства для
автоматизации процессов подачи, принятия и обработки заявок на обслуживание
компьютерной оргтехники, осуществлена декомпозиция задач;
сформулированы требования к аппаратному и программному обеспечению
разрабатываемого средства.
2.
Проектный раздел
.1
Инструментальные средства
.1.1 Выбор языка программирования
Выбирая язык программирования для разработки программного средства, было
рассмотрено несколько вариантов: C++, Java и C#. Их сравнительная характеристика рассмотрена в таблице 2.1.
Таблица 2.1 - Сравнительная характеристика языков программирования
|
C++
|
Java
|
C#
|
|
1
|
2
|
3
|
4
|
|
Подход к разработке ПО
|
объектно-ориентированный
|
объектно-ориентированный
|
объектно-ориентированный
|
|
Инструкция break
с меткой
|
-
|
+
|
-
|
|
Целые числа произвольной
длинны
|
-
|
+
|
+
|
|
Поддержка языка SQL
|
+
|
+
|
+
|
|
Кроссплатформенность
|
-
|
+
|
-
|
|
Многопоточная компиляция
|
+
|
+
|
-
|
|
Поддержка оконного
интерфейса
|
+
|
+
|
+
|
|
Блок else (исключения)
|
-
|
+
|
+
|
|
Возможность создания
запускаемого файла
|
+
|
+
|
+
|
|
Возможность разработки Web-приложений
|
-
|
+
|
+/-(имеется только для
клиентов Windows)
|
Как видно из таблицы, для разработки программного средства по
автоматизации обслуживания заявок от пользователей ЛВС Филиала наиболее
подходят языки программирования Java и
C#, так как они поддерживают
возможность разработки Web-приложений.
Акцент на этой технологии был установлен ввиду особенности поставленной задачи:
программное средство должно встраиваться в АСУОД Tandem, установленную в Филиале, иметь Web-интерфейс и работать без установки
на компьютеры пользователей. То есть сама программа будет запускаться с сервера
через локальную сеть Филиала. Для решения этих задач больше подходит язык Java, так как он более адаптирован для
программирования Internet-программ.
Когда программный продукт, написанный на языке программирования Java,
компилируется с использованием Java-компилятора, получается байткод. Этот
байткод может интерпретироваться на любой платформе, где установлена
виртуальная машина Java. Это означает, что нет необходимости в импортировании
программ, то есть их перевода на язык, понятный конкретному компьютеру [9].
За последние годы увеличилось множество несовместимых аппаратных
архитектур, каждая из которых поддерживает множество несовместимых операционных
систем, которые, в свою очередь, управляют несовместимыми графическими
пользовательскими интерфейсами. Задача создания распределенных клиент-серверных
сред сталкивается с проблемой интеграции подобных разрозненных продуктов.
Развитие Internet, World Wide Web и электронного бизнеса привнесло новый
уровень сложности в процесс разработки. Язык Java компании Sun Microsystems решает
эти проблемы [10].
Цикл разработки программных средств с использованием Java значительно
сокращается в силу того, что Java - интерпретируемый язык. Процесс
компиляции-сборки-загрузки устарел - теперь программу надо только
откомпилировать и сразу запускать.
Поддержка системы многопоточности позволяет создавать параллельно
исполняемые взаимодействующие легковесные процессы.
Приложения настраиваемы под изменяющееся окружение: возможна динамическая
загрузка программных модулей из любого места в сети.
Так как создаваемое программное средство относится к Web-приложениям, то для его разработки
необходима расширенная платформа Java Enterprise Edition, или Java EE, являющаяся стандартом разработки
серверных Java приложений. Эта платформа содержит необходимые технологии, такие как сервлеты, JSP, JDBC. Сервлет - это небольшая программа, выполняемая на
сервере. Сервлеты динамически расширяют функциональные возможности Web-сервера. Их часто называют web-компонентами, так как они
выполняются в специальной среде исполнения, создаваемой контейнером сервлетов
или web-контейнером, таким, как Jakarta Tomcat или ВЕА WebLogic [11].
Таким образом, с появлением сервлетов язык Java распространился на оба конца
соединения "клиент-сервер". Сервлеты служат для создания динамически
генерируемого содержимого, которое затем обслуживает клиента. Хотя динамически
генерируемое содержимое доступно также посредством таких механизмов, как CGI (Common Gateway Interface - общий шлюзовой интерфейс), сервлет
обеспечивает ряд преимуществ, в том числе - повышение производительности.
Поскольку сервлеты (подобно всем Java-программам) компилируются в байт-код
и выполняются машиной JVM,
они в высшей степени переносимы. Следовательно, один и тот же сервлет может
применяться в различных серверных средах. Единственные необходимые условия для
этого - поддержка сервером машины JVM и контейнера сервлета.Server Pages (JSP, или в русском переводе
серверные страницы Java) являются стандартным расширением платформы Java и
построены на основе технологии сервлетов. Основное назначение JSP-страниц - это
упростить создание и управление динамическим содержанием в World Wide Web.
Структура серверной страницы JSP представляет некий компромисс между сервлетом
и обычной HTML-страницей. Так, технология JSP позволяет комбинировать разметку
на языке HTML или XML с фрагментами кода Java в одном документе. Этот код
выполняется на стороне сервера и служит для обработки запросов клиентов и
генерации ответов. Фрагменты кода Java, как и обычные HTML-теги, начинаются и
заканчиваются угловыми скобками, однако дополнительно к угловым скобкам
используются знаки процента. Эти специальные теги предписывают контейнеру JSP
использовать этот код для генерации сервлета или его части. Остальные HTML- и
XML-фрагменты, а также прочие данные передаются клиенту без обработки на
стороне сервера [12].
Благодаря сервлетам разрабатываемое программное средство не нуждается в
установке на рабочие станции пользователей, а запускается и выполняется на
сервере, что значительно упрощает первичное апробирование и дальнейшую отладку
программного средства.
.1.2
Технология клиент/сервер. Принцип работы Java Web-приложения
В типичном Java EE web-приложении HTML клиент отправляет запрос
серверу, где этот запрос обрабатывается веб-контейнером сервера приложений.
Веб-контейнер вызывает сервлет, который сконфигурирован для обработки
определенного контекста запроса. Начальный запрос HTML клиента проиллюстрирован
на рисунке 2.1.
Рисунок 2.1 - Начальный запрос HTML клиента
Как только сервлет получает начальный запрос, инициируется
выполнение определенной бизнес логики для завершения запроса. При этом
вызывается один или несколько бизнес сервисов или компонентов как показано на
рисунке 2.2.
Рисунок 2.2 - Бизнес сервисы или компоненты в JEE архитектуре
Некоторым бизнес сервисам или компонентам требуется доступ к
хранилищам данных или информационным системам. Как правило, для этих целей
вводится дополнительный слой абстракции между бизнес сервисами и хранилищем
данных, что позволяет сделать максимально безболезненным возможное изменение
источника данных в будущем. При этом объекты доступа к данным (DAO)
представляются отдельными компонентами, как показано на рисуноке 2.3.
Рисунок 2.3 - Использование DAO объектов бизнес сервисами для
доступа к хранилищу данных
Когда обработка запроса на сервере завершена, HTML клиенту
возвращается ответ в определенном формате. Этот процесс показан на рисунке 2.4.
Рисунок 2.4 - Ответ возвращается HTML клиенту
Сценарий, проиллюстрированный на рисунке 2.4, может быть
реализован с использованием ограниченного набора Java EE технологий, таких как,
например, сервлеты, JDBC, JSP и тому подобные. Tomcat как и другие веб-серверы,
предоставляющие среду выполнения сервлетов и JSP, вполне может быть использован
как сервер приложений для данного сценария [13].
.1.3
Архитектура платформы Tandem
В филиале РГУ нефти и газа имени И.М. Губкина города Оренбурга
используется платформе АСУОД Tandem Framework. Она построена с использованием
трехуровневой (3-tier) архитектуры, общая схема которой представлена на рисунке
2.5.
В качестве постоянного хранилища данных используется реляционная база
данных. Данные в базу помещаются в виде набора реляционных сущностей (связанных
таблиц, содержащих колонки с данными). Система совместима практически со всеми
современными реляционными СУБД, такими как Oracle, MS SQL, PostgreSQL, MySQL,
Interbase/Firebird.
Рисунок 2.5 - Архитектура платформы
Сервер приложений представляет собой контейнер сервлетов Tomcat, который
обеспечивает работу Web-приложения, состоящего из набора модулей при помощи
Spring Framework и Tapestry, связанных между собой [14]. Наряду с прикладными
модулями приложения в набор модулей входят также и системные модули фреймворка.
Работа с базой данных внутри сервера приложений реализуется с использованием
ORM инструмента Hibernate, который предназначен для связи объектной структуры
приложения с реляционной моделью базы данных и обеспечивает транзакционную
целостность данных и независимость кода уровня приложения от выбранного
реляционного хранилища. Для управления исходным кодом Tandem Framework
используется SVN.
Платформа Tandem Framework обеспечивает возможность создания
пользовательского интерфейса в виде "тонкого" клиента. На клиентском
рабочем месте для работы с системой необходим лишь Web-браузер, который имеется
в любой операционной системе. Так как разрабатываемое программное средство
будет разворачиваться на сервере приложений платформы Tandem Framework, то для начала его работы нет
необходимости в установке дополнительных программных пакетов - достаточно иметь
подключение к серверу по локальной сети или через интернет [15].
.1.4 Выбор
СУБД
В качестве основных претендентов рассмотрим СУБД Microsoft SQL Server 2008, MySQL
5.1, PostgreSQL 8.4. Все они имеют широкий
функционал, высокую скорость работы, поддержку основных типов данных,
поддерживают различные ОС .
В таблице 2.1 производится сравнение выбранных СУБД.
Таблица 2.1 - "Сравнение СУБД"
|
Показатели
|
Microsoft SQL Server 2008
|
MySQL 5.1
|
PostgreSQL 8.4
|
|
1
|
2
|
3
|
4
|
|
Поддерживаемые операционные
системы
|
Windows Desktop/Server
|
Windows
Desktop/Server, Linux, Unix, Mac
|
Windows1
Desktop/S22erver, Linux, Unix, Mac
|
|
Условия лицензирования
|
Коммерческий продукт с
закрытым исходным кодом
|
Коммерческая лицензия и GNU
GPL
|
Лицензия BSD Open Source
|
|
Процесс установки и
поддержки
|
Довольно длительное время
уходит на установку приложения и всех его зависимостей, однако множество
средств помощи помогают в процессе. Платные версии отсылают электронные
сообщения, если что-то "не так" в процессе работы
|
Самый простой процесс
установки, так как существует огромное количество готовых пакетов для разных
операционных систем, установка из которых сводит трудности и проблемы к нулю
|
Для операционных систем
семейств Linux/Unix установка идентична установке MySQL. Однако во время
установки под Windows иногда возникают проблемы с инициализацией базы данных
|
|
Наличие драйверов ODBC,
JDBC, ADO.NET
|
Да
|
Да
|
Да
|
|
Наличие View, доступных
только для чтения
|
Да
|
Да
|
Да
|
|
Наличие программных
продуктов с открытым исходным кодом, основанных на этой СУБД
|
Несколько
|
Много
|
Несколько, но их число
растет, особенно в проектах на PHP
|
|
Использование в
коммерческих проектах
|
Среднее (продукт новый)
|
Среднее
|
Среднее (почти как у MySQL)
|
|
Обновляемые View
|
Да, даже для двухтабличных
view
|
Да, для однотабличных view
и некоторых "простых" двухтабличных
|
Да, но не в автоматическом
режиме. Надо писать правила обновления
|
|
Наличие графического ПО для
конструирования и оптимизации запросов
|
Да (SQL Management Studio и
Studio Express)
|
Нет
|
Да (PgAdminIII)
|
|
Наличие Computed Columns
|
Да, но все равно чаще
используются view
|
Нет
|
Нет - в PostgreSQL это функциональность
излишняя
|
|
Поддержка функциональных
индексов
|
Нет, но можно обойтись
Computed Columns
|
Нет
|
Да
|
|
Поддержка частичных
индексов
|
Да (называются
"фильтрованные индексы")
|
Нет
|
Да
|
|
Поддержка ACID-требований к
транзакциям
|
Да
|
Да, при использовании
некоторых движков хранения данных
|
Да
|
|
Каскадное
обновление/удаление внешних ключей
|
Да
|
Да, при использовании
некоторых движков хранения данных
|
Да
|
|
Внесение данных в несколько
строк
|
Да
|
Да
|
Да
|
|
Поддержка UPSERT-логики
|
Да (через MERGE UPDATE)
|
Да (через INSERT IGNORE, REPLACE INSERT ON
DUPLICATE UPDATE)
|
нет
|
|
Поддержка репликации
|
Да, встроенная и разных
типов
|
Да, включая mater-master
репликацию
|
Да, но с помощью сторонних
продуктов с открытым исходным кодом
|
|
Возможность писать хранимые
функции на разных языках программирования
|
Да, теоретически на любом
языке, поддерживающим CLR, например VisualBasic.NET, C#, IronPython
|
Нет (кроме C и Pl/SQL)
|
Да, наиболее полная
поддержка из всех рассматриваемых
|
|
Возможность создавать
пользовательские агрегированные функции
|
Да - любой .NET язык, кроме
TRANSACT SQL
|
Да, только на С
|
Да - на PL language и
встроенных C, SQL, PLPgSQL
|
|
Поддержка триггеров
|
Да
|
Да
|
Да
|
|
Партицирование таблиц
|
Да (в Enterprise версии)
|
Да
|
Да
|
|
Возможность создавать
функции, возвращающие таблицу или набор таблиц, которые можно использовать в
секции FROM
|
Да
|
Нет
|
Да
|
|
Поддержка хранимых процедур
|
Да
|
Да
|
Да (с помощью CREATE
FUNCTION)
|
|
Поддержка динамического SQL
в функциях
|
Нет
|
Нет
|
Да
|
|
Бесплатное ПО для
графического управления БД
|
Да (SQL Management Studio/Express)
|
Нет
|
Да (PgAdmin III)
|
|
Наличие встроенного
планировщика (не CronTab)
|
Да (SQL Agent не для
Express версии)
|
Да (только для
SQL-запросов)
|
Да (PgAgent)
|
|
Возможность доступа к
таблице из другой базы данных, находящейся на том же хосте
|
Да
|
Да
|
Да
|
|
Чувствительность к регистру
|
По умолчанию - не
чувствительна
|
Нет
|
Да
|
|
Поддержка даты и времени
|
Да
|
Да (но без временной зоны)
|
Да
|
|
Аутентификация
|
Средствами БД и
ActiveDirectory
|
Средствами БД
|
Много разных методов,
включающих предыдущие
|
|
Разграничение доступа к
столбцам
|
Да
|
Да
|
Да
|
|
Поддержка рекурсивных
запросов
|
Да
|
Нет
|
Да
|
|
Поддержка CROSS APPLY
|
Да
|
Нет
|
Нет, но можно обойтись
возвращающей функции в Select
|
|
Поддержка LIMIT .. OFFSET
|
Нет
|
Да
|
Да
|
|
Поддержка связанных
подзапросов
|
Да
|
Да
|
Да
|
|
Производительность
планировщика запросов для сложных запросов
|
Средняя (умеет параллельные
запросы "из коробки")
|
Плохая
|
Очень хорошая (GridSQL)
|
|
Наличие текстового
процессора
|
Да
|
Да
|
Да
|
|
Возможность откатить
CREATE, ALTER
|
Да
|
Нет
|
Да
|
На основе данных, представленных в таблице 2.1, можно сделать вывод что
для реализации данной задачи подходят все три СУБД, но так как PostgreSQL
является бесплатно распространяемой, имеющей встроенные средства обеспечивающие
надёжность хранимых данных и широкие возможности оптимизации запросов, то она
была выбрана в качестве СУБД для разрабатываемого программного средства по
автоматизации обслуживания заявок от пользователей.
.1.5
Структурированный язык запросов SQL
Одним из языков, появившихся в результате разработки реляционной модели
данных, является язык SQL (Structured Query Language), который в настоящее
время получил очень широкое распространение и фактически превратился в
стандартный язык реляционных баз данных. Стандарт на язык SQL был выпущен
Американским национальным институтом стандартов (ANSI) в 1986 г., а в 1987 г.
Международная организация стандартов (ISO) приняла его в качестве
международного. Нынешний стандарт SQL известен под названием SQL/92.
Все конкретные реализации языка несколько отличаются друг от друга. В
интересах самих же производителей гарантировать, чтобы их реализация
соответствовала современным стандартам ANSI в части переносимости и удобства
работы пользователей. Тем не менее каждая реализация SQL содержит
усовершенствования, отвечающие требованиям того или иного сервера баз данных.
Эти усовершенствования или расширения языка SQL представляют собой
дополнительные команды и опции, являющиеся добавлениями к стандартному пакету и
доступные в данной конкретной реализации.
Язык SQL ориентирован на операции с данными, представленными в виде
логически взаимосвязанных совокупностей таблиц-отношений. Важнейшая особенность
его структур - ориентация на конечный результат обработки данных, а не на
процедуру этой обработки. Язык SQL сам определяет, где находятся данные,
индексы и даже какие наиболее эффективные последовательности операций следует
использовать для получения результата, а потому указывать эти детали в запросе
к базе данных не требуется.
Основные достоинства языка SQL заключаются в следующем:
стандартность - как уже было сказано, использование языка SQL в программах
стандартизировано международными организациями;
независимость от конкретных СУБД - все распространенные СУБД используют
SQL, т.к. реляционную базу данных можно перенести с одной СУБД на другую с
минимальными доработками;
возможность переноса с одной вычислительной системы на другую - СУБД
может быть ориентирована на различные вычислительные системы, однако
приложения, созданные с помощью SQL, допускают использование как для локальных
БД, так и для крупных многопользовательских систем;
реляционная основа языка - SQL является языком реляционных БД, поэтому он
стал популярным тогда, когда получила широкое распространение реляционная
модель представления данных. Табличная структура реляционной БД хорошо понятна,
а потому язык SQL прост для изучения;
возможность создания интерактивных запросов - SQL обеспечивает
пользователям немедленный доступ к данным, при этом в интерактивном режиме
можно получить результат запроса за очень короткое время без написания сложной
программы;
возможность программного доступа к БД - язык SQL легко использовать в
приложениях, которым необходимо обращаться к базам данных. Одни и те же
операторы SQL употребляются как для интерактивного, так и программного доступа,
поэтому части программ, содержащие обращение к БД, можно вначале проверить в
интерактивном режиме, а затем встраивать в программу;
обеспечение различного представления данных - с помощью SQL можно
представить такую структуру данных, что тот или иной пользователь будет видеть
различные их представления. Кроме того, данные из разных частей БД могут быть
скомбинированы и представлены в виде одной простой таблицы, а значит,
представления пригодны для усиления защиты БД и ее настройки под конкретные
требования отдельных пользователей;
возможность динамического изменения и расширения структуры БД - язык SQL
позволяет манипулировать структурой БД, тем самым обеспечивая гибкость с точки
зрения приспособленности БД к изменяющимся требованиям предметной области;
поддержка архитектуры клиент-сервер - SQL - одно из лучших средств для
реализации приложений на платформе клиент-сервер. SQL служит связующим звеном
между взаимодействующей с пользователем клиентской системой и серверной
системой, управляющей БД, позволяя каждой из них сосредоточиться на выполнении
своих функций [16].
В настоящее время язык SQL поддерживается многими десятками СУБД
различных типов, разработанных для самых разнообразных вычислительных платформ,
начиная от персональных компьютеров и заканчивая мейнфреймами.
.2
Разработка базы данных проектируемого программного средства
В теории баз данных существует ряд методов разработки моделей БД,
отображающих разные уровни ее архитектуры. Распространены два основных подхода
к проектированию систем баз данных: "нисходящий" и
"восходящий".
"Восходящее" проектирование - это достаточная сложная и
устаревшая методика, требующая значительного объема мероприятий по нормализации
схем реляционных отношений и подходящая для проектирования небольших баз данных
[17].
При "нисходящем" проектировании осуществляется структурное
проектирование сверху-вниз. Такой процесс называется анализом - происходит
изучение описания предметной области, а затем разделение целого на составные
части с последующим изучением. Начинается этот подход с разработки моделей
данных, которые содержат несколько высокоуровневых сущностей и связей, затем
работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей,
связей и относящихся к ним атрибутов.
Таким образом, для проектирования базы данных необходимо использовать
"нисходящий" подход, содержащий ряд этапов:
анализ предметной области. На основе анализа предметной области
получают описание внешнего уровня БД, являющееся исходными данными для
следующего этапа;
разработка инфологической модели (ИЛМ). По полученному на
предыдущем этапе описанию строится модель данных использующая модель
"сущность-связь";
разработка даталогической модели (ДЛМ). На основе ИЛМ предметной
области строится ДЛМ БД;
нормализация. Этап представляет собой нормализацию полученной
модели;
формирование физической модели БД на языке описания данных СУБД.
На заключительном этапе проектирования строится физическая модель данных с
учетом особенностей используемой СУБД.
.2.1
Формализованное описание предметной области
Формализованное описание предметной области содержит описание классов
объектов (сущностей), выявленных на этапе анализа предметной области и связей
(отношений) между ними. Оно необходимо для того, чтобы определить, какие данные
будут в таблицах разрабатываемой БД, а также логические ограничения полей этих
таблиц [18].
Формализованное описание предметной области представлено в таблице 2.2
Таблица 2.2 - Формализованное описание предметной области
|
Объект
|
Ключ
|
Физические характеристики
|
Обязательность значения
|
Логические ограничения
|
Процессы
|
|
ПОМЕЩЕНИЕ
|
|
ID помещения
|
УК, ПК
|
Целое 5
|
непустое
|
>0
|
Г, Пр
|
|
Имя
|
|
Символьное 30
|
непустое
|
|
Вв,Пр,У
|
|
Номер
|
|
Символьное 4
|
непустое
|
>0
|
Вв,Пр,У
|
|
Этаж
|
|
Целое 1
|
непустое
|
>0
|
Вв,Пр,У
|
|
ID типа помещения
|
|
Целое 5
|
непустое
|
>0
|
Пр
|
|
ТИПЫ ПОМЕЩЕНИЙ
|
|
ID типа помещения
|
УК, ПК
|
Целое 5
|
непустое
|
>0
|
Г, Пр
|
|
Тип
|
|
Символьное 30
|
непустое
|
|
Вв,Пр,У
|
|
Описание
|
|
Символьное 10
|
непустое
|
|
Вв,Пр,У
|
|
ОБОРУДОВАНИЕ
|
|
ID оборудования
|
УК, ПК
|
Целое 5
|
непустое
|
>0
|
Г, Пр
|
|
ID типа оборудования
|
|
Целое 5
|
непустое
|
>0
|
Пр
|
|
ID помещения
|
|
Целое 5
|
непустое
|
>0
|
Пр
|
|
Инвентарный
номер
|
|
Символьное 10
|
непустое
|
>0
|
Пр
|
|
Объект
|
Ключ
|
Физические характеристики
|
Обязательность значения
|
Логические
ограничения
|
Процессы
|
|
Серийный номер
|
|
Символьное 10
|
непустое
|
>0
|
Пр
|
|
Ввод в
эксплуатацию
|
|
Дата
|
непустое
|
дд.мм.ггг
|
Вв,Об,Пр,У
|
|
Имя
|
|
Символьное 30
|
непустое
|
|
Вв,Пр,У
|
|
ТИП ОБОРУДОВАНИЯ
|
|
ID типа оборудования
|
УК, ПК
|
Целое 5
|
непустое
|
>0
|
Г, Пр
|
|
Тип оборудования
|
|
Символьное 30
|
непустое
|
|
Вв,Пр,У
|
|
Описание
|
|
Символьное 100
|
непустое
|
|
Вв,Пр,У
|
|
КЛАССЫ ОБОРУДОВАНИЯ
|
|
ID класса
|
УК, ПК
|
Целое 5
|
непустое
|
>0
|
Г, Пр
|
|
Класс оборудования
|
|
Символьное 30
|
непустое
|
>0
|
Вв,Пр,У
|
|
Описание
|
|
Символьное 100
|
непустое
|
|
Вв,Пр,У
|
|
ПОЛЬЗОВАТЕЛИ
|
|
ID пользователя
|
УК, ПК
|
Целое 5
|
непустое
|
>0
|
Г, Пр
|
|
ID типа пользователя
|
|
Целое 5
|
непустое
|
>0
|
Пр, Об
|
Ключ
|
Физические характеристики
|
Обязательность значения
|
Логические
ограничения
|
Процессы
|
|
Логин
|
|
Символьное 20
|
непустое
|
|
Вв,Об,Пр,У
|
|
Пароль
|
|
Символьное 20
|
непустое
|
|
Вв,Об,Пр,У
|
|
Фамилия
|
|
Символьное 30
|
непустое
|
|
Вв,Об,Пр,У
|
|
Имя
|
|
Символьное 20
|
непустое
|
|
Вв,Об,Пр,У
|
|
Отчество
|
|
Символьное 20
|
непустое
|
|
Вв,Об,Пр,У
|
|
Инициалы
|
|
Символьное 20
|
непустое
|
|
Г
|
|
ТИП ПОЛЬЗОВАТЕЛЯ
|
|
ID типа пользователя
|
УК, ПК
|
Целое 5
|
непустое
|
>0
|
Г, Пр
|
|
Тип пользователя
|
|
Символьное 15
|
непустое
|
|
Вв,Пр,Об,У
|
|
ЗАЯВКИ
|
|
ID заявки
|
УК, ПК
|
Целое 5
|
непустое
|
>0
|
Г, Пр
|
|
ID пользователя
|
|
Целое 5
|
непустое
|
>0
|
Пр, Об
|
|
ID помещения
|
|
Целое 5
|
непустое
|
>0
|
Пр, Об
|
|
ID устройства
|
|
Целое 5
|
непустое
|
>0
|
Пр, Об
|
|
Объект
|
Ключ
|
Физические характеристики
|
Обязательность значения
|
Логические
ограничения
|
Процессы
|
|
ID класса устройства
|
|
Целое 5
|
непустое
|
>0
|
Пр, Об
|
|
Дата создания
|
|
Дата
|
непустое
|
дд.мм.ггг
|
Вв,Об,Пр,У
|
|
Дата выполнения
|
|
Дата
|
непустое
|
дд.мм.ггг
|
Вв,Об,Пр,У
|
|
ID статуса
|
|
Целое 5
|
непустое
|
>0
|
Пр, Об
|
|
СТАТУС ЗАЯВКИ
|
|
ID статуса
|
УК, ПК
|
Целое 5
|
непустое
|
>0
|
Г, Пр
|
|
Статус
|
|
Символьное 15
|
непустое
|
|
Вв,Пр,Об,У
|
|
|
|
|
|
|
|
|
|
В таблице 2.2 использованы следующие сокращения: УК -
уникальный ключ, ПК - первичный ключ Г - генерация данных, Вв - ввод данных, Пр
-просмотр данных, Об - обновление, У - удаление.
Теперь необходимо выявить взаимосвязи сущностей предметной
области.
Связь - ассоциирование двух или более сущностей (объектов). Одно из
основных требований к организации базы данных - это обеспечение возможности
отыскания одних сущностей по значениям других, для чего необходимо установить
между ними определенные связи. А так как в реальных базах данных нередко
содержатся сотни или даже тысячи сущностей, то теоретически между ними может
быть установлено более миллиона связей. Наличие такого множества связей и
определяет сложность инфологических моделей.
Существующие типы связей:
первый тип - связь один-к-одному (1:1). В каждый момент времени каждому
представителю (экземпляру) сущности А соответствует 1 или 0 представителей
сущности В;
- второй тип - связь один-ко-многим (1:М). Одному представителю сущности
А соответствуют 0, 1 или несколько представителей сущности В, но каждому
представителю сущности В может соответствовать только один представитель из А. Связь один-ко-многим является самой распространенной для
реляционных баз данных, она позволяет моделировать иерархические структуры
данных;
- третий тип - связь многие-ко-многим (М:М). Представителю сущности А
может сопоставляться несколько представителей таблицы В, и наоборот. Такой тип
связи создается определением третьей сущности, которая называется сущностью
соединения, чей первичный ключ состоит из внешних ключей А и В.
Связи между сущностями, их тип и описание связи отражены в таблице 2.3.
Таким образом, на основании связей между сущностями можно определить, в
какой зависимости находятся объекты модели. Процесс моделирования взаимосвязей
между сущностями присутствует на всех этапах проектирования модели базы данных.
При этом каждая связь прорабатывается с обеих сторон. Окончательно все связи
устанавливаются в результате процесса нормализации.
Таблица 2.3 - Связи между сущностями
|
Название связи
|
Тип связи
|
Сущность 1
|
Сущность 2
|
|
соответствует
|
М:1
|
Помещение
|
Определенному типу
помещения
|
|
соответствует
|
М:1
|
Тип оборудования
|
Определенному классу
оборудования
|
|
соответствует
|
М:1
|
Пользователь
|
Определенному типу
пользователя
|
|
соответствует
|
М:1
|
Оборудование
|
Определенному помещению
|
|
соответствует
|
1:М
|
Пользователь
|
Различное множество заявок
|
|
соответствует
|
М:1
|
Оборудование
|
Определенному типу
оборудования
|
|
соответствует
|
1:М
|
Помещение
|
Различному множеству заявок
|
|
имеют
|
М:1
|
Заявки
|
Определенный статус
|
|
соответствует
|
М:1
|
Заявки
|
Определенное оборудование
|
.2.2
Разработка инфологической модели БД
Целью этапа инфологического проектирования является разработка
концептуальной информационно-логической модели предметной области, отражающей
логику информации предприятия. В предметной области в процессе ее исследования
и анализа выделяются классы объектов [19].
ИЛМ предметной области представлена в виде ER-диаграммы предметной
области, построенной по методологии Ричарда Баркера. Основные элементы ER -
модели в методологии Ричарда Баркера: сущность, атрибуты, уникальные
идентификаторы, опциональность атрибутов, связи, опциональность и переносимость
связей, уникальность объекта из связи, супертипы, подтипы, арки.диаграмма -
четырехугольник с закругленными углами. В нем описан класс объектов - это
значимая вещь, о которой предприятие должно хранить информацию со свойствами -
качественное или количественное описание класса объекта. Значение свойства
может быть обязательным или необязательным. Такая характеристика свойства
называется опциональностью свойства. ER-диаграмма по методологии Ричарда
Баркера показана на рисунке 2.2.
Рисунок 2.2 - Инфологическая модель БД
Обязательность свойства помечается "*". Необязательные значения
свойства помечается "о".
Уникальный идентификатор (УИ) - любая комбинация свойств и связей,
используемых для однозначной идентификации объекта. Количество УИ в классе
объектов может быть каким угодно. На диаграмме идентификатор обозначается
"#", если УИ несколько, порядок обозначается числом в скобках.
Обязательная связь помечается сплошной линией, необязательная -
пунктирной. Тип (мощность) связи "один" помечается линией,
"много" - "вороньей лапой".
2.2.3
Разработка даталогической модели БД
После построения ИЛМ предметной области согласно этапам нисходящего
проектирования проектируется даталогическая (ДЛМ) модель БД. Основным элементом
структуры данных в ДЛМ является реляционное отношение. Существует несколько
видов представления реляционного отношения: таблица, математическая запись,
графическое изображение.
На графическом изображении название таблиц выделено. Помечены первичные
ключи. Связи прорисованы линями, идущими горизонтально и вертикально. Линии
связи идут от первичного ключа к соответствующему внешнему ключу. Возле
атрибута внешнего ключа (на стороне "много") линия связи
заканчивается черным кругом.
Даталогическая модель разрабатываемой базы данных отображена на рисунке
2.3.
Рисунок 2.3 - Даталогическая модель реляционной БД
.2.4 Нормализация
отношений
Процесс проектирования БД с использованием метода нормальных форм
является итерационным и заключается в последовательном переводе отношений из
первой нормальной формы в нормальные формы более высокого порядка по
определенным правилам.
Нормализация выполняется поэтапно.
Первая нормальная форма (1НФ). Для нее требуется, чтобы таблица базы
данных была плоской и не содержала повторяющихся групп. У плоской таблицы есть
только две характеристики - длина (количество записей или строк) и ширина (количество
полей или столбцов). Такая таблица не должна содержать ячеек, включающих
несколько значений.
Никакую из систем управления базами данных (СУБД) не удовлетворяет только
1НФ, так как в этом случае необходимо определить большое число полей, многие из
которых остаются в основном пустыми. Избыточные данные могут послужить причиной
проблем целостности и снижение эффективности при внесении изменений, поэтому
подобных решений при проектировании баз данных необходимо избегать.
Вторая нормальная форма (2НФ). Для 2НФ требуется, чтобы все поля таблицы
зависели от первичного ключа, то есть, чтобы первичный ключ однозначно
определял запись и не был избыточен. 2НФ позволяет удалить большую часть
повторяющихся данных, которые часто остаются после первого этапа нормализации.
Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы
таблицы зависели от первичного ключа таблицы, но были независимы друг от друга.
Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ [20].
Еще существует 3НФБК, 4НФ и 5НФ, но для большинства существующих СУБД
необходимо представить проект базы данных в ЗНФ, так как этого вполне
достаточно практически для всех обычных приложений.
Логическая структура базы данных, спроектированная в рамках данной
дипломной работы, находится в третьей нормальной форме, исходя из следующего:
структура БД находится в первой нормальной форме, так как все таблицы
являются плоскими и не содержат повторяющихся групп;
структура БД находится во второй нормальной форме, так как она находится
в первой и для каждого объекта БД все не ключевые атрибуты функционально
полностью зависят от составного первичного ключа;
структура БД находится в третьей нормальной форме, так как она находится
во второй нормальной форме и в ней отсутствуют транзитивные зависимости между
не ключевыми атрибутами и первичным ключом.
.2.5
Физическая модель БД
Под физическим проектированием понимают процесс создания эффективной
реализуемой структуры физической базы данных по заданной логической структуре,
полученной исходя из требований пользователя к информации. Физическое
проектирование часто предполагает удовлетворение определенным эксплуатационным
ограничениям, таким, как требования к объему памяти и к распределению времени
отклика.
Основная единица данных в физических структурах - хранимая запись. Она
представляет собой совокупность связанных элементов данных (атрибутов), которая
соответствует одной или нескольким логическим записям, она содержит все
необходимые указатели, длину записи и некоторые дополнительные данные, а также
схему кодирования для символьного представления [21]. Под хранимой записью в
СУБД PostgreSQL понимается таблица со своими
атрибутами.
.2.5.1
Техническое описание объектов БД
Техническое описание проектируемых объектов БД на языке определения
данных СУБД PostgreSQL можно представить в виде таблиц и
операторов на языке DDL.
Далее в таблицах 2.4-2.12 идет техническое описание атрибутов, по каждой
таблице представлен оператор описания на языке DDL.
Таблица 2.4 - Описание атрибутов класса DeviceClasses
|
Field
|
Type
|
Length
|
Default
|
Not Null
|
Index
|
Auto_increment
|
|
Idclass
|
int
|
10
|
null
|
+
|
primary
|
+
|
|
class
|
varchar
|
30
|
null
|
+
|
-
|
-
|
|
description
|
text
|
255
|
null
|
-
|
-
|
-
|
Оператор:
CREATE TABLE "DeviceClasses"
(integer NOT NULL,text,
"class" character varying(30),"PK_КлассыОборудования" PRIMARY KEY
(idclass)
)(=FALSE
);TABLE "DeviceClasses" OWNER TO postgres;
Таблица 2.5 - Описание атрибутов класса DeviceTypes
|
FieldTypeLengthDefaultNot
NullIndexAuto_increment
|
|
|
|
|
|
|
|
Idtype
|
int
|
10
|
null
|
+
|
primary
|
+
|
|
device
|
varchar
|
255
|
null
|
+
|
-
|
-
|
|
description
|
text
|
255
|
null
|
-
|
-
|
-
|
Оператор:
CREATE TABLE "DeviceTypes"
(integer NOT NULL,character(255) NOT NULL,text,integer NOT
NULL,"PK_СправочникТипаОборудования" PRIMARY KEY (idtype)
)(=FALSE
);TABLE "DeviceTypes" OWNER TO postgres;
Таблица 2.6 - Описание атрибутов класс Users
|
Field
|
Type
|
Length
|
Default
|
Not Null
|
Index
|
Auto_increment
|
|
id
|
int
|
3
|
null
|
+
|
primary
|
+
|
|
login
|
varchar
|
20
|
null
|
+
|
-
|
-
|
|
pas
|
varchar
|
20
|
null
|
+
|
-
|
-
|
|
Surname
|
varchar
|
30
|
null
|
+
|
-
|
-
|
|
Name
|
varchar
|
30
|
null
|
+
|
-
|
-
|
|
FName
|
varchar
|
30
|
null
|
+
|
-
|
-
|
|
shortName
|
varchar
|
20
|
null
|
+
|
-
|
-
|
|
Id_type_user
|
int
|
2
|
null
|
+
|
-
|
-
|
Оператор:
CREATE TABLE "Users"
(
"login" character varying(20) NOT NULL DEFAULT
NULL::character varying,character varying(20) NOT NULL DEFAULT NULL::character
varying,
"Surname" character varying(30) NOT NULL DEFAULT
NULL::character varying,
"Name" character varying(20) NOT NULL DEFAULT
NULL::character varying,
"FName" character varying(20) NOT NULL DEFAULT
NULL::character varying,
"typeUser" integer NOT NULL,
"shortName" character(20) NOT NULL,bigint NOT NULL
DEFAULT
nextval('"Users_Id_user_seq"'::regclass),"PK_Пользователь"
PRIMARY KEY (id),"FK_Id_type" FOREIGN KEY
("typeUser")"TypeUsers" ("typeUser") MATCH
SIMPLEUPDATE NO ACTION ON DELETE NO ACTION
)(=FALSE);TABLE "Users" OWNER TO postgres;
Таблица 2.7 - Описание атрибутов класса TypeUsers
|
Field
|
Type
|
Length
|
Default
|
Not Null
|
Index
|
Auto_increment
|
|
typeUser
|
int
|
2
|
null
|
+
|
primary
|
+
|
|
name
|
varchar
|
15
|
null
|
+
|
-
|
-
|
Оператор:
CREATE TABLE "TypeUsers"
(
"typeUser" integer NOT NULL,
"name" character(15) NOT
NULL,"PK_ТипПользователя" PRIMARY KEY ("typeUser")
)(=FALSE
);TABLE "TypeUsers" OWNER TO postgres;
Таблица 2.8 - Описание атрибутов класса devices
|
Field
|
Type
|
Length
|
Default
|
Not Null
|
Index
|
Auto_increment
|
|
iddevice
|
20
|
null
|
+
|
primary
|
+
|
|
nameDevice
|
varchar
|
30
|
null
|
+
|
-
|
-
|
|
inventorynumber
|
varchar
|
30
|
null
|
+
|
-
|
-
|
|
idtype
|
int
|
10
|
null
|
+
|
-
|
-
|
|
idroom
|
int
|
10
|
null
|
+
|
-
|
-
|
|
exploitation
date
|
datetime
|
0
|
null
|
+
|
-
|
-
|
Оператор:
CREATE TABLE devices
(integer NOT NULL,integer NOT NULL,character(30) NOT
NULL,character(255) NOT NULL,date NOT NULL,
"nameDevice" character(30) NOT NULL,bigserial NOT
NULL,"PK_Устройства" PRIMARY KEY (iddevice),"FK_idroom"
FOREIGN KEY (idroom)"Rooms" (idroom) MATCH SIMPLEUPDATE NO ACTION ON
DELETE NO ACTION,"FK_idtype" FOREIGN KEY
(idtype)"DeviceTypes" (idtype) MATCH SIMPLEUPDATE NO ACTION ON DELETE
NO ACTION
)(=FALSE
);TABLE devices OWNER TO postgres;
Таблица 2.9 - Описание атрибутов класса Status
|
Field
|
Type
|
Length
|
Default
|
Not Null
|
Index
|
Auto_increment
|
|
idstatus
|
int
|
1
|
null
|
+
|
primary
|
+
|
|
statusname
|
varchar
|
15
|
null
|
+
|
-
|
-
|
Оператор:
CREATE TABLE "Status"
(integer NOT NULL,character varying(15) NOT
NULL,"PK_Справочник_статусов" PRIMARY KEY (idstatus)
)(=FALSE);TABLE "Status" OWNER TO postgres;
Таблица 2.10 - Описание атрибутов класса Demands
|
Field
|
Type
|
Length
|
Default
|
Not Null
|
Index
|
Auto_increment
|
|
iddemand
|
int
|
20
|
null
|
+
|
primary
|
+
|
|
Field
|
Type
|
Length
|
Default
|
Not Null
|
Index
|
Auto_increment
|
|
iddevice
|
varchar
|
20
|
null
|
+
|
-
|
-
|
|
Description
|
text
|
500
|
null
|
+
|
-
|
-
|
|
Id_user
|
int
|
3
|
null
|
+
|
-
|
-
|
|
datetimeCreat
|
datetime
|
0
|
null
|
+
|
-
|
-
|
|
datetime
|
datetime
|
0
|
null
|
+
|
-
|
-
|
|
idstatus
|
int
|
1
|
null
|
+
|
-
|
-
|
|
idroom
|
int
|
10
|
null
|
+
|
-
|
-
|
Оператор:
CREATE TABLE demands
(
"Id_user" bigint NOT NULL,integer NOT NULL,integer
NOT NULL,bigint NOT NULL,
"datetimeCreat" timestamp with time zone NOT
NULL,timestamp with time zone NOT NULL,integer NOT NULL,bigserial NOT NULL,text
NOT NULL,"PK_Заявка" PRIMARY KEY (iddemand),"FK_Id_user"
FOREIGN KEY ("Id_user")"Users" (id) MATCH SIMPLEUPDATE NO
ACTION ON DELETE NO ACTION,"FK_idstatus" FOREIGN KEY
(idstatus)"DemandStatus" (idstatus) MATCH SIMPLEUPDATE NO ACTION ON
DELETE NO ACTION,"FK_idtypedem" FOREIGN KEY (idtypedem)"TypeDemands"
(idtypedem) MATCH SIMPLEUPDATE NO ACTION ON DELETE NO ACTION
)(=FALSE
);TABLE demands OWNER TO postgres;
Таблица 2.11 - Описание атрибутов класса RoomTypes
|
Field
|
Type
|
Length
|
Default
|
Not Null
|
Index
|
Auto_increment
|
|
idtype
|
int
|
10
|
null
|
+
|
primary
|
+
|
|
type
|
varchar
|
30
|
null
|
+
|
-
|
-
|
|
description
|
text
|
255
|
null
|
-
|
-
|
-
|
Оператор:
CREATE TABLE "RoomTypes"
(integer NOT NULL,
"type" character(30) NOT NULL,text,"PK_Тип помещений" PRIMARY KEY (idtype)
)(=FALSE
);TABLE "RoomTypes" OWNER TO postgres;
Таблица 2.12 - Описание атрибутов класса Rooms
|
Field
|
Type
|
Length
|
Default
|
Not Null
|
Index
|
Auto_increment
|
|
idroom
|
int
|
10
|
null
|
+
|
primary
|
+
|
|
name
|
varchar
|
30
|
null
|
+
|
-
|
-
|
|
number
|
varchar
|
4
|
null
|
+
|
-
|
-
|
|
storey
|
int
|
1
|
null
|
+
|
-
|
-
|
|
idtype
|
int
|
10
|
null
|
+
|
-
|
+
|
Оператор:
CREATE TABLE "Rooms"
(
"name" character(30) NOT NULL,
"number" character(4) NOT NULL,smallint,integer NOT
NULL,bigserial NOT NULL,"PK_Помещения" PRIMARY KEY
(idroom),"FK_idtype" FOREIGN KEY (idtype)"RoomTypes"
(idtype) MATCH SIMPLEUPDATE NO ACTION ON DELETE NO ACTION
)(=FALSE
);TABLE "Rooms" OWNER TO postgres;
2.2.5.2
Реализация ограничений целостности БД
Создаваемая и эксплуатируемая реляционная база данных должна быть
целостной и надежной. Поддержка целостности реляционной БД рассматривается в
трех аспектах.
Целостность таблицы. Обязательно должны поддерживаться:
уникальность строк таблицы. Должен быть определен первичный ключ таблицы,
и значение его должно быть определено;
все уникальные ключи, выявленные в ходе анализа предметной области.
Эти ограничения реализуются в командах создания и модификации таблиц.
Например, в языке SQL это команды Create Table, Alter Table. В этих командах
для описания полей - первичных ключей используется конструкция Primary Key, для
описания полей - уникальных ключей конструкция Unique, обязательность значений
полей задается конструкцией Not Null.
Ссылочная целостность. Каждая таблица проектируемой БД должна быть
связана с другими посредством соответствующих первичных и внешних ключей.
Назначение внешнего ключа - связывать каждую строку дочерней таблицы с
соответствующей строкой родительской таблицы. Значение внешнего ключа может
иметь и пустое значение (Null), если он реализует необязательную связь,
выявленную в предметной области. В качестве значения внешнего ключа может
выступать значение и любого уникального (потенциального) ключа [22].
Декларативные ограничения данных. Так называют ограничения реляционной
базы данных, объявленные предметной областью и выявленные в ходе её анализа.
Задача проектировщика БД - адекватно отобразить их в БД.
Самые распространенные ограничения предметной области - это ограничения
на свойства объекта предметной области, далее атрибута отношения или поля
таблицы:
обязательность значения поля;
тип, длина, диапазон значения поля (например, значение должно быть целым
и положительным), вхождение значения в заданный список и т.п.
Такие ограничения могут быть заданы в командах создания и модификации
таблиц - Create Table, Alter Table при описании поля таблицы.
Ниже рассмотрена реализация ограничений целостности БД на примере таблица
"Status":
CREATE TABLE "Status"
(integer NOT NULL,character varying(15) NOT
NULL,"PK_Справочник_статусов" PRIMARY KEY (idstatus)
)(=FALSE
);TABLE "Status" OWNER TO postgres;
Такие записи как NOT NULL, character varying(15) обеспечивают поддержку ограничений предметной
области, запись PRIMARY
KEY (idstatus)обеспечивают поддержку ограничений
первичного ключа.
Реализация ограничений целостности БД аналогична для остальных таблиц.
.3
Разработка программного средства автоматизации обслуживания заявок
Разработка велась согласно следующей модели жизненного цикла [23],
представленной на рисунке 2.4.
Рисунок 2.4 - Поэтапная модель жизненного цикла
На этапе разработки требований необходимо тесное взаимодействие с
будущими пользователями и сотрудниками отдела ИТ. На данном этапе определяются
границы разрабатываемого средства, его основные функции.
В ходе беседы с пользователями и сотрудниками ОИТ были определены
следующие функции программы:
подача и принятие заявок на обслуживание и установку компьютерной
оргтехники;
осуществление контроля над исполнением заявок;
генерирование отчетов.
На этапе проектирования необходимо провести исследование бизнес-процессов
и информации, необходимой для их выполнения, а также сформировать набор
спецификаций для разрабатываемого средства.
Необходимые бизнес-процессы можно отобразить с помощью диаграммы
вариантов использования и диаграммы состояний.
Диаграммы вариантов использования - это один из видов диаграмм UML,
предназначенных для моделирования динамических аспектов систем. Диаграммы
вариантов использования - основной вид диаграмм при моделировании поведения
системы, подсистемы или класса. Каждая из них показывает набор вариантов
использования и действующих лиц в их взаимодействии.
Создание диаграммы вариантов использования имеет следующие цели:
определить общие границы и контекст моделируемой предметной области на
начальных этапах проектирования системы;
сформулировать общие требования к функциональному поведению проектируемой
системы;
разработать исходную концептуальную модель системы для ее последующей
детализации в форме логических и физических моделей;
подготовить исходную документацию для взаимодействия разработчиков
системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система
представляется в виде множества сущностей или актеров, взаимодействующих с
системой с помощью вариантов использования. При этом актером или действующим
лицом называется любая сущность, взаимодействующая с системой извне. Это может
быть человек, техническое устройство, программа или любая другая система,
которая может служить источником воздействия на моделируемую систему так, как
определит сам разработчик. В свою очередь, вариант использования служит для
описания сервисов, которые система предоставляет актеру. Другими словами,
каждый вариант использования определяет некоторый набор действий, совершаемый
системой при диалоге с актером. При этом ничего не говорится о том, каким
образом будет реализовано взаимодействие актеров с системой.
Актер представляет собой любую внешнюю по отношению к моделируемой
системе сущность, которая взаимодействует с системой и использует ее
функциональные возможности для достижения определенных целей или решения
частных задач. При этом актеры служат для обозначения согласованного множества
ролей, которые могут играть пользователи в процессе взаимодействия с
проектируемой системой. Каждый актер может рассматриваться как некая отдельная
роль относительно конкретного варианта использования [24].
На диаграмме изображено два актера:
администратор;
пользователь.
Актеры между собой взаимодействуют с помощью четырёх вариантов
использования:
пройти авторизацию. Данный вариант использования подразумевает
авторизацию каждого актера путем проверки логина и пароля;
просмотреть свои заявки. Данный вариант использования позволяет
пользователю просматривать свои заявки, поданные ранее;
просмотреть текущие заявки. Этот вариант использования подразумевает
просмотр имеющихся заявок администратором БД, при желании он может их удалять и
менять их статус;
подать новую заявку. Этот вариант использования позволяет пользователю
подавать новые заявки;
Готовая диаграмма вариантов использования изображена на рисунке 2.5.
Рисунок 2.5 - Диаграмма вариантов использования
Главное предназначение диаграммы состояний - описать возможные
последовательности состояний и переходов, которые в совокупности характеризуют
поведение элемента модели в течение его жизненного цикла. Диаграмма состояний
представляет динамическое поведение сущностей, на основе спецификации их
реакции на восприятие некоторых конкретных событий [25].
Поведение проектируемого программного средства описывается следующими
состояниями. Авторизация/регистрация - состояние, которое в свою очередь
делится на два состояния: ввод данных для регестрации и ввод данных для
авторизации. При успешной авторизации возможны следующие состояния: для актера
"администратор": просмотр данных о правах пользователей, подача новой
заявки, просмотр текущих заявок; для актера "пользователь": подача
новой заявки, просмотр текущих заявок.
Диаграмма состояний для разрабатываемого программного средства отображена
на рисунке 2.6.
Рисунок 2.6 - Диаграмма состояний
Приступая к этапу реализации программного средства, следует помнить, что
оно является большой программной системой, поэтому целесообразно принять меры
для его упрощения, разделив весь процесс на отдельные модули [26]. Такое
разбиение позволит:
а) упростить их разработку и реализацию;
б) облегчить чтение программы;
в) упростить настройку и модификацию;
г) облегчить работу с данными, имеющими сложную структуру;
д) избежать чрезмерной детализации алгоритмов;
е) обеспечить более выгодное размещение программ в памяти ЭВМ.
Модуль - фрагмент программного текста, являющийся строительным блоком для
физической структуры системы. Как правило, модуль состоит из интерфейсной части
и части-реализации [27].
Модульная структура разрабатываемого автоматизированного средства по
обслуживанию заявок отображена на рисунке 2.7.
Рисунке 2.7 - Модульная структура
автоматизированного средства
Модуль идентификации и аутентификации является основным модулем,
разграничивающим права доступа пользователям программы, а также предоставляет
пользователям графический интерфейс для работы.
Модуль регистрации пользователя предоставляет форму для
заполнения полей данными о пользователе с последующим внесением их в базу
данных.
Модуль создания интерфейса формы для подачи новой заявки
генерирует поля, отображаемы в форме, и осуществляет связь с модулем добавления
заявки в БД.
Модули доступа к таблицам БД выполняют соединение с базой
данных и выборку полей из соответствующих таблиц.
Модуль добавления заявки в БД выполняет соединение с базой
данных и обновление полей таблицы заявок.
Модуль создания интерфейса для просмотра текущих заявок
осуществляет вывод данных из таблицы заявок БД в форму просмотра.
Листинг данных модулей представлен в приложении Б.
На этапе тестирования было сделано следующее: на одном из компьютеров ОИТ
был установлен сервер приложений Tomcat
и развернута созданная база данных. Далее на этот же компьютер было установлено
спроектированное программное средство. После чего пользователем была отправлена
заявка на установку проектора (мультимедиа оборудование). Она прошла успешную
обработку и в последующем удалена из БД. Необходимо отметить, что процесс
обработки заявки в очереди проводился при 100% загрузке пользователями базы
данных. Все испытания прошли успешно, недостатков и ошибок не было выявлено.
Во втором разделе проведена следующая работа:
представлено обоснование выбора и описание инструментальных средств:
языка программирования, СУБД, языка запросов;
представлено описание принципов работы Java web-приложения;
проанализирована архитектура АСУОД Tandem, функционирующая в Филиале;
разработана БД проектируемого средства;
разработано программное средство автоматизации обслуживания заявок
пользователей ЛВС Филиала.
3.
Технико-эксплуатационный раздел
.1
Руководство для пользователей
Взаимодействие пользователя с программным средством осуществляется через
веб-интерфейс. Для запуска необходимо указать в адресной строке обозревателя
путь к программному средству (#"600513.files/image058.gif">
Рисунок 3.1 - Страница авторизации пользователя
Если пользователь ранее не был зарегистрирован, то ему необходимо перейти
по ссылке на страницу регистрации для заполнения соответствующих полей как
показано на рисунке 3.2.
Рисунок 3.2 - Страница регистрации пользователя
При успешной регистрации откроется страница, изображённая на рисунке 3.3.
После чего необходимо будет пройти авторизацию.
Рисунок 3.3 - Успешная регистрация
После успешной авторизации откроется меню пользователя, изображенное на
рисунке 3.4. Выделение двух типов заявок основывается на принципиальном
различие форм заполнения заявок на мультимедиа оборудование и компьютерную
оргтехнику. При выборе определенного типа откроется страница выбора дальнейших
действий, изображённая на рисунке 3.5.
Рисунок 3.4 - Меню пользователя
В зависимости от того как прописан пользователь в базе данных он может
являться одним из актеров: администратор, либо пользователь какого-либо другого
отдела. При авторизации администратора ему предоставляется возможность
просмотреть текущие заявки, создать новую заявку либо управлять правами
пользователей.
Рисунок 3.5 - Меню выбора действия
Для внесения изменений в данные о правах пользователей необходимо перейти
по ссылке "Пользователи" из меню пользователя, после чего откроется
страница, изображенная на рисунке 3.6. При нажатии на ссылку "НЕТ" её
значение изменяется на противоположное, что означает присвоение прав
администратора данному пользователю. Так же изменяется значение типа
пользователя в базе данных.
Рисунок 3.6 - Меню управления пользователями
Чтобы просмотреть заявки, необходимо пройти по ссылке "Просмотреть
заявки" на соответствующую страницу, которая изображена на рисунке 3.7.
Для удобства просмотра, осуществляется выборка заявок из базы данных по определенным
периодам.
Рисунок 3.7 - Меню выбора периода заявок
Просматривая текущие заявки на мультимедиа оборудование, администратор
имеет возможность менять их статус на принята или не принята. На странице
просмотра отображается следующая информация: пользователь, запросивший
оборудование; пользователь, создавший заявку; номер аудитории в которую
необходимо установить оборудование; дата и время установки; статус принятия
заявки; статус выполнения. Дата регистрации заявки формируются автоматически.
Страница просмотра текущих заявок на мультимедиа оборудование показана на
рисунке 3.8.
Рисунок 3.8 - Страница просмотра заявок на мультимедиа оборудование
При авторизации пользователя, ему предоставляется возможность только
просмотреть текущие заявки или создать новую. Меню пользователя идентично меню
администратора. При попытке пользователя пройти по ссылке на страницу
управления правами пользователей, программное средство выдаст сообщение, как
показано на рисунке 3.9.
Рисунок 3.9 - Страница ошибки
При подаче новой заявки на обслуживание компьютерной оргтехники
пользователю необходимо заполнить форму, состоящую из следующих полей: класс
оборудования, тип оборудования, аудиторию/кабинет и номер соответствующего
помещения, наименование оборудования, описать неисправность, либо представить
план действий по конкретному оборудованию. Все поля заполняются путем выборки
соответствующего пункта из "выпадающего меню", кроме поля для ввода
описания неполадки. Страница подачи новой заявки показана на рисунке 3.10.
Рисунок 3.10 - Подача новой заявки
Каждому классу оборудования соответствует определенный тип оборудования.
Они не должны пересекаться между собой. Для класса печатающие устройства:
многофункциональное устройство (МФУ);
принтер;
плоттер.
Для класса компьютерное оборудование:
персональный компьютер;
монитор;
клавиатура;
компьютерная мышь;
USB-флеш-накопитель;
сервер;
сетевой кабель;
ноутбук.
Для класса мультимедиа-оборудования:
проектор;
веб-камера;
устройства вывода звука (колонки).
.2
Руководство для серверной части
В основе функционирования разрабатываемого программного средства лежит
клиент-серверная технология. В качестве серверной части был выбран сервер
приложений Tomcat7.позволяет запускать веб-приложения,
содержит ряд программ для самоконфигурирования. Он используется в качестве
самостоятельного веб-сервера, в качестве сервера контента в сочетании с
веб-сервером Apache HTTP Server, а также в качестве контейнера сервлетов в
сервере приложений JBoss.
Перед началом работы с разработанным программным средством необходимо
правильно настроить сервер Tomcat.
Для своей работы он требует установки нескольких переменных окружения:
CATALINA_HOME должна указывать на каталог с
установленным Tomcat;
JAVA_HOME должна указывать на каталог с SDK.
Эти переменные прописываются в свойствах системы в переменных среды как
показано на рисунке 3.11.
Рисунок 3.11 - Окно настройки переменных среды
При неверной установке этих переменных Tomcat выводит сообщение об ошибке.
Для работы программного средства автоматизации обслуживания заявок,
необходимо чтобы сервер был всегда запущен. Установка сервера как сервиса Windows NT исключит необходимость запускать сервер вручную при каждом
включение компьютера. Для этого необходимо выполнить команду в командной
строке:
%CATALINA_HOME%\bin\tomcat.exe
install Apache-Catalina
%JAVA_HOME%\jre\bin\server\jvm.dll -DJava.class.path=%CATALINA_EOME%
\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar
Dcatalina.home=%CATALINA_HOME%
%CATALINA_OPTS% -Xrs
start
org.apache.catalina.scartup.BootstrapService -params start
stop
org.apache.catalina.startup.BootstrapService -params stop
out %CATALINA_HOME%\logs\stdout.log
err %CATALINA_HOME%\logs\stderr.log
Эта команда последовательно указывает:
- имя сервиса, которое будет отображаться в оснастке Services Windows. Имя сервиса используется также для создания имени
ключа реестра, поэтому пробелов там быть не должно;
ссылку на библиотеку Java-машины с рядом необходимых параметров. Среди которых
параметры, указанные в переменной catalina_opts . Собственно эта библиотека и будет
загружена как сервис;
на методы запуска и остановки сервиса, также с
необходимыми параметрами;
ссылки на файлы журналов и ряд других необязательных
параметром.
После чего сервер Tomcat
появится в службах Windows как
показано на рисунке 3.12. Через службы можно настроить его на автозапуск. Так
же можно остановить, либо перезапустить сервер.
Рисунок 3.12 - Окно настройки служб Windows
3.3
Руководство администратора
Администратор отвечает за правильное функционирование серверной части
разрабатываемого программного средства, а также следит за состоянием базы
данных.
Этапы установки сервера Tomcat:
распаковать архив с дистрибутивом в каталог c:\Tomcat;
загрузить актуальную версию java JDK;
установить переменные окружения и выполнить настройку, как было
писано в главе 3.2;
удалить каталог c:\Tomcat\work;
удалить содержимое каталога c:\Tomcat\webapps;
поместить в каталог webapps файлы разработанного программного средства (каталог webapps на момент размещения должен быть
пустым);
запустить сервис Tomcat.
Далее в браузере необходимо набрать следующий адрес:
#"600513.files/image070.gif">
Рисунок 3.13 - Тестовая страница сервера приложений Tomcat
3.4
Руководство программиста
Разработанное программное средство состоит из 15 фрагментов: login.java, reg.java, DAOdemands.java, DAOusers.java, DAODevices.java, DAODeviceClasses.java, DAODeviceType.java, DAORoomTypes.java, DAORooms.java, AddDemand.java, AdmAccept.java, AdmUser.jsp, submitDemand.jsp, DAORequest.java, SelRequest.java.
Страница submitDemand.jsp содержит форму для оформления
заявки; ссылку "Отправить заявку", ссылающуюся на сервелет AddDemand.java; ссылку на index.html
Страница index.html - содержит ссылки "Добавить заявку" на
submitDemand.jsp и "Просмотреть заявки" на showRequest.html
Страница showRequest.html содержит ссылки на сервлеты: TodayRequest, TomorrowRequest, EndWeekRequest, WeekendRequest, TimeIntervalRequest и ссылку на index.html.
Обработка всех JAVA-сервлетов
осуществляется сервером Tomcat,
который является контейнером сервлетов. Все SQL-скрипты обрабатываются СУБД PostgreSQL.
Подготовка локальной вычислительной сети к работе заключается в проверке
соединений командой ping. Конечный
адрес 127.0.0.1. Окно ввода команды ping показано на рисунке 3.14.
В результате выполнения данной команды появится окно обмена пакетами с
адресом 127.0.0.1. При правильной настройке ЛВС обмен пакетами закончится
успешно.
Рисунок 3.14 - Проверка соединений командой ping
В третьем разделе проведена следующая работа:
разработано руководство для пользователя проектируемого программного
средства. В нем описан пользовательский интерфейс, его функции и приемы работы;
разработано руководство для серверной части проектируемого модуля. В нем
описан метод настройки сервера Tomcat;
разработано руководство администратора. В нем показаны процесс установки
сервера Tomcat и тестирование его работы;
разработано руководство программиста, в котором описаны фрагменты,
ссылающиеся на другие компоненты спроектированного программного средства, и тем
самым осуществляющие логическую связь. Так же показана подготовка ЛВС к работе
средства.
4.
Обоснование экономической эффективности проекта
Широкое внедрение средств вычислительной техники во многие сферы
человеческой деятельности и повышение требований к качеству продукции остро
поставили вопрос по определению экономического эффекта от разработки и
внедрения новых программных продуктов в тех или иных областях науки и
производственной деятельности .
.1 Расчет
трудоемкости разработки программного продукта
Расчет затрат времени на разработку программного обеспечения охватывает
работы выполняемые специалистами на стадиях представленных в таблице 4.1 [28].
Таблица 4.1 -Стадии разработки программного обеспечения
|
Обозначение
|
Стадии разработки
|
|
ТЗ
|
Техническое задание
|
|
ЭП
|
Эскизный проект
|
|
ТП
|
Технический проект
|
|
РП
|
Рабочий проект
|
|
В
|
Стадия внедрения
|
При расчете фактических затрат времени необходимо учесть влияние
следующих факторов:
количество разновидностей форм входной информации;
количество разновидностей форм выходной информации;
степень новизны комплекса задач;
сложность алгоритма;
виды используемой информации;
сложность контроля входной и выходной информации;
использование типовых проектных решений.
Предусматривается четыре степени новизны разрабатываемых задач, которые
представлены в таблице 4.2.
Таблица 4.2 - Степени новизны разрабатываемых задач
|
Обозначение
|
Степень новизны
|
|
А
|
Разработка комплекса задач,
предусматривающая применение новых методов разработки, проведения
научно-исследовательских работ
|
|
Б
|
Разработка решений задач и
систем, не имеющих аналогов
|
|
В
|
Разработка решений задач и
систем, имеющих аналогичное решение
|
|
Г
|
Привязка типовых проектных
решений
|
Сложность алгоритма представлена тремя группами в таблице 4.3.
Таблица 4.3 - Группы сложности алгоритмов
|
Обозначение
|
Виды алгоритмов
|
|
С1
|
Алгоритмы оптимизации и
моделирования систем и объектов
|
|
С2
|
Алгоритмы учета и
отчетности, статистики, поиска
|
|
С3
|
Алгоритмы, реализующие
стандартные методы решения, а также не предусматривающие применение сложных
численных и логических методов
|
Трудоемкость разработки проекта зависит так же от вида используемой
информации. Виды информации представлены в таблице 4.4.
Таблица 4.4 - Виды используемой информации
|
Обозначение
|
Виды информации
|
|
ПИ
|
Переменная информация
|
|
НСИ
|
Нормативно-справочная
информация
|
|
БД
|
Базы данных
|
|
РВ
|
Режим работы в реальном
времени
|
|
ТОУ
|
Телекоммуникационная
обработка данных и управление удаленными объектами
|
Сложность организации контроля входной и выходной информации представлена
в таблице 4.5 четырьмя группами.
Таблица 4.5 - Группы сложностей организации контроля входной и выходной
информации
|
Обозначение
|
Группа сложности
|
|
11
|
Входные данные и документы
разнообразного формата и структур (контроль осуществляется перекрестно)
|
|
12
|
Входные данные и документы
однообразной формы и содержания (осуществляется формальный контроль)
|
|
21
|
Печать документов сложной многоуровневой
структуры, разнообразного содержания
|
|
22
|
Печать документов
однообразной формы и содержания, вывод массивов данных на машинные носители
|
Далее в справочных таблицах 4.6-4.11 представлены затраты времени при
выполнении различных работ на разных стадиях процесса разработки программного
продукта.
Таблица 4.6 - Затраты времени при выполнении работ на стадии технического
задания (дни)
|
Комплекс задач подсистемы
|
Степень новизны
|
|
А
|
Б
|
В
|
Г
|
|
1
|
2
|
3
|
4
|
5
|
|
Перспективное планирование,
размещение и развитие отрасли; управление проектируемым капитальным
строительством; технико-экономическое планирование; ценообразование
|
79
|
57
|
37
|
34
|
|
Управление материально -
техническим снабжением; сбытом продукции; управление комплектации импортными
и экспортными поставками
|
105
|
76
|
42
|
30
|
|
Управление бухгалтерским
учетом, финансовой деятельности предприятия
|
103
|
72
|
30
|
35
|
|
Управление организацией
труда, зарплата, кадры, нормы и нормативы, охрана труда
|
63
|
46
|
30
|
19
|
|
Учет пенсий, пособий и
страховых операций
|
79
|
55
|
36
|
26
|
|
Статистические задачи
|
129
|
111
|
61
|
38
|
|
Управление транспортными
перевозками, техобслуживанием. Вспомогательными службами и электроснабжение
|
91
|
66
|
43
|
26
|
|
Управление научно -
технической информацией. Совершенствование документооборота и контроль
исполнения документа. Управление охраной природы и окружающей среды
|
50
|
36
|
24
|
15
|
|
Задачи расчетного характера
|
92
|
69
|
47
|
2
|
|
Управление качеством
продукции, технологическими процессами производства, стандартизации,
технической подготовкой производства
|
64
|
47
|
31
|
22
|
Таблица 4.7 - Затраты времени при выполнении работ на стадии эскизного
проекта (дни)
|
Комплекс задач
|
Степени новизны
|
|
А
|
Б
|
В
|
Г
|
|
Перспективное планирование,
размещение и развитие отрасли; управление проектируемым капитальным
строительством; технико-экономическое планирование; ценообразование
|
175
|
117
|
77
|
53
|
|
Управление материально -
техническим снабжением; сбытом продукции; управление комплектации импортными
и экспортными поставками
|
115
|
79
|
53
|
35
|
|
Управление бухгалтерским
учетом, финансовой деятельности предприятия
|
166
|
112
|
67
|
57
|
|
Управление организацией
труда, зарплата, кадры, нормы и нормативы, охрана труда
|
151
|
101
|
67
|
44
|
|
Управление качеством
продукции, технологическими процессами производства, стандартизации,
технической подготовкой производства
|
157
|
99
|
67
|
44
|
|
Управление транспортными
перевозками, техобслуживанием. Вспомогательными службами и электроснабжение
|
170
|
100
|
70
|
45
|
|
Управление научно -
технической информацией. Совершенствование документооборота и контроль
исполнения документа. Управление охраной природы и окружающей среды
|
151
|
101
|
67
|
46
|
|
Учет пенсий, пособий и
страховых операций
|
103
|
70
|
45
|
36
|
|
Статистические задачи
|
103
|
70
|
45
|
49
|
|
Задачи расчетного характера
|
103
|
70
|
45
|
41
|
Таблица 4.8 - Поправочные коэффициенты (К1, К2,
К3) для определения трудоемкости работ на стадии технического
проекта
|
Вид используемой информации
|
Степень новизны
|
|
А
|
Б
|
В
|
Г
|
|
ПИ, К1
|
1,7
|
1,2
|
1
|
0,5
|
|
НСИ, К2
|
1,45
|
1,08
|
0,72
|
0,43
|
|
БД, К3
|
4,37
|
3,12
|
2,08
|
1,25
|
Таблица 4.9 - Поправочные коэффициентами (К1, К2,
К3) определения трудоемкости работ на стадии рабочего проекта
|
Вид используемой информации
|
Группа сложности алгоритма
|
Степень новизны
|
|
|
А
|
Б
|
В
|
Г
|
|
ПИ, К1
|
С1
|
2,27
|
1,62
|
1,2
|
0,65
|
|
С2
|
2,02
|
1,44
|
1,1
|
0,58
|
|
С3
|
1,68
|
1,2
|
1
|
0,48
|
|
НСИ, К2
|
С1
|
1,36
|
0,97
|
0,65
|
0,4
|
|
С2
|
1,21
|
0,86
|
0,58
|
0,34
|
|
С3
|
1,01
|
0,72
|
0,48
|
0,29
|
|
БД, К3
|
С1
|
1,14
|
0,81
|
0,54
|
0,32
|
|
С2
|
1,05
|
0,72
|
0,48
|
0,29
|
Таблица 4.10 -Поправочные коэффициенты, учитывающие сложность контроля
входной и выходной информации на стадиях рабочего проекта и внедрения
|
Сложность контроля входной
информации
|
Сложность контроля выходной
информации
|
|
21
|
22
|
|
11
|
1,16
|
1,07
|
|
12
|
1,08
|
1
|
Таблица 4.11 -Поправочные коэффициенты для определения трудоемкости работ
на стадии технического и рабочего проектов, внедрения
|
Стадия разработки
|
Вид обрабатываемой
информации
|
Степень новизны
|
|
|
А
|
Б
|
В
|
Г
|
|
ТП
|
РВ
|
1,67
|
1,45
|
1,26
|
1,1
|
|
ТОУ
|
1,75
|
1,52
|
1,15
|
|
РП
|
РВ
|
1,75
|
1,52
|
1,36
|
1,15
|
|
ТОУ
|
1,92
|
1,67
|
1,44
|
1,25
|
|
В
|
РВ
|
1,6
|
1,39
|
1,21
|
1,05
|
|
ТОУ
|
1,67
|
1,45
|
1,26
|
1,1
|
Общая трудоемкость разработки программного продукта рассчитывается по
формуле
(4.1)
где 
- затраты труда на стадии технического задания (в днях);
- затраты труда на стадии эскизного проекта (в днях);
- затраты труда на стадии технического проекта(в днях);
- затраты труда на стадии рабочего проекта (в днях);
- затраты труда на стадии внедрения (в днях).
Трудоемкости разработки на этапах: техническое задание - определяется из
таблицы 4.6, эскизный проект - определяется из таблицы 4.7, остальные
трудоемкости определяются методом хронометража. Подставив в формулу 4.1
числовые значения трудоёмкости разработки программного продукта на каждом этапе
без учета поправочных коэффициентов, получим 
Общая трудоемкость разработки программного продукта с учетом поправочных
коэффициентов рассчитывается по формуле
(4.2)
где 
- затраты труда на стадии технического проекта с учетом
поправки;
- затраты труда на стадии рабочего проекта с учетом поправки;
- затраты труда на стадии внедрения с учетом поправки.
При использовании информации разных видов для технического и рабочего
проекта поправочный коэффициент рассчитывается по формуле
где m - количество наборов данных ПИ;
n - количество наборов данных НСИ;
p - количество наборов данных БД.
Для расчета затрат труда на стадии технического проекта с учетом поправки
по формуле 4.1 и на основе справочной таблицы 4.8, рассчитаем поправочный
коэффициент на использование разных видов информации 
Теперь с учетом поправки на
использование различных видов информации и на основе справочной таблицы 4.11,
вычислим затраты труда на стадии технического проекта с учетом поправки 
Для расчета затрат труда на стадии рабочего проекта с учетом поправки по
формуле 4.1, и на основе справочной таблицы 4.9 рассчитаем поправочный
коэффициент на использование разных видов информации 
С учетом поправки на использование разных видов информации и на основе
справочных таблиц 4.10 и 4.11 вычислим затраты труда на стадии рабочего проекта
с учетом поправки 
дня.
Для расчета затрат труда на стадии внедрения используются поправочные
коэффициенты из справочных таблиц 4.10 и 4.11
дней.
Таким образом, общие затраты труда на разработку программного продукта с
учетом поправочных коэффициентов составят
дней.
.2 Расчет
себестоимости программного продукта
Затраты на вспомогательные материалы приведены в таблице 4.12
Таблица 4.12 -Затраты на вспомогательные материалы
|
Наименование затрат
|
Количество, шт.
|
Сумма, руб.
|
|
Бумага для принтера
|
1
|
250
|
|
Картридж для принтера
|
1
|
700
|
|
CD-RW
|
1
|
40
|
|
Доступ в Интернет
|
-
|
450
|
|
Всего
|
|
1440
|
Затраты на электроэнергию рассчитываются по формуле
, (4.5)
где Р - мощность потребляемой электроэнергии, кВт;
СЭ - стоимость одного киловатт-часа электроэнергии, руб;
- общие затраты труда на разработку программного продукта,
час;
- коэффициент загрузки компьютера.
руб.
Основная заработная плата разработчика рассчитывается по формуле
, (4.6)
где Счтс - часовая тарифная ставка разработчика, руб;
- общие затраты труда на разработку программного продукта,
час.
руб.
Дополнительная заработная плата разработчика составляет 10% от основной
зарплаты, то есть 
Отчисления на социальные нужды определяются по формуле
, (4.7)
где Rсн - взнос на страхование и социальное
обеспечение, Rсн= 0,26.
Подставив в формулу (4.7), получим
руб.
Накладные расходы рассчитываются по формуле
. (4.8)
Подставив значения, получим 
руб.
Зная все числовые значения можно рассчитать полную себестоимость
разработанного программного продукта
руб.
В таблице 4.13 сведены результаты расчетов себестоимости программного
продукта [29].
Таблица 4.13 -Себестоимость программного продукта
|
Наименование статей
расходов
|
Затраты, руб.
|
|
Вспомогательные материалы
|
1440
|
|
Основная зарплата
|
8185,5
|
|
Дополнительная зарплата
|
818,6
|
|
Отчисления на социальные
нужды
|
2341,1
|
|
Затраты на электроэнергию
|
428,9
|
|
Накладные расходы
|
900,4
|
|
Полная себестоимость
|
14114,5
|
.3 Расчет
экономического эффекта от внедрения программного продукта
Экономический эффект от внедрения программного продукта рассчитывается по
формуле
(4.9)
где N - количество обрабатываемых
документов;
t1 ,t2 -
трудоемкость обработки документов до и после внедрения программы;
Счтс - часовая тарифная ставка пользователя;
Кдоп - коэффициент отчислений на дополнительную зарплату;
Ксн - взнос на страхование и социальное обеспечение;
Ен - нормативный коэффициент окупаемости капитальных вложений;
К
- дополнительные капитальные вложения, связанные с разработкой программного
продукта [30].
Используя ранее рассчитанные значения, рассчитываем экономический эффект 
руб.
Срок окупаемости программного продукта рассчитывается по формуле
, (4.10)
где Спр - себестоимость программного продукта, руб.;
С1 - стоимостные затраты при использовании ручного труда, руб.;
С2 - стоимостные затраты при использовании программы, руб.
руб.,
руб.,
года 
мес.
Полученные экономические показатели представлены в таблице 4.14.
Таблица 4.14 - Экономические показатели
|
Наименование показателя
|
Значение
|
Ед. изм.
|
|
Вспомогательные материалы
|
1440
|
руб.
|
|
Основная зарплата
|
8185,5
|
руб.
|
|
Дополнительная зарплата
|
818,6
|
руб.
|
|
Отчисления на социальные
нужды
|
2341,1
|
руб.
|
|
Затраты на электроэнергию
|
428,9
|
руб.
|
|
Накладные расходы
|
900,4
|
руб.
|
|
Экономический эффект
|
11655,3
|
руб.
|
|
Срок окупаемости
|
10
|
мес.
|
В четвертом разделе проведена следующая работа: осуществлены расчеты
трудоемкости разработки, себестоимости, экономического эффекта от внедрения
программного продукта, а также срок его окупаемости.
5.
Безопасность труда
.1 Анализ
условий труда
Площадь помещения, где работает сотрудник ОИТ, составляет 3
2,7 = 8,1 кв. метров.
Данные параметры не противоречат СанПиН, в которых площадь одного рабочего
места составляет 6 м2 при объеме помещения не менее 24,0 м3.
В помещении имеется световой проем площадью шириной 2 м. и высотой 2 м.
Высота рабочей поверхности стола составляет 800 мм, ширина
1200, глубина - 785 мм. Рабочее кресло оснащено подъемно-поворотным и
регулирующимся по высоте и углам наклона сиденья и спинки, а так же расстоянию
спинки от переднего края сиденья. Клавиатура располагается на поверхности стола
на расстоянии 150 мм от края и связана с центральным блоком ЭВМ с помощью
шнура, что позволяет менять место ее расположения и принимать наиболее удобную
рабочую позу.
Рабочие место с ПЭВМ по отношению к световому проему
располагается так, что естественный свет падает на спину, сидящего на рабочем
месте оператора ЭВМ.
Экран дисплея расположен на расстоянии от 50 до 100 см от
глаз оператора. Плоскость экрана перпендикулярна нормальной линии взора.
Предусмотрена возможность перемещения дисплейного устройства по высоте, а также
вокруг вертикальной оси в диапазоне от минус 20 до плюс 20 градусов (вправо -
влево) и наклона в вертикальной плоскости в пределах 30 градусов (вперед
-назад). Размер экрана по диагонали составляет 31 см, высота символов на экране
варьируется по желанию. Яркость свечения экрана не менее 100 кд/м (светлый
фон). Яркость символов на экране составляет от 22 до 31 кд/м. Контрастность изображения
знака - не менее 0,8. Частота регенерации изображения при работе с позитивным
контрастом в режиме обработки текста - не менее 100 Гц. Количество точек на
строке - 1024. Экран имеет антибликовое покрытие [31].
После анализа организации планировки рабочего места
администратора ЭВМ можно дать рекомендацию по изменению положения рабочего
места относительно светового проема - рабочий стол необходимо повернуть на 900
относительно текущего положения, таким образом, чтобы естественный свет падал
преимущественно слева от сидящего оператора.
Для достижения оптимальных условий микроклимата помещения,
где работает оператор должны соблюдаться следующие требования:
- оптимальная температура воздуха - 22°С (допустимая - 20-24°С);
- оптимальная относительная влажность -
40-60% (допустимая - не более 75%), скорость движения воздуха не более 0,1 м/с.
Для создания и автоматического поддержания в помещении
независимо от наружных условий оптимальных значений температуры, влажности,
чистоты и скорости движения воздуха, в холодное время года используется водяное
отопление, в теплое время года используются кондиционеры и помещение
проветривается.
Из полученных данных следует, что микроклимат в помещении с
ПЭВМ удовлетворяет требованиям СанПиН п.5 "Требования к микроклимату, содержанию
аэроионов и вредных химических веществ в воздухе помещений эксплуатации ВДТ и
ПЭВМ".
.2 Расчет
искусственного освещения
Искусственное освещение помещения осуществляется лампами
дневного света. Оно может быть общим, местным или комбинированным. Общее
предназначено для освещения всего производственного помещения. Местное при
необходимости дополняет общее и концентрирует дополнительный световой поток на
рабочих местах. Сочетание местного и общего освещения называют комбинированным.
Если в светлое время суток уровень естественного освещения не
соответствует нормам, то его дополняют искусственным.
При выборе источников света для производственных помещений
необходимо руководствоваться общими рекомендациями: отдавать предпочтение
газоразрядным лампам как энергетически более экономичным и обладающим большим
сроком службы; для уменьшения первоначальных затрат на осветительные установки
и расходов на их эксплуатацию необходимо по возможности использовать лампы
наименьшей мощности, но без ухудшения при этом качества освещения.
Создание в производственных помещениях качественного и
эффективного освещения невозможно без рациональных светильников. Электрический
светильник это совокупность источника света и осветительной арматуры
предназначенной для перераспределения излучаемого источником светового потока в
требуемом направлении, предохранения глаз рабочего от слепящего действия ярких
элементов источника света, защиты источника от механических повреждений,
воздействия окружающей среды и эстетического оформления помещения.
При распределении светового потока в пространстве различают
светильники прямого, преимущественно прямого, рассеянного, отраженного и
преимущественно отраженного света. В зависимости от конструктивного исполнения
различают открытые, защищенные, закрытые и другие [32].
Норма искусственного освещения общего = 300 лк (определяется
при характере выполняемой работы: характеристика зрительной работы - высокой
точности, разряд зрительной работы - III, контраст объекта с фоном - средний,
характеристика фона - светлый, под-разряд зрительной работы - В).
Для расчета общего равномерного освещения при горизонтальной
рабочей поверхности основным является метод светового потока (коэффициент
использования), учитывающий световой поток, отраженный от потолка и стен. Количество
ламп, которые будут обеспечивать равномерное освещение можно рассчитать по
формуле
|
|
(5.1)
|
где Ен - нормированная минимальная
освещенность, лк (в рассматриваемом случае это 300 лк)
n - число ламп в светильнике (3);
S - площадь освещаемого помещения, м2 (S=32,7 = 8,1м2);
Z - коэффициент минимальной освещенности, равный
отношению Еср/Еmin, значение которого для люминесцентных ламп -
1,15;
К - коэффициент запаса, учитывающий снижение
освещенности из-за загрязнения и старения лампы. При освещении люминесцентными
лампами и при запыленности помещения менее 5 мг/м3 (1,4);
Kз - коэффициент затемнения (0,9);
Ku - коэффициент использования светового потока.
Значения коэффициентов берутся из справочных таблиц. Для
определения значения коэффициента Ku находится индекс помещения I и предположительно
оцениваются коэффициенты отражения поверхностей помещения: потолка - Pп, стен - Pс, расчетной поверхности
или пола - Pр. Pп=50%, Рс=30%, Рр=10%.
Индекс помещения находится по формуле
|
|
(5.2)
|
где A и B - длина и ширина помещения, м (А=3м, В=2,7 м)
Нр - высота светильников над рабочей поверхностью,
м (Нр=2,20)
.
Используя справочную таблицу и рассчитанное по формуле (5.2)
значение индекса помещения I, получим коэффициент использования Ku=0,85.
Для освещения выберем лампы люминесцентные мощностью 20 Вт,
световой поток которых Fл = 1180 лм.
Рассчитаем необходимое количество светильников, подставив все
данные в формулу (5.1) 
шт.
Таким образом, для освещения помещения требуется 2
светильника по 3 люминесцентных лампы мощностью по 20 Вт.
.3 Возможные
чрезвычайные ситуации
.3.1 Расчет
зоны заражения
Чрезвычайная ситуация (ЧС) - это обстановка на определенной
территории, произошедшая в результате аварии, опасного природного явления,
катастрофы, стихийного или иного действия, которые повлекли: человеческие
жертвы, ущерб здоровью, окружающей среде, нарушению условий жизнедеятельности,
материальные потери.
Наибольшую опасность представляет выброс в атмосферу
аварийных химических отравляющих веществ (АХОВ).
Выброс АХОВ возможен при аварии автомобиля перевозящего
жидкий хлор.
Хлор - зеленовато-желтый газ с резким запахом. Порог
восприятия - 0,003 мг/л. ПДК в рабочей зоне - 0,001 мг/л. Следовательно, если
ели чувствуется резкий запах - это значит, что уже работать без средств защиты
опасно. Хлор в 2,5 раза тяжелее воздуха, поэтому облако хлора будет
перемещаться по направлению ветра близко к земле. Температура кипения -34,6
градусов Цельсия, следовательно, даже зимой хлор находится в газообразном
состоянии. При испарении на воздухе жидкий хлор образует с водяными парами
белый туман.
В малых и средних концентрациях хлор вызывает жжение и резь в
глазах, чувство стеснения и боль за грудиной, дискомфорт в горле, слезотечение,
сухой мучительный кашель. В больших концентрациях хлор довольно быстро вызывает
отек легких. У человека, попавшего в атмосферу с очень высокими концентрациями
паров хлора, быстро наступает потеря сознания и смерть от остановки дыхания,
что является следствием ожога легких парами хлора.
Первая медицинская помощь - надевание противогаза и быстрая
эвакуация из зоны поражения. Кожу и слизистые промыть 2%-м содовым раствором не
менее 15 мин. Чтобы смягчить раздражение дыхательных путей, следует вдыхать
аэрозоль 0,5%-го раствора питьевой соды. Транспортировать в стационар только в
лежачем положении [33].
Предположим, что где-то на железнодорожном пути, на
расстоянии в 7 км от рассматриваемого объекта (филиала вуза) в результате
железнодорожной аварии произошел выброс в атмосферу 5 тонн жидкого хлора.
Скорость ветра 3 м/с. Проведем расчет размеров и площади зоны заражения, а так
же время подхода зараженного облака к объекту для трех состояний атмосферы.
Определим глубину зоны заражения из таблицы "Глубина
распространения облаков зараженного воздуха с поражающими концентрациями АХОВ
на открытой местности".
При инверсии она составляет 23 км. Так как скорость ветра
больше 0,1 м/с, определяем поправочный коэффициент по таблице влияния скорости
ветра на глубину распространения зараженного воздуха с поражающей
концентрацией. При скорости ветра 3 м/с этот коэффициент будет равен 0,45.
Отсюда глубина распространения зараженного облака равна 
км.
При изометрии глубина зоны заражения составляет 4,6 км.
Поправочный коэффициент по таблице влияния скорости ветра на глубину распространения
зараженного воздуха с поражающей концентрацией будет равен 0,55. Следовательно,
глубина распространения зараженного облака равна 
км.
При конвекции глубина зоны заражения составляет 1 км.
Поправочный коэффициент по таблице влияния скорости ветра на глубину
распространения зараженного воздуха с поражающей концентрацией будет равен
0,62. Следовательно, глубина распространения зараженного облака равна 
км.
Определим ширину зоны химического заражения. Ширина (Ш) зоны
химического заражения зависит от степени вертикальной устойчивости воздуха и
определяется для инверсии как
где Г - глубина распространения облака зараженного воздуха с
поражающей концентрацией в км.
При инверсии ширина зоны химического заражения будет равна 
км. При изотермии
ширина зоны химического заражения будет равна 
км. При конвекции
ширина зоны химического заражения будет равна 
км.
Площадь зоны заражения определяется по формуле
|
 .
|
(5.4)
|
При инверсии площадь зоны заражения будет равна: 
км2. При
изометрии площадь зоны заражения будет равна 
км2.При
конвекции площадь зоны заражения будет равна 
км2.
Расстояние от места разлива АХОВ (R) до объекта составляет
7км. По таблице для инверсии и скорости ветра 3 м/с определим среднюю скорость
переноса облака зараженного веществом W, в данном случае она составляет 16 м/с.
Время подхода облака t к заданному объекту
зависит от скорости переноса облака воздушными потоками и определяется по
формуле
|
|
5.5)
|
|
|
часа.
|
Расстояние от места разлива АХОВ (R) до объекта составляет 7
км. По таблице для изометрии и скорости ветра 3 м/с определим среднюю скорость
переноса облака зараженного веществом W, в данном случае она составляет 18 м/с. Время
подхода облака t к заданному объекту зависит от скорости переноса облака
воздушными потоками и определяется по формуле (5.5)
|
|
часа.
|
|
Расстояние от места разлива АХОВ (R) до объекта составляет 7
км. По таблице для конвекции и скорости ветра 3 м/с определим среднюю скорость
переноса облака зараженного веществом W, в данном случае она составляет 21 м/с. Время
подхода облака t к заданному объекту зависит от скорости переноса облака
воздушными потоками и определяется по формуле (5.5) 
часа. Таким образом, в
наихудшем случае при конвекции атмосферы подход зараженного облака к объекту
составит 0,3 часа или 18 минут.
Времени поражающего действия АХОВ в очагах химического
поражения определяется временем испарения АХОВ с поверхности его выброса.
По таблице времени испарения некоторых АХОВ определяем время
поражающего действия хлора при скорости ветра 1м/с. Время испарения хлора равно
1,3 ч.
Время испарения используется для определения ориентировочного
времени поражающего действия АХОВ в очаге химического поражения. Т.к. скорость
ветра больше 1 м/с, введем поправочный коэффициент. Для скорости 3 м/с он будет
равен 0,55. Время поражающего действия хлора, составит 
часа=20 мин.
.3.2 Расчет
времени эвакуации
Проведем расчет времени эвакуации для лаборатории
компьютерной графики филиала. Обычно в лаборатории находится до 25 человек.
Лаборатория находится на первом этаже и длина L пути
эвакуации от лаборатории до выхода составляет 22 м.
Эвакуация при возникновении чрезвычайной ситуации
производится в соответствии с планом эвакуации.
Процесс эвакуации из зданий и сооружений характеризуется
следующими параметрами: плотность D, скорость движения людского потока v,
пропускная способность пути (выходов) Q и интенсивность движения q.
Эвакуационные пути, как горизонтальные, так и наклонные, характеризуются длиной
L и шириной b движения [34,35]. Расчетное время эвакуации людей Т
определяется по формуле
,
где 
- время движения людского потока на каждом этапе
эвакуации.
Время движения людского потока на участке пути
|
|
,
|
где 
- скорость движения людского потока на одном из
участков, определяется по таблице определения скорости движения людского потока
в зависимости от плотности D.
Плотность людского потока D, состоящего из N
людей, равна
|
|
,
|
где N - среднее число людей на участке эвакуации;
А - площадь эвакуационного пути.
N = 25.
Вычислим площадь пути эвакуационного участка по формуле
.
Ширина коридора 
м.
Тогда, плотность людского потока на участках
Скорость движения людского потока зависит от его плотности
и вида пути (горизонтальные или наклонные). С увеличением плотности потока
скорость движения уменьшается. Для горизонтального пути и значения D = 0,45 значение составит 35 м./мин.
Таким образом, время движения людей, находящихся в
лаборатории компьютерной графики, к выходу составит 
Пропускной способностью пути называют количество людей, проходящих
в единицу времени через поперечное сечение пути шириной b. Эту величину
можно вычислить по формуле
.
Тогда пропускная способность на каждом участке будет равна
соответственно 
.
Интенсивностью движения людского потока называется величина,
равная произведению плотности и скорости движения. Интенсивность движения не
зависит от ширины пути и является характеристикой потока. Интенсивность потока
рассчитывается по формуле
|
|
,
|
Тогда интенсивность движения на каждом участке будет равна
соответственно 
чел/мин.
Так как облако хлора подойдет к объекту через 18 мин. после
аварии, а расчетное время эвакуации 38 сек., то в случае своевременного
оповещения люди успеют эвакуироваться в безопасное место.
В пятом разделе были проанализированы условия труда,
осуществлен расчет искусственного освещения в помещении отдела ИТ, рассчитана
зона поражения при аварии цистерны с ядовитым веществом, а также время
эвакуации персонала из зоны поражения.
Заключение
Результатом данной дипломной работы является программное средство
автоматизации заявок пользователей локальной вычислительной сети филиала РГУ
нефти и газа имени И.М. Губкина в г. Оренбурге.
Данный средство предназначено для автоматизации процессов обслуживания
заявок пользователей и ведение реестра отчетности сотрудников ОИТ
Разработанное средство позволяет:
хранить данные централизованно;
осуществлять контроль за исполнением заявок;
оперативно генерировать отчеты;
снизить временные затраты на принятие, обработку и исполнение заявок.
В ходе выполнения данной дипломной работы были выполнены следующие задачи
и подзадачи:
разработка базы данных учета и хранения заявок пользователя;
разработка программного средства на основе клиент/серверной технологии;
разработка интерфейса программного средства;
выбор СУБД;
выбор языка программирования;
углубленное ознакомление с платформой Tandem Framework;
математическое описание решения задачи предметной области;
первичное апробирование и дальнейшая отладка программного средства
автоматизации обслуживания заявок предметной области.
В первом разделе дипломной работы сделано следующее:
- проведен анализ предметной области Филиала;
исследованы информационные потоки рассматриваемой предметной области;
проанализированы существующие аналоги разрабатываемому программному
средству;
сформулирована постановка задачи на разработку программного средства для
автоматизации процессов подачи, принятия и обработки заявок на обслуживание
компьютерной оргтехники, осуществлена декомпозиция задач; база данные учет заявка программный платформа
- сформулированы требования к аппаратному и программному обеспечению
разрабатываемого средства.
Во втором разделе дипломной работы сделано следующее:
представлено обоснование выбора и описание инструментальных средств:
языка программирования, СУБД, языка запросов;
представлено описание технологии клиент/сервер и принципов работы Java web-приложения;
проанализирована архитектура платформы АСУОД Tandem, функционирующая в Филиале;
разработана БД проектируемого средства;
разработано программное средство автоматизации обслуживания заявок
пользователей ЛВС Филиала.
В третьем разделе дипломной работы сделано следующее:
разработано руководство для пользователя проектируемого программного
средства. В нем описан пользовательский интерфейс, его функции и приемы работы;
разработано руководство для серверной части проектируемого модуля. В нем
описан метод настройки сервера Tomcat;
разработано руководство администратора. В нем показаны процесс установки
сервера Tomcat и тестирование его работы;
разработано руководство программиста, в котором описаны фрагменты,
ссылающиеся на другие компоненты спроектированного программного средства, и тем
самым осуществляющие логическую связь. Так же показана подготовка ЛВС к работе
средства.
В четвертом разделе дипломной работы сделано следующее: осуществлены
расчеты трудоемкости разработки, себестоимости, экономического эффекта от
внедрения программного продукта, а также срок его окупаемости.
В пятом разделе дипломной работы были проанализированы
условия труда, осуществлен расчет искусственного освещения в помещении отдела
информационных технологий, рассчитана зона поражения при аварии цистерны с
ядовитым веществом, а также время эвакуации персонала из зоны поражения.
Внедрение разработанного программного средства позволяет в
значительной мере сократить время подачи, обработки и выполнения заявок за счет
внедрения процессов автоматизации на смену ручному труду. Срок окупаемости
составляет приблизительно 10 месяцев.
Список
использованных источников
1 Официальный
сайт Филиал Российского государственного университета нефти и газа имени И.М.
Губкина в Оренбурге. Режим доступа: #"600513.files/image143.gif">
Приложение
Б
Листинг программных модулей
//Модуль идентификации и аутентификации login.java
package
avk;java.io.IOException;java.sql.SQLException;java.util.ArrayList;javax.servlet.ServletException;javax.servlet.http.*;class
login extends HttpServlet {void doPost(HttpServletRequest req,
HttpServletResponse resp)ServletException, IOException {<String> ar =
null;login = req.getParameter("login");pas =
req.getParameter("pas");(validLoginPas(login, pas))
{= getDate(login, pas);(ar != null)
{(ar,
req.getSession(true));.sendRedirect("menu.html");
}resp.sendRedirect("info.html");
}resp.sendRedirect("info1.html");
}void doGet(HttpServletRequest req, HttpServletResponse
resp)ServletException, IOException {(req,resp);
}boolean validLoginPas(String login, String pas)
{(login == null || pas == null )return false;(login.length()
== 0 || pas.length() == 0 )return false;true;
}void autorization(ArrayList<String> ar, HttpSession
ses)
{.setAttribute("id", ar.get(0));.setAttribute("typeUser",
ar.get(7));.setAttribute("shortName", ar.get(6));
}ArrayList<String> getDate(String login, String pas)
{<String> ar = null;
{dao = new DAOusers();= dao.getUserDate(login, pas);
}(SQLException e)
{
}(ClassNotFoundException e)
{
}ar;
}
}
//Модуль регистрации
reg.javaavk;java.io.IOException;java.sql.SQLException;javax.servlet.ServletException;javax.servlet.http.*;class
reg extends HttpServlet {void doPost(HttpServletRequest req,
HttpServletResponse resp)ServletException, IOException {login, pas, Surname,
Name, FName;.setCharacterEncoding("utf8");=
req.getParameter("login");= req.getParameter("pas");=
req.getParameter("Surname");= req.getParameter("Name");=
req.getParameter("FName");(validUserData(login, pas, Surname, Name,
FName))
{
{dao = new DAOusers();(dao.InsUserDate(login, pas, Surname,
Name,
FName))resp.sendRedirect("sacsFulReg.html");resp.sendRedirect("error.html?Insert_failed");
}(SQLException e)
{.sendRedirect("error.html?User_was_not_added");
}(ClassNotFoundException e)
{
}
}resp.sendRedirect("erReg.html");
}void doGet(HttpServletRequest req, HttpServletResponse
resp)ServletException, IOException {(req,resp);
}boolean validUserData(String login, String pas, String
Surname, String Name, String FName)
{(login == null || pas == null || Surname == null || Name ==
null || FName == null )return false;(login.length() == 0 || pas.length() == 0
|| Surname.length() == 0 || Name.length() == 0 || FName.length() == 0 )return
false;true;
}
}
//Модуль доступа
к БД DAODemands.javaavk;java.sql.*;java.util.*;java.util.Date;class
DAOdemands {Connection connect = null;PreparedStatement pst = null;
//private Statement st = null;
//private String sql;ResultSet result =
null;ResultSetMetaData resMet;DAOdemands() throws ClassNotFoundException,
SQLException
{.connect = getConnection();
}Connection getConnection() throws ClassNotFoundException,
SQLException {
{.forName("org.postgresql.Driver");
}(ClassNotFoundException e)
{
//return null;e;
}url, user, password;=
"jdbc:postgresql://127.0.0.1/zit";= "postgres";=
"xmmGQAKq";
{DriverManager.getConnection(url, user, password);
}(SQLException e)
{e;
}
}boolean addDemand(String forName, String name, String
tarqetDate, int tarqetTimeH, int tarqetTimeM, int tarqetAud, String
targetMulti) throws SQLException {sql = "INSERT INTO
\"demands\"(\"forName\", \"name\",
\"dateTime\", \"tarqetAud\", \"targetMulti\",
"+
"\"requestAccepted\",
\"requestDoned\", \"dateTimeRegistration\")VALUES(?, ?, ?,
?, ?, ?, ?, ?);";
{= connect.prepareStatement(sql);.setString(1, forName);.setString(2,
name);.setTimestamp(3,
getTimestamp(tarqetDate,((Integer)tarqetTimeH).toString(),((Integer)tarqetTimeM).toString()));.setInt(4,
tarqetAud);.setString(5, targetMulti);.setBoolean(6, false);.setBoolean(7,
false);timestamp = new Timestamp((new Date()).getTime());.setTimestamp(8,
timestamp);.executeUpdate();
{e;
}
/*finally
{{.close();.close();
}(SQLException e)
{e;
}
}*/true;
}ArrayList<ArrayList<String>>
commonRequest(String sqlSuffics) throws SQLException
{sql = "SELECT \"idRequest\",
\"forName\", \"name\", \"dateTime\","+
"\"tarqetAud\", \"targetMulti\",
\"requestAccepted\","+
"\"requestDoned\",
\"dateTimeRegistration\" FROM public.requests "+sqlSuffics
+" ORDER BY \"dateTime\";";=
connect.prepareStatement(sql);= pst.executeQuery();=
result.getMetaData();colCount = resMet.getColumnCount();cal = new
GregorianCalendar(Locale.getDefault());frm;<ArrayList<String>>
selectRequest = new ArrayList<ArrayList<String>>();(int i = 1; i
<= colCount; i++)(result.next())
{<String> arRow = new ArrayList<String>(colCount);(int
j = 1; j <= colCount; j++)
{.add(((Integer)result.getInt(1)).toString());.add(result.getString(2));.add(result.getString(3));.setTimeInMillis(result.getTimestamp(4).getTime());=
new Formatter();.format("%td.%tm.%tY %tk:%tM", cal,cal,cal,cal,cal);.add(frm.toString());.close();.add(((Integer)result.getInt(5)).toString());.add(result.getString(6));.add(result.getBoolean(7)
? "ДА" : "НЕТ");.add(result.getBoolean(8) ?
"ДА" : "НЕТ");.setTimeInMillis(result.getTimestamp(9).getTime());=
new Formatter();.format("%td.%tm.%tY %tk:%tM:%tS",
cal,cal,cal,cal,cal,cal);.add(frm.toString());.close();
}.add(arRow);
}.close();.close();selectRequest;
}String getTime(int shiftYear, int shiftMonth, int shiftDay)
{cal = new GregorianCalendar();.set(GregorianCalendar.HOUR_OF_DAY,
0);.set(GregorianCalendar.DAY_OF_MONTH, cal.get(GregorianCalendar.DAY_OF_MONTH)+shiftDay);.set(GregorianCalendar.MONTH,
cal.get(GregorianCalendar.MONTH)+shiftMonth);.set(GregorianCalendar.YEAR,
cal.get(GregorianCalendar.YEAR)+shiftYear);frm = new
Formatter();.format("%td.%tm.%tY", cal,cal,cal);frm.toString();
}String getSqlSuffics(String date, String date1)
{
"WHERE requests.\"dateTime\" >=
\'"+date+"\' AND requests.\"dateTime\" <=
\'"+date1+"\'";
}ArrayList<ArrayList<String>> callSel(int
shiftYear, int shiftMonth, int shiftDay,int shiftYear1, int shiftMonth1,
int shiftDay1) throws SQLException
{
{commonRequest(getSqlSuffics(getTime(shiftYear, shiftMonth,
shiftDay), getTime(shiftYear1, shiftMonth1, shiftDay1)));
}(SQLException e)
{e;
}
}Timestamp getTimestamp(String date, String h, String m)
{year, month, dayOfMonth, hours = Integer.valueOf(h),
minutes = Integer.valueOf(m);strTok = new StringTokenizer(date,
".");= Integer.valueOf(strTok.nextToken());= Integer.valueOf(strTok.nextToken());=
Integer.valueOf(strTok.nextToken());cal = new GregorianCalendar(year,
month-1, dayOfMonth, hours, minutes);timeStamp = new
Timestamp(cal.getTime().getTime());
return timeStamp;
}
}
// Модуль добавления заявки на компьютерную оргтехнику addDemand.java
package
avk;java.io.IOException;java.sql.SQLException;javax.servlet.*;javax.servlet.http.*;class
AddDemand extends HttpServlet {void doPost(HttpServletRequest req,
HttpServletResponse resp)ServletException, IOException {name, forName,
tarqetDate, tarqetTimeH, tarqetTimeM, tarqetAud,
targetMulti;.setCharacterEncoding("utf8");=
req.getParameter("name");= req.getParameter("forName");=
req.getParameter("tarqetDate");=
req.getParameter("tarqetTimeH");=
req.getParameter("tarqetTimeM");= req.getParameter("tarqetAud");=
req.getParameter("targetMulti");
{dao = new DAOdemands();(dao.addDemand(forName, forName,
tarqetDate, Integer.parseInt(tarqetTimeH), Integer.parseInt(tarqetTimeM),
Integer.parseInt(tarqetAud), targetMulti)).sendRedirect("sacsFulAdReq.html");
}(SQLException e)
{.sendRedirect("error.html?errorAddRequest");
}(ClassNotFoundException e)
{.sendRedirect("error.html?errorAddRequest");
}
}
}
//Модуль создания интерфейса формы создания заявки SubmitDemand.jsp
<?xml version="1.0" encoding="utf8"
?>
<%@page import="avk.DAOdemands"%>
<%@page import="avk.DAOusers"%>
<%@page import="avk.DAODeviceClasses"%>
<%@page import="avk.DAODeviceType"%>
<%@page import="avk.DAODevices"%>
<%@page import="avk.DAORooms"%>
<%@page import="java.util.ArrayList"%>
<%@page import="java.util.Formatter"%>
<%@page import="java.util.GregorianCalendar"%>
<%@ page language="java" contentType="text/html;
charset=utf8"="utf8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=utf8" />
<title>Заявки</title>
</head>
<body>
<div style="text-align: center; font-weight: bold;"><big><big><big><big>Оформление
заявки<br>
<br>
</big></big></big></big>
<form action="addDemand" method="post">
<div style="text-align: center;"></div>
<table style="text-align: left; height: 180px;
width: 922px;" align="center" border="1"
cellpadding="2" cellspacing="2">
<tbody>
<tr>
<td style="font-weight: bold; text-align: left;
width: 343px;"><big><big><big><small>Заявка
от:</small><br>
</big></big></big></td>
<td style="text-align: left; width: 470px;"><big><big>
<%= session.getAttribute("shortName") %>
</big></big></td>
</tr>
<tr>
<td style="text-align: left; font-weight: bold;
width: 343px;"><big><big>Заявка на:</big></big></td>
<td style="text-align: left; width: 470px;"><big><big>
<select name="class">
<%dao = new
DAODeviceClasses();<ArrayList<String>> selAllDevClass =
dao.selAllDevClass();(ArrayList<String> deviceData : selAllDevClass)
{
%><option value="<%=
deviceData.get(0)%>"><%= deviceData.get(1)
%></option>
<%;} %>
</select>
<br>
</big></big></td>
</tr>
<tr>
<td style="text-align: left; font-weight: bold;
width: 343px;"><big><big>Тип оборудования:</big></big></td>
<td style="text-align: left; width: 470px;"><big><big>
<select name="device">
<%daot = new
DAODeviceType();<ArrayList<String>> selAllDevType = daot.selAllDevType();(ArrayList<String>
deviceType : selAllDevType)
{
%><option value="<%=
deviceType.get(0)%>"><%= deviceType.get(1)
%></option>
<%;} %>
</select>
<br>
</big></big></td>
</tr>
<tr>
<td style="text-align: left; font-weight: bold;
width: 343px;"><big><big>Аудитория/кабинет, номер</big></big></td>
<td style="width: 470px;">
<select name="name">
<% DAORooms daor = new
DAORooms();<ArrayList<String>> selAllRooms =
daor.selAllRooms();id=null;(ArrayList<String> rooms : selAllRooms)
{
%><option value="<%=
id=rooms.get(0)%>"><%= rooms.get(1) %></option>
<%;} %>
</select>
<span style="font-weight: bold;">Этаж</span>
<select name="storey">
<%for(ArrayList<String> rooms : selAllRooms)
{
%>
<option value="<%=id %>"><%=
rooms.get(3) %></option><%;} %>
</select>
<span style="font-weight: bold;">№</span>
<select name="number">
<%for(ArrayList<String> rooms : selAllRooms)
{
%><option><%= rooms.get(2)
%></option><%;} %>
</select>
</td>
</tr>
<tr>
<td style="text-align: left; font-weight: bold;
width: 343px;"><big><big>Данные об оборудовании</big></big></td>
<td style="text-align: left; width: 470px;"><big><big>
<select name="device">
<%daod = new DAODevices();<ArrayList<String>>
selAllDev = daod.selAllDev();(ArrayList<String> device : selAllDev)
{
%><option value="<%= device.get(0)%>"><%=
device.get(1) %></option>
<%;} %>
</select>
<br>
</big></big></td>
</tr>
<tr>
<td style="text-align: left; font-weight: bold;
width: 343px;"><big><big>Что необходимо сделать:</big></big></td>
<td style="width: 470px;"><big><big><textarea
cols="30" rows="3" name="description"></textarea></big></big></td>
</tr>
<tr>
<td style="width: 343px;" colspan="1"
rowspan="1"><big><big><a href="menu.html"
name="index"><big><big>На
главную</big></big></a></big></big></td>
<td style="width: 470px;"><big><big><button
value="Отправить заявку" name="AddRequest"><big><big>Отправить
заявку</big></big></button></big></big></td>
</tr>
</tbody>
</table>
</form>
</div>
</body>
</html>
//Модуль доступа к таблице классов устройств БД DAODeviceClasses.java
package avk;java.sql.*;java.util.*;java.util.Date;class
DAODeviceClasses {Connection connect = null;PreparedStatement pst = null;
//private Statement st = null;
//private String sql;ResultSet result =
null;ResultSetMetaData resMet;DAODeviceClasses() throws ClassNotFoundException,
SQLException
{.connect = getConnection();
}Connection getConnection() throws ClassNotFoundException,
SQLException {
{.forName("org.postgresql.Driver");
}(ClassNotFoundException e)
{
//return null;e;
}url, user, password;=
"jdbc:postgresql://127.0.0.1/zit";= "postgres";=
"xmmGQAKq";
{DriverManager.getConnection(url, user, password);
}(SQLException e)
{e;
}
}ArrayList<ArrayList<String>> selAllDevClass()
throws SQLException
{sql = "SELECT \"idclass\",
\"class\" FROM
public.\"DeviceClasses\";";<ArrayList<String>>
selAllDevClass = null;
{= connect.prepareStatement(sql);= pst.executeQuery();=
result.getMetaData();colCount = resMet.getColumnCount();= new
ArrayList<ArrayList<String>>();(result.next())
{<String> arRow = new
ArrayList<String>(colCount);.add(result.getString(1));.add(result.getString(2));.add(arRow);
}.close();.close();
}(SQLException e)
{e;
}selAllDevClass;
}
}
//Модуль доступа
к таблице
типов устройств БД
DAODeviceTypes.javaavk;java.sql.*;java.util.*;java.util.Date;class
DAODeviceType {Connection connect = null;PreparedStatement pst = null;
//private Statement st = null;
//private String sql;ResultSet result =
null;ResultSetMetaData resMet;DAODeviceType() throws ClassNotFoundException,
SQLException
{.connect = getConnection();
}Connection getConnection() throws ClassNotFoundException,
SQLException {
{.forName("org.postgresql.Driver");
}(ClassNotFoundException e)
{
//return null;e;
}url, user, password;=
"jdbc:postgresql://127.0.0.1/zit";= "postgres";=
"xmmGQAKq";
{DriverManager.getConnection(url, user, password);
}(SQLException e)
{e;
}
}ArrayList<ArrayList<String>> selAllDevType()
throws SQLException
{sql = "SELECT \"idtype\",
\"device\", \"idclass\" FROM
public.\"DeviceTypes\";";<ArrayList<String>> selAllDevType
= null;
{= connect.prepareStatement(sql);= pst.executeQuery();=
result.getMetaData();colCount = resMet.getColumnCount();= new
ArrayList<ArrayList<String>>();(result.next())
{<String> arRow = new
ArrayList<String>(colCount);.add(result.getString(1));.add(result.getString(2));.add(result.getString(3));.add(arRow);
}.close();.close();
}(SQLException e)
{e;
}selAllDevType;
}
}
//Модуль доступа
к таблице
устройств БД DAODevices.javaavk;java.sql.*;java.util.*;java.util.Date;class
DAODevices {Connection connect = null;PreparedStatement pst = null;
//private Statement st = null;
//private String sql;ResultSet result =
null;ResultSetMetaData resMet;DAODevices() throws ClassNotFoundException,
SQLException
{.connect = getConnection();
}Connection getConnection() throws ClassNotFoundException,
SQLException {
{.forName("org.postgresql.Driver");
}(ClassNotFoundException e)
{
//return null;e;
}url, user, password;=
"jdbc:postgresql://127.0.0.1/zit";= "postgres";=
"xmmGQAKq";
{DriverManager.getConnection(url, user, password);
}(SQLException e)
{e;
}
}ArrayList<ArrayList<String>> selAllDev() throws
SQLException
{sql = "SELECT \"iddevice\",
\"nameDevice\" FROM
public.\"devices\";";<ArrayList<String>> selAllDev =
null;
{= connect.prepareStatement(sql);= pst.executeQuery();=
result.getMetaData();colCount = resMet.getColumnCount();= new
ArrayList<ArrayList<String>>();(result.next())
{<String> arRow = new
ArrayList<String>(colCount);.add(result.getString(1));.add(result.getString(2));.add(arRow);
}.close();.close();
}(SQLException e)
{e;
}selAllDev;
}
}
//Модуль доступа
к таблице
типов помещений БД
DAORoomTypes.javaavk;java.sql.Connection;java.sql.DriverManager;java.sql.PreparedStatement;java.sql.ResultSet;java.sql.ResultSetMetaData;java.sql.SQLException;java.util.ArrayList;class
DAORoomTypes {Connection connect = null;PreparedStatement pst = null;
//private Statement st = null;
//private String sql;ResultSet result =
null;ResultSetMetaData resMet;DAORoomTypes() throws ClassNotFoundException,
SQLException
{.connect = getConnection();
}Connection getConnection() throws ClassNotFoundException,
SQLException {
{.forName("org.postgresql.Driver");
}(ClassNotFoundException e)
{
//return null;e;
}url, user, password;= "jdbc:postgresql://127.0.0.1/zit";=
"postgres";= "xmmGQAKq";
{DriverManager.getConnection(url, user, password);
}(SQLException e)
{e;
}
}ArrayList<ArrayList<String>> selAllRoomTypes()
throws SQLException
{sql = "SELECT \"idtype\", \"type\"
FROM public.\"RoomTypes\";";<ArrayList<String>>
selAllRoomTypes = null;
{= connect.prepareStatement(sql);= pst.executeQuery();=
result.getMetaData();colCount = resMet.getColumnCount();= new
ArrayList<ArrayList<String>>();(result.next())
{<String> arRow = new ArrayList<String>(colCount);.add(result.getString(1));.add(result.getString(2));.add(arRow);
}.close();.close();
}(SQLException e)
{e;
}selAllRoomTypes;
}
}
//Модуль доступа
к таблице
пользователей БД DAOUsers.javaavk;java.sql.*;java.util.*;java.util.Date;class DAOusers
{Connection connect = null;PreparedStatement pst = null;
//private Statement st = null;
//private String sql;ResultSet result =
null;ResultSetMetaData resMet;DAOusers() throws ClassNotFoundException,
SQLException
{.connect = getConnection();
}Connection getConnection() throws ClassNotFoundException,
SQLException {
{.forName("org.postgresql.Driver");
}(ClassNotFoundException e)
{
//return null;e;
}url, user, password;=
"jdbc:postgresql://127.0.0.1/zit";= "postgres";=
"xmmGQAKq";
{DriverManager.getConnection(url, user, password);
}(SQLException e)
{e;
}
}ArrayList<String> getUserDate(String login, String
pas) throws SQLException
{sql = "SELECT \"id\",\"login\",
\"pas\",\"Surname\",\"Name\",\"FName\",\"shortName\",\"typeUser\"
FROM public.\"Users\" WHERE \"Users\".\"login\"
=? AND \"Users\".pas = ?;";ar = null;
{= connect.prepareStatement(sql);.setString(1,
login);.setString(2, pas);= pst.executeQuery();(result.next())
{= new
ArrayList(8);.add(result.getString(1));.add(result.getString(2));.add(result.getString(3));.add(result.getString(4));.add(result.getString(5));.add(result.getString(6));.add(result.getString(7));i;.add((i
= result.getInt(8)).toString());
}return null;(result.wasNull())return null;.close();.close();
}(SQLException e)
{null;
//throw e;
}ar;
}ArrayList<ArrayList<String>> selAllUserDate()
throws SQLException
{sql = "SELECT \"id\",
\"shortName\", \"typeUser\" FROM
public.\"Users\";";<ArrayList<String>> selAllUser =
null;
{= connect.prepareStatement(sql);= pst.executeQuery();=
result.getMetaData();colCount = resMet.getColumnCount();= new
ArrayList<ArrayList<String>>();(result.next())
{<String> arRow = new
ArrayList<String>(colCount);.add(result.getString(1));.add(result.getString(2));.add(result.getString(3));.add(arRow);
}.close();.close();
}(SQLException e)
{e;
}selAllUser;
}boolean admAccept(String flag, String id)
{sql = "UPDATE \"Users\" SET
\"typeUser\"=? WHERE id = ?;";
{= connect.prepareStatement(sql);.setInt(1, Integer.parseInt(flag));.setInt(2,
Integer.parseInt(id));.executeUpdate();.close();.close();
}(SQLException e)
{false;
}true;
}boolean InsUserDate(String login, String pas, String
Surname, String Name, String FName) throws SQLException
{typeUser = 0;shortName = Surname+"
"+Name.substring(0, 1) + "."+FName.substring(0, 1) +
".";sql = "INSERT INTO \"Users\"(\"login\",
\"pas\",\"Surname\", \"Name\",
\"FName\", \"shortName\", \"typeUser\")VALUES (?,
?, ?, ?, ?, ?, ?);";
{= connect.prepareStatement(sql);.setString(1,
login);.setString(2, pas);.setString(3, Surname);.setString(4, Name);.setString(5,
FName);.setString(6, shortName);.setInt(7,
typeUser);.executeUpdate();.close();.close();
}(SQLException e)
{
//return false;e;
}true;
}
}
// Модуль, открывающий доступ к странице редактирования прав
пользователей AdmAccept.java
package avk;java.io.IOException;java.sql.SQLException;javax.servlet.ServletException;javax.servlet.http.*;class
AdmAccept extends HttpServlet {void doGet(HttpServletRequest req,
HttpServletResponse resp)ServletException, IOException {flag, id;=
req.getParameter("id");= req.getParameter("flag");
{dao = new
DAOusers();(dao.admAccept(flag.equals("0") ? "1" :
"0",
id))resp.sendRedirect("admUser.jsp");resp.sendRedirect("error.html?errorAdd");
}(SQLException e)
{.sendRedirect("error.html?errorDB");
}(ClassNotFoundException e)
{.sendRedirect("error.html?errorCNotF");
}
}
}
//Модуль создания интерфейса страницы редактирования прав пользователей admUser.jsp
<?xml version="1.0" encoding="utf8"
?>
<%@page import="java.sql.SQLException"%>
<%@page import="java.util.ArrayList"%>
<%@page import="avk.DAOusers"%>
<%@ page language="java" contentType="text/html;
charset=utf8"="utf8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=utf8" />
<title>Заявки</title>
</head>
<body>
<div style="text-align: center;"><big><big><big><big><big><span="font-weight:
bold;">Управление пользователями(<%= session.getAttribute("shortName") %>)<br><br>
</span></big></big></big></big></big>
<table style="text-align: left; width: 340px;
height: 60px;"="center" border="1"
cellpadding="2"="2">
<tbody>
<tr>
<td style="width: 149px; text-align: right;"><span="font-weight:
bold;">Пользователь</span></td>
<td style="width: 171px; text-align: center;"><span="font-weight:
bold;">Администратор</span></td>
</tr>
<%<ArrayList<String>> arSel=null;ses =
request.getSession(false);atr;
if(ses==null) {%>
<big><big><big><big><big>ses==null</big></big></big></big>
<jsp:forward page="info2.html"/>
<%;} else
{
atr =
(String)ses.getAttribute("typeUser");(atr.equals("1"))
{
{dao = new DAOusers();= dao.selAllUserDate();
}(SQLException e)
{%>
<jsp:forward page="error.html"/>
<%;}str = null;(ArrayList<String> ar : arSel)
{ str = ar.get(2).equals("0") ? "НЕТ" : "ДА";%>
<tr>
<td style="width: 149px; text-align: right;"><%=
ar.get(1) %>
</td>
<td="width: 171px; text-align: center;
font-weight: bold;"><big><big><a="Users"
href="AdmAccept?id=<%= ar.get(0) %>&flag=<%=ar.get(2)%>">
<%= str%>
</a></big></big></td>
</tr>
<%;}(arSel.isEmpty())
{
%>
<td colspan="2" rowspan="1"><span="font-weight:
bold;">Пользователи отсутствуют</span></td>
</tr>
<%;}} if(atr.equals("0")){%>
<jsp:forward page="info2.html"/>
<% ;}}%>
</tbody>
</table>
<big><big><big><big>
<br>
<a href="menu.html" name="menu">Главная</a></span></big></big></big></big></div>
</div>
</body>
</html>
//Модуль доступа к таблице заявок на мультимедиа оборудование БД //DAORequest.java
package avk;java.sql.*;java.util.*;java.util.Date;class
DAORequest implements IDAORequest {Connection connect = null;PreparedStatement
pst = null;
//private Statement st = null;
//private String sql;ResultSet result =
null;ResultSetMetaData resMet;DAORequest() throws ClassNotFoundException,
SQLException
{.connect = getConnection();
}Connection getConnection() throws ClassNotFoundException,
SQLException {
{.forName("org.postgresql.Driver");
}(ClassNotFoundException e)
{
//return null;e;
}url, user, password;=
"jdbc:postgresql://127.0.0.1/request";= "postgres";=
"xmmGQAKq";
{DriverManager.getConnection(url, user, password);
}(SQLException e)
{e;
}
}boolean addRequest(String forName, String name, String
tarqetDate, int tarqetTimeH, int tarqetTimeM, int tarqetAud, String
targetMulti) throws SQLException {sql = "INSERT INTO
\"requests\"(\"forName\", \"name\", \"dateTime\",
\"tarqetAud\", \"targetMulti\", "+
"\"requestAccepted\",
\"requestDoned\", \"dateTimeRegistration\")VALUES(?, ?, ?,
?, ?, ?, ?, ?);";
{= connect.prepareStatement(sql);.setString(1,
forName);.setString(2, name);.setTimestamp(3,
getTimestamp(tarqetDate,((Integer)tarqetTimeH).toString(),((Integer)tarqetTimeM).toString()));.setInt(4,
tarqetAud);.setString(5, targetMulti);.setBoolean(6, false);.setBoolean(7,
false);timestamp = new Timestamp((new Date()).getTime());.setTimestamp(8,
timestamp);.executeUpdate();
}(SQLException e)
{e;
}
/*finally
{{.close();.close();
}(SQLException e)
{e;
}
}*/true;
}ArrayList<ArrayList<String>> todayRequest()
throws SQLException {callSel(0, 0, 0, 0, 0, 1);
}ArrayList<ArrayList<String>> tomorrowRequest()
throws SQLException {callSel(0, 0, 1, 0, 0, 2);
}ArrayList<ArrayList<String>> endWeekRequest()
throws SQLException {cal = new GregorianCalendar();curentDayOfWeek =
cal.get(GregorianCalendar.DAY_OF_WEEK);(curentDayOfWeek == 1)
curentDayOfWeek = 8;shift = 8 - curentDayOfWeek + 1;callSel(0, 0, 0, 0, 0,
shift);
}ArrayList<ArrayList<String>> weekendRequest()
throws SQLException {cal = new GregorianCalendar();curentDayOfWeek =
cal.get(GregorianCalendar.DAY_OF_WEEK);(curentDayOfWeek == 1)
curentDayOfWeek = 8;shift = 8 - curentDayOfWeek + 1;callSel(0, 0, shift-2, 0,
0, shift);
}ArrayList<ArrayList<String>>
timeIntervalRequest() throws SQLException {callSel(0, 0, 1, 0, 0, 2);
}boolean acceptingRequest(String id, String bool){sql =
"UPDATE requests SET \"requestAccepted\"=? WHERE
\"idRequest\"=?;";
{= connect.prepareStatement(sql);.setBoolean(1, new
Boolean(bool));.setInt(2, Integer.parseInt(id));.executeUpdate();.close();.close();
}(SQLException e)
{false;
}true;
}boolean donedRequest(String id, String bool){sql =
"UPDATE requests SET \"requestDoned\"=? WHERE
\"idRequest\"=?;";
{= connect.prepareStatement(sql);.setBoolean(1, new
Boolean(bool));.setInt(2, Integer.parseInt(id));.executeUpdate();.close();.close();
}(SQLException e)
{false;
}true;
}ArrayList<String> getUserDate(String login, String
pas) throws SQLException
{sql = "SELECT \"id\", \"fName\",
\"lName\", \"mName\", \"shortName\",
\"login\", \"pas\", \"typeUser\" FROM
public.\"user\" WHERE \"user\".\"login\" =? AND
\"user\".pas = ?;";ar = null;
{= connect.prepareStatement(sql);.setString(1,
login);.setString(2, pas);= pst.executeQuery();(result.next())
{= new
ArrayList(8);.add(result.getString(1));.add(result.getString(2));.add(result.getString(3));.add(result.getString(4));.add(result.getString(5));.add(result.getString(6));.add(result.getString(7));i;.add((i
= result.getInt(8)).toString());
}return null;(result.wasNull())return null;.close();.close();
}(SQLException e)
{null;
//throw e;
}ar;
}ArrayList<ArrayList<String>> selAllUserDate()
throws SQLException
{sql = "SELECT \"id\",
\"shortName\", \"typeUser\" FROM public.\"user\";";<ArrayList<String>>
selAllUser = null;
{= connect.prepareStatement(sql);= pst.executeQuery();=
result.getMetaData();colCount = resMet.getColumnCount();= new
ArrayList<ArrayList<String>>();(result.next())
{<String> arRow = new ArrayList<String>(colCount);.add(result.getString(1));.add(result.getString(2));.add(result.getString(3));.add(arRow);
}.close();.close();
}(SQLException e)
{e;
}selAllUser;
}boolean admAccept(String flag, String id)
{sql = "UPDATE \"user\" SET
\"typeUser\"=? WHERE id = ?;";
{= connect.prepareStatement(sql);.setInt(1, Integer.parseInt(flag));.setInt(2,
Integer.parseInt(id));.executeUpdate();.close();.close();
}(SQLException e)
{false;
}true;
}boolean InsUserDate(String login, String pas, String fName,
String lName, String mName) throws SQLException
{typeUser = 0;shortName = lName+"
"+fName.substring(0, 1) + "."+mName.substring(0, 1) +
".";sql = "INSERT INTO \"user\"(\"fName\",
\"lName\", \"mName\", \"shortName\", \"login\",
\"pas\", \"typeUser\")VALUES (?, ?, ?, ?, ?, ?, ?);";
{= connect.prepareStatement(sql);.setString(1,
fName);.setString(2, lName);.setString(3, mName);.setString(4,
shortName);.setString(5, login);.setString(6, pas);.setInt(7,
typeUser);.executeUpdate();.close();.close();
}(SQLException e)
{
//return false;e;
}true;
}ArrayList<ArrayList<String>>
commonRequest(String sqlSuffics) throws SQLException
{sql = "SELECT \"idRequest\",
\"forName\", \"name\", \"dateTime\","+
"\"tarqetAud\", \"targetMulti\",
\"requestAccepted\","+
"\"requestDoned\", \"dateTimeRegistration\"
FROM public.requests "+sqlSuffics +" ORDER BY
\"dateTime\";";= connect.prepareStatement(sql);=
pst.executeQuery();= result.getMetaData();colCount =
resMet.getColumnCount();cal = new GregorianCalendar(Locale.getDefault());frm;<ArrayList<String>>
selectRequest = new ArrayList<ArrayList<String>>();(int i = 1; i
<= colCount; i++)(result.next())
{<String> arRow = new
ArrayList<String>(colCount);(int j = 1; j <= colCount; j++)
{.add(((Integer)result.getInt(1)).toString());.add(result.getString(2));.add(result.getString(3));.setTimeInMillis(result.getTimestamp(4).getTime());=
new Formatter();.format("%td.%tm.%tY %tk:%tM",
cal,cal,cal,cal,cal);.add(frm.toString());.close();.add(((Integer)result.getInt(5)).toString());.add(result.getString(6));.add(result.getBoolean(7)
? "ДА" : "НЕТ");.add(result.getBoolean(8) ?
"ДА" : "НЕТ");.setTimeInMillis(result.getTimestamp(9).getTime());=
new Formatter();.format("%td.%tm.%tY %tk:%tM:%tS",
cal,cal,cal,cal,cal,cal);.add(frm.toString());.close();
}.add(arRow);
}.close();.close();selectRequest;
}String getTime(int shiftYear, int shiftMonth, int shiftDay)
{cal = new GregorianCalendar();.set(GregorianCalendar.HOUR_OF_DAY,
0);.set(GregorianCalendar.DAY_OF_MONTH, cal.get(GregorianCalendar.DAY_OF_MONTH)+shiftDay);.set(GregorianCalendar.MONTH,
cal.get(GregorianCalendar.MONTH)+shiftMonth);.set(GregorianCalendar.YEAR,
cal.get(GregorianCalendar.YEAR)+shiftYear);frm = new
Formatter();.format("%td.%tm.%tY", cal,cal,cal);frm.toString();
}String getSqlSuffics(String date, String date1)
{
"WHERE requests.\"dateTime\" >=
\'"+date+"\' AND requests.\"dateTime\" <=
\'"+date1+"\'";
}ArrayList<ArrayList<String>> callSel(int
shiftYear, int shiftMonth, int shiftDay,int shiftYear1, int shiftMonth1, int
shiftDay1) throws SQLException
{
{commonRequest(getSqlSuffics(getTime(shiftYear, shiftMonth,
shiftDay), getTime(shiftYear1, shiftMonth1, shiftDay1)));
}(SQLException e)
{e;
}
}Timestamp getTimestamp(String date, String h, String m)
{year, month, dayOfMonth, hours = Integer.valueOf(h),
minutes = Integer.valueOf(m);strTok = new StringTokenizer(date,
".");= Integer.valueOf(strTok.nextToken());= Integer.valueOf(strTok.nextToken());=
Integer.valueOf(strTok.nextToken());cal = new GregorianCalendar(year,
month-1, dayOfMonth, hours, minutes);timeStamp = new
Timestamp(cal.getTime().getTime());
return timeStamp;
}
}
//Модуль выборки заявок по определенным периодам SelRequest.java
import
java.io.*;java.sql.SQLException;java.util.*;javax.servlet.ServletException;javax.servlet.http.*;class
SelRequests extends HttpServlet {
@Overridevoid doGet(HttpServletRequest req,
HttpServletResponse resp)ServletException, IOException {
//String sel1 = req.getParameter("sel");(secureTested())
{
/*HttpSession session = req.getSession();sel = null;(session.getAttribute("sel")
== null)
{
sel = req.getParameter("sel");.setAttribute("sel",
sel);
}else sel = (String)session.getAttribute("sel");*/sel
= req.getParameter("sel");
/*if(sel ==
null)*/.setCharacterEncoding("utf-8");.setContentType("text/html");out
= resp.getWriter();<ArrayList<String>> arSel = null;info = null;
try
{
DAORequest dao = new DAORequest();
switch(Integer.parseInt(sel))
{
case 0: {arSel=dao.todayRequest(); info = "На сегодня"; break;}
case 1: {arSel=dao.tomorrowRequest(); info = "На завтра"; break;}
case 2: {arSel=dao.endWeekRequest(); info = "До конца недели"; break;}
case 3: {arSel=dao.weekendRequest(); info = "На выходные"; break;}
}
}
catch(SQLException e)
{
}
catch(ClassNotFoundException e)
{
}.println("<!DOCTYPE html PUBLIC \"-//W3C//DTD
HTML 4.01
Transitional//EN\">");.println("<html>");.println("<head>");
out.println("<meta content=\"text/html;
charset=utf-8\"");
out.println("http-equiv=\"content-type\">");
out.println("<title>Заявки</title>");.println("</head>");.println("<body>");.println("<div
style=\"text-align: center; font-weight:
bold;\"><big><big><big><big>Заявки " +
info);.println("<br>");.println("<br>");.println("</big></big></big></big>");.println("<div
style=\"text-align: center;\"></div>");.println("<table
style=\"text-align: left; width: 100%;\"
align=\"center\"");
out.println("border=\"1\"
cellpadding=\"2\" cellspacing=\"2\">");
out.println("<tbody>");
out.println("<tr>");
out.println("<td style=\"text-align: center;
width: 102px;\"><big><big><small><small>Запросил(а)</small></small><br>");
out.println("</big></big></td>");
out.println("<td style=\"text-align: center;
width: 101px;\"><big><big><small><small>Оформил(а)</small></small></big></big></td>");
out.println("<td style=\"text-align: center;
width: 88px;\">Время<br>");.println("выполнения</td>");
out.println("<td style=\"text-align: center;
width: 21px;\">№<br>");.println("ауд.</td>");
out.println("<td style=\"text-align: center;
width: 311px;\">Средство");.println("мультимедиа</td>");
out.println("<td style=\"text-align: center;
width: 50px;\">Приня-<br>");.println("та<br>");
out.println("</td>");
out.println("<td style=\"text-align: center;
width: 46px;\">Выпол-<br>");.println("нена");
out.println("</td>");
out.println("<td style=\"text-align: center;
width: 87px;\">Время");.println("регистрации</td>");
out.println("</tr>");(ArrayList<String>
ar : arSel)
{
out.println("<tr>");//Boolean bol =
new.println("<td style=\"text-align: center; width:
102px;\"><small>"+ar.get(1)+"</small></td>");.println("<td
style=\"text-align: center; width:
101px;\"><small>"+ar.get(2)+"</small></td>");.println("<td
style=\"text-align: center; width:
88px;\"><small>"+ar.get(3)+"</small></td>");.println("<td
style=\"text-align: center; width:
21px;\"><small>"+ar.get(4)+"</small></td>");.println("<td
style=\"text-align: center; width:
311px;\"><small>"+ar.get(5)+"</small></td>");.println("<td
style=\"text-align: center; width: 50px;\"><big><big>");strForA
= "?sel=%s&id=%s&flag=%s&field=%s";frm = new
Formatter();.format(strForA, sel, ar.get(0), ar.get(6).equals("ДА") ?
"true":"false","0");sesion;=
req.getSession(true);admUser =
(String)sesion.getAttribute("typeUser");bol =
(admUser.equals("1") ? true : false);h = frm.toString();= new
Formatter();.format(strForA, sel, ar.get(0), ar.get(7).equals("ДА") ?
"true":"false","1");h1 = frm.toString();(bol)
{.println("<a
href=\"DoneingAccepting"+h+"\"
name=\"submitRequest\">"+ar.get(6)+"</a></big></big></td>");.println("<td
style=\"text-align: center; width: 46px;\"><big><big><a");.println("href=\"DoneingAccepting"+h1+"\"
name=\"showRequest\">"+ar.get(7)+"</a></big></big></td>");
}
{.println(ar.get(6)+"</big></big></td>");.println("<td
style=\"text-align: center; width:
46px;\"><big><big>"+ar.get(7)+"</big></big></td>");
}.println("<td style=\"text-align: center;
width:
87px;\"><small>"+ar.get(8)+"</small></td>");.println("</tr>");
}.println("<tr
align=\"center\">");.println("<td
colspan=\"8\"
rowspan=\"1\"><big><big><big><big><a");.println("href=\"showRequest.html\"
name=\"index\">Посмотреть еще</a></big></big></big></big></td>");.println("
</tr>");
out.println("</tbody></table></div></body></html>");
}
//resp.sendRedirect("/");
}boolean secureTested()
{true;
}
}