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

Размещено на http://www.allbest.ru/

Содержание

• Введение
• 1. Аналитический обзор
• 1.1 Анализ процесса планирования различных видов работ
• 1.2 Актуальность разработки системы
• 1.3 Программные средства, используемые для решения поставленной задачи
• Выводы по первой главе
• 2. Проектирование автоматизированной информационной системы
• 2.1 Описание модели системы планирования и учета нарядов подразделения
• 2.2 Подсистема "регистрации пользователей"
• 2.3 Подсистема "идентификации и авторизации пользователей"
• 2.4 Подсистема "первоначального ввода и редактирования личных данных"
• 2.5 Подсистема "просмотра информации о пользователе"
• 2.6 Подсистема "администрирования"
• 2.7 Подсистема "обмена личными сообщениями между пользователями" системы
• 2.8 Подсистема "просмотра нарядов"
• 2.9 Подсистема "планирования, распределения и учета нарядов"
• 2.10 Структура базы данных
• 3. Выбор аппаратной и программной платформы системы планирования и учета нарядов подразделения
• 3.1 Определение архитектуры создаваемой системы
• 3.2 Обзор существующихWeb-технологий
• 3.3 Сравнение существующих технологий программирования
• 3.4 Выбор платформы системы
• Выводы по третьей главе
• 4. Программная реализация информационной системы
• 4.1 Главная страница сайта
• 4.2 Регистрация пользователя в системе планирования и учета нарядов подразделения
• 4.3 Реализация подсистемы "идентификации и авторизации"
• 4.4 Реализация подсистемы "Просмотра профиля"
• 4.5 Реализация подсистемы "Первоначального ввода и редактирования личных данных"
• 4.6 Реализация подсистемы "обмена личными сообщениями между пользователями"
• 4.7 Реализация подсистемы "просмотра нарядов"
• 4.8 Реализация подсистемы "планирования, распределения и учета нарядов"
• 4.9 Реализация подсистемы "администрирования"
• Заключение
• Список литературы
• Приложения

Введение

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

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

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

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

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

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

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

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

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

1. Аналитический обзор

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

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

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

1.1 Анализ процесса планирования различных видов работ

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

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

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

Проанализировав существующее положение дел при планировании нарядов, получаем следующее:

1. распределение происходит в несколько этапов различными должностными лицами;

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

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

4. при внесении изменений в расписание нарядов не обеспечивается качество - своевременность в достаточном объеме;

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

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

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

1.2 Актуальность разработки системы

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

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

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

1.3 Программные средства, используемые для решения поставленной задачи

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

· Браузер Google Chrome

· NotePad++

· Denwer

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

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

Автономные обновления. Большинство браузеров при обновлении просят скачать, а затем установить какой-то файл. Chrome - один из немногих интернет обозревателей, обладающих высоким уровнем безопасности. Он способен защитить компьютер от взлома и заражения, поскольку в него интегрирован список ненадежных сайтов (постоянно обновляется), а файлы с расширением BAT, DLL, EXE запускаются только после подтверждения.

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

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

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

Denwer - программная оболочка, используемая Web-разработчиками для разработки сайтов на "домашней" (локальной) Windows-машине без необходимости выхода в Интернет. Главная особенность Денвера - удобство при удаленной работе сразу над несколькими независимыми проектами и возможность размещения на Flash-накопителе.

Выводы по первой главе

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

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

2. Проектирование автоматизированной информационной системы

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

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

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

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

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

2.1 Описание модели системы планирования и учета нарядов подразделения

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

Рисунок1 - Общая схема автоматизированной системы планирования и учета нарядов подразделения

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

Разрабатываемый информационный ресурс состоит из 8 подсистем, которые входят в состав системы планирования и учета нарядов подразделения, а именно:

1. подсистема регистрации пользователей;

2. подсистема идентификации и авторизации пользователей;

3. подсистема первоначального ввода и редактирования личных данных;

4. подсистема просмотра информации о пользователе;

5. подсистема обмена личными сообщениями между пользователями;

6. подсистема планирования, распределения и учета нарядов;

7. подсистема просмотра нарядов;

8. подсистема администрирования.

На рисунке ниже представлена структурная схема взаимодействия подсистем.

Рисунок2 - Структурная схема автоматизированной системы планирования и учета нарядов подразделения

Как видно из рисунка, подсистемы структурно связанны между собой и образуют единую систему.

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

Рисунок3 - Функциональная схема взаимодействия подсистем

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

1. комендант;

2. начальник факультета;

3. начальник кафедры;

4. офицер факультета;

5. офицер кафедры;

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

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

Рисунок4 - Принцип распределения нарядов в филиале

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

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

2.2 Подсистема "регистрации пользователей"

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

Регистрация проходи по 4 полям:

1. логин пользователя, в данном случае выступает фамилия военнослужащего;

2. тип профиля необходимо выбрать из вариантов: комендант, начальник факультета, начальник кафедры, офицер факультета или офицер кафедры;

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

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

Стоит заметить, что при регистрации в целях безопасности пароль сохраняется в БД в зашифрованном виде.



Рисунок 5 - Блок схема алгоритма работы подсистемы регистрации

2.3 Подсистема "идентификации и авторизации пользователей"

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

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

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



Рисунок 6 - Блок схема алгоритма подсистемы идентификации и авторизации пользователей

2.4 Подсистема "первоначального ввода и редактирования личных данных"

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

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

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

Начальник факультета, как и офицер факультета, заполняют поля так же поля:

1. должность;

2. номер факультета.

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

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

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

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

2.5 Подсистема "просмотра информации о пользователе"

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

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

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

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

2.6 Подсистема "администрирования"

Подсистема "администрирования" непосредственно предназначена для внесения изменений в функциональную часть системы, изменения настроек и создания правил, она состоит из 6 панелей:

1. пользователи;

2. факультеты;

3. кафедры;

4. правила распределения нарядов;

5. управление праздниками;

6. виды нарядов.

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

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

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

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

1. просмотр нарядов - праздничные дни, как и выходные, отмечаются отличительным цветом;

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

3. распределение нарядов - в процессе планирования и распределения праздничные дни влияют на статистику и выставление нарядов.

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

1. сокращение - служит для краткого отображения вида наряда в общей таблице нарядов подразделения;

2. полное описание - для расшифровки сокращения.

2.7 Подсистема "обмена личными сообщениями между пользователями" системы

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

Данный модуль содержит следующие компоненты:

1. выбор пользователя, которому необходимо отправить сообщение;

2. набор и отправка сообщения;

3. получение сообщений от пользователей;

4. визуальное оповещение о том, что получено новое сообщение (не зависимо от того, в каком модуле системы работает пользователь);

5. очистка диалоговых окон.

Таким образом, подсистема решает следующие задачи:

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

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

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

2.8 Подсистема "просмотра нарядов"

В подсистеме "просмотра нарядов" имеются 3 режима:

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

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

3. режим просмотра нарядов за конкретного пользователя.

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

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

1. вид наряда;

2. номер кафедры (факультета), военнослужащий которой заступает в наряд;

3. фамилия заступающего офицера.

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

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

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

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



Рисунок 7 - Блок схема алгоритма формирования подсистемы "просмотра нарядов"

2.9 Подсистема "планирования, распределения и учета нарядов"

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

1. комендант;

2. начальник факультета или начальник кафедры.

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

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

1. ручное редактирование;

2. автоматический.

Общая схема функционирования подсистемы изображена на рисунке ниже.



Рисунок 8 - Общая блок схема функционирования подсистемы "планирования, распределения и учета нарядов"

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

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

Рисунок 9 - Функциональная схема автоматического процесса распределения нарядов

На вход подсистемы подаем:

1. период времени, на который будет производиться распределение нарядов;

2. список подразделений, участвующих в распределении;

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

4. факторы, влияющие на распределение, руководящие документы, уставы

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

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

1. процент нарядов в выходные и праздничные дни от общего количества нарядов в прошлом месяце за конкретное подчиненное подразделение;

2. процент нарядов в будни дни конкретного подчиненного подразделения от общего количества нарядов подразделения за прошлый месяц;

3. процент нарядов в выходные и праздничные дни конкретного подчиненного подразделения от общего количества нарядов подразделения за прошлый месяц;

4. в процессе распределения нарядов на день преимущественно не ставится подчиненное подразделение в несколько видов нарядов;

5. при равной статистике нескольких подчиненных подразделений выбирается случайно подчиненное подразделение, которое будет выставлять наряд;

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

Далее представлены факторы, которые влияют на планирование нарядов по подчиненным пользователям:

1. процент нарядов в выходные и праздничные дни от общего количества нарядов пользователя в прошлом месяце;

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

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

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

5. проверятся возможность военнослужащего в определённой должности заступать в соответствующие виды нарядов;

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

2.10 Структура базы данных

Рисунок 10 - Структура базы данных

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

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

1. каждый элемент таблицы - один элемент данных;

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

3. каждый столбец имеет уникальное имя;

4. одинаковые строки в таблице отсутствуют;

5. порядок следования строк в столбце может быть произвольным.

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

1. kaf_users - сущность, хранящая в себе данные обо всех пользователях, зарегистрированных в системе. По уникальному атрибуту"id" связана с сущностями: kaf_session, kaf_mail, kaf_holidays, kaf_duty;

2. kaf_duty - экземпляры данной сущности описывают наряды в системе;

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

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

1. kaf_session -данные сессий пользователей;

2. kaf_mail -личные сообщения пользователей;

3. kaf_holidays - информация о праздниках пользователей и общих праздниках подразделения;

4. kaf_dutyTypes - виды нарядов (дежурный по филиалу, помощник дежурного по филиалу и т.д.);

5. kaf_ranks - виды званий военнослужащих (лейтенант, полковник и.д.);

6. kaf_usersRoles - типы профилей пользователей (комендант, офицер факультета и т.д.);

7. kaf_jobs - должности военнослужащих (начальник кафедры, курсовой офицер и т.д.);

8. kaf_unitsType - тип подразделения(факультет, кафедра);

9. kaf_fucks - подчиненные подразделения (факультеты);

10. kaf_kafs - подчиненные подразделения (кафедры);

Выводы по второй главе

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

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

3.1 Определение архитектуры создаваемой системы

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

К таким особенностям можно отнести:

1. территориальную удалённость подразделений института и

соответственно рабочих мест пользователей системы;

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

различие выполняемых пользователями задач, в соответствии со своим должностным положением;

необходимость централизованного использования и хранения информации.

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

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

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

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

3.2 Обзор существующих Web-технологий

Платформенно-независимый интерфейс CGI

Значительные сервисные ресурсы могут быть созданы с применением технологии CGI. Платформенно-независимый интерфейс CGI (CommonGatewayInterface - дословно - общий шлюзовой интерфейс) используется для исполнения программ совместно с Web-сервером. Такие программы называются CGI-приложениями. Рассмотрим, как работает данная технология.

В зависимости от решаемой задачи в CGI-программе может быть выбран любой из поддерживаемых протоколом HTTP форматов данных: текст, изображение, документ в HTML-формате с соответствующим форматированием, аудиофайл и прочее. Пользователь же не заметит никакой разницы, загрузил ли он существовавший документ с диска Web-сервера, или этот документ был создан для него CGI-программой "на лету".

CGI-программа может представлять собой любой исполняемый файл - будь то программа, написанная на языке С, Shell-скрипт или программа на Perl. Вообще приложениями CGI называются программы, которые, пользуясь этим интерфейсом, получают через протокол HTTP информацию от удаленного пользователя, обрабатывают ее, и возвращают результат обработки обратно в виде ссылки на уже существующий документ HTMLили другой объект (например, графическое изображение) или в виде документа HTML, созданного динамически. Из-за того, что очень часто такие программы пишутся именно на языках-интерпретаторах (подобных Basic, Perl, PHP), их традиционно называют сценариями.

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

Язык разработки сценариев РНР

РНР - язык, специально нацеленный на работу в сети Интернет, который позволяет встраивать программный код в HTML-доку менты. Синтаксис языка чрезвычайно ясный и читаемый, сочетает в себе все достоинства языков Perl и С.

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

Как правило, Web-документы, написанные на языке РНР, имеют расширение.php. Рассмотрим, как работает данная технология. РНР-"программа" представляет собой обычный HTML-файл, в который в требуемых местах встроен программный код, выполняющий заданные действия. Вставки кода оформляются парой тегов <?php и ?>, между которыми может находиться необходимое число операторов языка. При запросе такого документа пользователем Web-сервер вызывает специальный PHP-интерпретатор и передает ему этот документ. Интерпретатор просматривает его, пропуская все теги HTML и выполняет все операторы программной вставки. Сама программная вставка, ограниченная тегами <?php и ?>, удаляется из документа, а на ее место вставляется результат выполнения операторов этой вставки, в том случае, конечно, если в ней содержатся операторы вывода. При этом сам HTML-файл фактически выступает в роли статического шаблона, в котором изменяемые фрагменты реализуются программным кодом. Результат такой обработки отправляется пользователю. Пользователь же никогда не сможет узнать, какой конкретно фрагмент (и вообще имелись ли такие фрагменты) был сгенерирован динамически. Однако если Web-сервер не имеет PHP-интерпретатора, но на нем была размещена страница с инструкциями на этом языке, то страница, вместе со всеми программными вставками будет передана пользователю. Так как вставки кода оформляются парой тегов <?php и ?>, они будут восприняты браузерами как комментарии, и отображены пользователю не будут. Хотя пользователь сможет увидеть их, запросив в браузере исходный код страницы. планирование наряд идентификация авторизация

Как следует из изложенного алгоритма, элементарная РНР-программа вообще может не содержать ни одной программной вставки. Тем не менее, такая "программа" будет вполне рабочей, и при ее интерпретации в интерпретаторе Web-сервера никакой ошибки не произойдет. Иными словами, PHP-сценарий вообще может не отличаться от HTML-документа.

Синтаксис языка РНР обширен и функционален. Язык не требует ни объявления переменных, ни указания их типов. Все преобразования типов выполняются интерпретатором автоматически. Язык поддерживает множество управляющих структур - выбор, циклы, ветвления, поддерживаются функции. В языке реализованы некоторые принципы объектно-ориентированного программирования. К достоинствам языка относится богатый набор "встроенных" функций самого широчайшего назначения: файловых, сетевых, математических, строковых, функций для доступа к базам данных и многих других. РНР изначально ориентирован на поддержку CGI - при обработке форм в обрабатывающем сценарии становятся автоматически доступны все переменные, которые соответствуют элементам форм, что в значительной мере упрощает работу Web-программиста.

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

Технология построения интерактивных документов

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

ДинамическийHTML (DynamicHTML, или DHTML) не является каким-то особым языком разметки страниц. Это термин, применяемый для обозначения HTML-страниц с динамически изменяемым на стороне клиента содержимым.

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

Компоненты ActiveX создаются с применением технологии

программирования COM (ComponentObjectModel), разработанной Microsoft.

С точки зрения программиста, использующего его, ActiveX-элемент - это

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

Элементы ActiveX хранятся на компьютере пользователя. Каждый элемент имеет уникальный идентификатор, и соответствующую, уникальную для каждого элемента запись в реестре операционной системы Windows. Встраивание элемента в HTML-страницу выполняется с помощью пары тегов <OBJECT>..</OBJECT>, содержащих идентификатор встраиваемого элемента ActiveX, а так же необходимое количество других параметров, задающих свойства элементов. Кроме того, может быть задан параметр, определяющий, откуда может быть загружен используемый ActiveX элемент, если он еще не имеется на компьютере пользователя.

ActiveServerPages (ASP)

Технология ASP компании Microsoft является аналогом рассмотренных ранее серверных технологий. Более всего ASP функционально походит на CGI. ASP-страница - это HTML-документ, содержащий сценарии, которые позволяют работать с управляющими элементами ActiveX, в том числе, и элементами для доступа к базам данных. Особенностью этой технологии является то, что в качестве языков сценариев для написания динамических вставок как правило используются JavaScript и VBScript, хотя допустимо использование и других языков. Сценарий управляет объектами, результаты работы которых представляются в формате DynamicHTML.

Технологию ASP используют Web-серверанабазе Windows - Internet Information Server и Personal Web Server. Таким образом, ASP в некоторой мере может служить заменой CGI на Windows-платформах.

3.3 Сравнение существующих технологий программирования

Рассмотрим особенности CGI и РНР. Очевидно, что реализация серьезных динамических Web-документов в этих технологиях неосуществима без передачи исходной информации от клиента на сервер. При изложении CGI были рассмотрены способы, которыми на сервер могут быть переданы данные. Было сказано, что задача написания функций, реализующих тот или иной алгоритм раскодирования информации и интерпретации строки параметров возлагается на программиста. На каком бы языке сценарий написан бы ни был, если этот язык не имеет соответствующих функций, то программисту придется заботиться и о решении этой совсем не простой задачи. В этом смысле выгодно отличается РНР, который был специально разработан для работы с Web-документами. Если PHP-сценарию была передана строка параметров, вне зависимости от использовавшегося для этого метода, все эти параметры становятся автоматически доступны в сценарии. Иными словами, если серверу была передана строка valuel=aaa&value2=%8E%8F%90, то в сценарии на момент выполнения программы эти данные будут в распоряжении программиста в виде массива. Никаких перекодированний и никаких интерпретаций строк параметров выполнять не потребуется.

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

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

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