1. комендант;
2. начальник факультета или начальник кафедры.
Группы пользователей "офицер факультета" и "офицер кафедры" в изменении таблицы нарядов участия не принимают. В случае попытки несанкционированное воспользоваться подсистемой, будет выведено сообщение об ограничении доступа. Как было сказано ранее, в описании общей модели системы, комендант занимается планированием нарядов за подразделение, распределяя подчиненные подразделения по видам нарядов на каждый день месяца. В свою очередь начальник факультета или кафедры распределяет наряды на те дни, где имеются наряды на подчиненное подразделение и в определенные виды нарядов.
В подсистеме каждой выше указанной группы пользователей, планирующих наряды, существую 2 режима распределения:
1. ручное редактирование;
2. автоматический.
Общая схема функционирования подсистемы изображена на рисунке ниже.
Рисунок
8 - Общая блок схема функционирования подсистемы "планирования,
распределения и учета нарядов"
Автоматизированный режим подразумевает вмешательство пользователя в распределение нарядов, то есть, например, комендант назначает сам подразделение в определенный вид наряда на конкретный день, без какого-либо математического аппарата и статистики, другими словами - на свое усмотрение.
Отдельное внимание стоит уделить автоматическому режиму. Функциональная
схема автоматического режима может быть представлена следующим образом:
Рисунок
9 - Функциональная схема автоматического процесса распределения нарядов
На вход подсистемы подаем:
1. период времени, на который будет производиться распределение нарядов;
2. список подразделений, участвующих в распределении;
3. список военнослужащих, способных нести наряд;
4. факторы, влияющие на распределение, руководящие документы, уставы
На выходе мы получаем таблицу нарядов, на указанный период времени, спланированную определенным образом с учетом, влияющих факторов.
Отдельно рассмотри факторы, которые могут влиять на распределение нарядов в подразделении по подчиненным подразделениям, то есть в автоматическом режиме от лица коменданта:
1. процент нарядов в выходные и праздничные дни от общего количества нарядов в прошлом месяце за конкретное подчиненное подразделение;
2. процент нарядов в будни дни конкретного подчиненного подразделения от общего количества нарядов подразделения за прошлый месяц;
3. процент нарядов в выходные и праздничные дни конкретного подчиненного подразделения от общего количества нарядов подразделения за прошлый месяц;
4. в процессе распределения нарядов на день преимущественно не ставится подчиненное подразделение в несколько видов нарядов;
5. при равной статистике нескольких подчиненных подразделений выбирается случайно подчиненное подразделение, которое будет выставлять наряд;
После распределения нарядов по подчиненным подразделениям, в случае режима от лица коменданта, выполняется функция распределения нарядов по пользователям, у начальника кафедры и начальника факультета присутствует лишь эта функция, распределение нарядов по подчиненным подразделениям в данных типах профилей не доступна.
Далее представлены факторы, которые влияют на планирование нарядов по подчиненным пользователям:
1. процент нарядов в выходные и праздничные дни от общего количества нарядов пользователя в прошлом месяце;
2. процент нарядов в будни дни конкретного пользователя от общего количества нарядов подразделения, в котором он состоит, за прошлый месяц;
3. процент нарядов в выходные и праздничные дни пользователя от общего количества нарядов подразделения, в котором он состоит, за прошлый месяц;
4. в процессе распределения нарядов на день учитывается нахождение военнослужащего в наряде на прошлый, текущий и следующий день, другими словами - военнослужащий не будет поставлен в наряд сегодня, если он стоит уже в наряде, либо сегодня заступает в другой вид наряда, либо завтра заступает в наряд;
5. проверятся возможность военнослужащего в определённой должности заступать в соответствующие виды нарядов;
6. в случае, если у военнослужащего на определенную дату отмечено знаменательное событие, которое указывается в подсистеме "первоначального ввода и редактирования личных данных", то у него есть преимущественное право не заступать в этот день в наряд, кроме того случая, если больше из его подразделения некому идти в наряд.
Рисунок 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 - подчиненные подразделения (кафедры);
Выводы по второй главе
Во второй главе были разработаны: общая модель функционирования системы планирования и учета нарядов, структурная схема системы и функциональная схема взаимодействия подсистем. Была проведена декомпозиция отдельных работ, на основании которой разработана база данных данной системы.
Важным вопросом разработки любой информационной системы является вопрос выбора архитектуры и способа её построения. Архитектура должна соответствовать требованиям и задачам, которые возлагаются на систему. Кроме того в ней должны быть учтены особенности использования системы.
К таким особенностям можно отнести:
1. территориальную удалённость подразделений института и
соответственно рабочих мест пользователей системы;
2. использование системы одновременно несколькими пользователями;
3. различие выполняемых пользователями задач, в соответствии со своим должностным положением;
4. необходимость централизованного использования и хранения информации.
Достойным в данных условиях решением задачи выбора архитектуры будет решение построения системы по клиент-серверной технологии. При её использовании функции системы можно разделить на функции клиентской и серверной части.
Главными функциями клиентской части являются интерфейсные, которые позволяют пользователю принимать информацию от системы и формировать к ней пользовательские запросы.
На серверной части реализуются функции основной логики работы системы. Сервер в клиент-серверной архитектуре занимает центральное место, поэтому через него можно реализовать общее управление всей системой. На серверной части помимо логики работы системы закладывается её информационная база, что так же позволяет централизованно хранить информацию.
В настоящее время большое распространение получили WEB -технологии. Они наилучшим образом реализуют клиент - серверную архитектуру. WEB - технологии позволяют создавать сайты различной сложности и структуры для решения практически любых задач. В случае решения поставленной перед данной дипломной работой задачи по созданию системы электронного оборота, успешно будет применение 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-программиста.