6. Сдавать в аренду без права выкупа закрепленные за ним площади.

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

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

Действующую в настоящее время организационную структуру университета можно представить следующим образом (см. РТДП 5.000.004).

В составе университета имеются 6 очных факультетов (ФПК, ФРЭ, ФКТК, ФИТиУ, ФКСиС, ЭФ), вечерний и заочный факультеты, факультет до университетской подготовки и факультет повышения квалификации.

На одном курсе факультета может быть несколько потоков, а в потоке -- несколько групп.

Высшая исполнительная власть в университете принадлежит ректору.

Для решения оперативных вопросов управления университетом при ректоре создается ректорат. В его состав входят: ректор, проректор, деканы, начальники УМУ, ОК, учебного отдела, гл. бухгалтер и некоторые другие руководители служб.

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

Часть полномочий ректором может быть передана проректорам, деканам и другим должностным лицам.

Высшим коллективным органом управления университетом является Совет университета, который решает основные вопросы деятельности университета. Он избирается на 3 года, состав персональный, ППС на менее 75%. Принципы и организация работы оговорены в Уставе университета.

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

Для решения оперативных вопросов управления факультетом при декане создается деканат в составе декана, зам. декана, зав. кафедрами и других лиц, определенных распоряжением по факультету. Коллективным органом управления факультета является Совет факультета, который решает основные вопросы деятельности факультета. Состав персональный (декан, зам. Декана, зав. кафедрами, ППС, научный персонал, студенты), ППС не менее 75%, избирается на 3 года, утверждается ректором университета. Принципы и организация работы оговорены в Уставе университета.

Учебные и воспитательные процессы, методическую и научно-исследовательскую работу ведут кафедры. Кафедры возглавляют зав. кафедрами, избираемые Советом университета на 5 лет. В состав кафедры входят учебные лаборатории, классы, кабинеты, спецаудитории, научно-исследовательские лаборатории (НИЛ). Кафедра может иметь в своем составе филиалы на производстве.

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

Кафедры выполняют различные научно-исследовательские работы, вовлекая в научную работу аспирантов и студентов.

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

Учебный план (типовой, рабочий) определяет:

время обучения;

перечень и объем изучаемых дисциплин, в часах;

последовательность их изучения;

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

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

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

методические указания;

тематика лекции и их краткое содержание;

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

наличие курсовых проектов или курсовых работ;

форма завершения курса (экзамен или зачет).

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

2.3 Функциональная структура Вуза

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

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

2. Выявить используемые внешние и внутренние документы и составить формализованную схему документооборота.

3. Определить информационные связи между отдельными подразделениями.

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

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

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

7. Определить дублирование и запаздывание в передаче и обработке данных.

8. Уточнить применяемую терминологию для обеспечения смыслового единства информации.

Информационные потоки, независимо от их содержания, характеризуются:

источником возникновения;

назначением;

степенью взаимосвязи;

степенью постоянства;

структурой;

видом носителя;

объемом и плотностью потока;

информационной емкостью сообщения;

методом образования;

способом и степенью их использования.

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

2.4 Проведение исследования и анализа информационных потоков и документооборота Вуза

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

Из каждой отобранной группы сообщений в качестве объекта наблюдения отбирается несколько наиболее характерных. Детально прослеживается их движение от момента возникновения (получения) до исполнения. Такой способ наблюдения «от сообщения», а не «от исполнителя» имеет ряд преимуществ:

учитываются все инстанции, которые участвуют в исполнении данного документа;

детально отражаются все операции, выполняемые с передачей и преобразованием сообщения;

наглядно устанавливается логическая связь между различными этапами обработки сообщений;

с большей точностью регистрируются маршруты передачи сообщений.

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

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

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

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

повторяемость и время выполнения операций;

межоперационное время «бездействия» сообщения.

Далее рассмотрим состав, содержание и последовательность проведенных работ по обследованию потоков документальной информации (см. рис. 2.2).

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

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

Рис. 2.2 Состав, содержание и последовательность выполнения работ по обследованию потоков документальной информации

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

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

количество и причины возвратов на одно и то же рабочее место;

способ, время и пути маршрутизации сообщения.

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

В процессе обследования информационных потоков должны быть:

Учтены все существующие в Вузе формы документов и проверены на соответствие ГОСТам, стандартам и другим нормативным требованиям.

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

Определены количественные и качественные характеристики используемых сообщений и документов.

Выявлены маршруты движения каждого документа.

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

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



2.5 Документы системы документооборота деканата

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

К основным документам, так или иначе относящимся к деятельности деканата, можно отнести следующие.

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

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

Типовые программы курсов. Применение данного вида документов пока только планируется. Разработку осуществляет Министерство Образования.

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

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

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

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

На протяжении всего периода обучения студентов диспетчера заполняют учетные карточки студентов (вносят личные данные, сведения об успеваемости, благодарности и взыскания).



3. Разработка программного обеспечения автоматизации документооборота Вуза

Прежде всего, определим требования, предъявляемые к программному обеспечению автоматизации делопроизводства деканата:

1. Надежность и целостность данных. Фактически, с этой задачей справляется СУБД используемой базы данных.

2. Многопользовательский параллельный доступ. Очевидно, что приложение должно обеспечивать возможность работ с документами деканата одновременно нескольким пользователям (декану, зам. декана, диспетчерам и т.д.). При этом обязательно реализовать средства синхронизации и распараллеливания доступа к данным. Также необходимо разграничить привилегии пользователей на операции с данными.

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

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

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

1. Модуль нотификации подключенных (on-line) пользователей. Данный модуль рассылает сообщения об изменениях на уровне отдельных записей базы данных (внесение изменений в оценки студента, изменение информации, хранимой в личной карточке студента) тем пользователям, которые в данный момент работают с приложением.

2. Модуль нотификации пользователей по электронной почте. Обеспечивает уведомление пользователей об изменениях в базе данных на уровне таблиц и представлений (например, создание/удаление экзаменационной или зачетной ведомости). Уведомление по электронной почте является достаточно надежным способом донести сообщения об изменениях в БД как активным клиентам, работающим с приложением на момент внесения изменений, так и прочим пользователям. Использование электронной почты (в отличии от собственного протокола нотификации) позволяет использовать на стороне пользователя стандартные программы чтения сообщений данного вида (Outlook Express, Microsoft Outlook, Eudora Mail, The Bat, Netscape Messenger и прочие).

3.1 Архитектура приложения

3.1.1 Сравнение двух- и трехуровневой архитектуры «клиент-сервер»

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

Рис. 3.1 Двухуровневая архитектура «клиент-сервер»

Идея трехуровневой архитектуры (см. рис. 3.2) состоит в перемещении значительной части кода, осуществляющего выборку и обработку данных, на третий уровень. Этот уровень в основном хранит всю функциональную логику, необходимую для работы клиентов, если они не хранят само описание бизнес-процессов.

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

Клиенты не хранят больше код, осуществляющий доступ к данным с помощью SQL. Они никогда не видят строки данных и не преобразуют их в локальные переменные или в элементы выходных данных. Java-клиенты для манипулирования данными могут использовать только соответствующие методы объектов.

Оставшаяся, наиболее чувствительная к изменениям часть -- это третий уровень. Являясь клиентом базы данных и в некотором смысле сервером приложений клиента, этот уровень хранит код доступа к данным и запросы SQL, использующие JDBC для выполнения своих операций. На этом уровне строки данных преобразуются в объекты Java. Например, запрос, возвращающий список студентов, возвратил бы набор объектов Java, называемых Student (студент), а для отдельного объекта Student или набора таких объектов может быть вызван метод calculateScholarship (начислить стипендию).

Приложение клиента использует объекты Student и знает метод calculateScholarship, но эти понятия реализуются не в рамках этого приложения. Объекты коллективного пользования называются proxy-объектами на стороне клиента. Они реализуются в промежуточном слое, и всякий раз, когда клиент вызывает метод calculateScholarship, этот метод запускается в промежуточном слое и выполняет инструкцию SQL. Поскольку реализация клиента невидима для клиента, она называется невидимым объектом.

Рис. 3.2. Трехуровневая архитектура «клиент-сервер»

Реальное внедрение трехуровневой архитектуры в значительной степени зависит от концепции программного обеспечения, связывающего вместе proxy-объекты и невидимые объекты (NonVisible Object, NVO). Среди многочисленных возможностей наиболее общеупотребительными для Java являются RMI и CORBA. RMI означает вызов удаленного метода (Remote Method Invocation), а CORBA -- обобщенную архитектуру брокера объектных запросов (Common Object Request Broker Architecture).

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

3.1.2 Общая схема работы приложения

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

Апплет, приложение клиента. На данном уровне осуществляется вывод информации, получаемой от объектов второго уровня, а также диспетчеризация команд пользователя в вызов соответствующих методов данных объектов. Первый уровень состоит из целого набора proxy-объектов, каждый из которых представляет отдельную сущность в рамках системы документооборота -- Student (студент), TestJornalRecord (запись в экзаменационной/зачетной ведомости) и т.д.

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

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

Система работает по следующей схеме (см. рис. 3.3).

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

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

На серверной стороне происходит получение запроса и диспетчеризация его соответствующему обработчику на основании переданных параметров. Обработчик разбирает запрос, создает NVO для запрашиваемого объекта и выполняет над ним требуемую операцию. Результаты операции (в случае отсутствия ошибок), а также статус ее состояния («успешное выполнение»/«ошибка при передаче или выполнении»/«предупреждение»). И, наконец, обработчик передает результаты модулям нотификации. Таким образом, на данном этапе пользователь, пославший запрос получает данные, а сервер нотифицирует остальных пользователей об изменениях.

Модуль on-line нотификации рассылает датаграммы всем активным пользователям, которые принимаются соответствующим модулем апплета. Off-line нотификация представляет собой сообщение электронной почты и помещается в почтовые ящики пользователей.

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

Рис. 3.3. Архитектура приложения

Понятие «документ» в приложении

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

Обычно объекты Java или экземпляры классов неустойчивы, если они не записаны на внешний носитель любого формата (т.е. они неустойчивы вне использующего их приложения). Значения заполняют элементы данных во время работы, и, если не предполагается их дальнейшего использования, элементы данных удаляются сборщиком мусора (Garbage Collector) и стираются. Выход из программы разрушает объекты.

Решение лежит в использовании устойчивости объекта, позволяющей сохранять в действии элементы объектов, даже когда приложение не выполняется. Системы управления базами данных позволяют сделать системы устойчивыми. Они предлагают множество служб, ориентированных на данные, а также обще употребительный язык запросов. Несмотря на то, что SQL используется в контексте реляционных баз данных, язык объектных запросов (Object Query Language, OQL) запрашивает объекты, хранимые в объектных системах управления базами данных (ОСУБД).

Многие общепринятые СУБД являются реляционными, а не объектно-ориентированными, но это не имеет никакого значения. Легко написать методы для выполнения основных задач, касающихся устойчивости. Вот основные из них:

создание нового объекта;

удаление объекта;

обновление объекта;

выбор одного или набора объектов;

дублирование (клонирование) объектов.

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

Устойчивость объектов реализуется на промежуточном слое и обеспечивает длительное существование важных объектов приложения. Необходимо сделать замечание относительно понятия устойчивости в данном программном средстве. Каждый объект-документ поддерживает интерфейс java.io.Serializable, т.е. способен сохранять свое состояние в потоке. Приложение использует это свойство для обмена данными между клиентом и сервером. Истинная устойчивость реализована в NVO как совокупность запросов/хранимых процедур, отвечающих за вставку, изменение и удаление конкретных записей в связанные с документом таблицы.

Клонирование реализовано только для proxy-объектов на стороне клиента. Каждый объект, являющийся документом либо его частью, реализует интерфейс java.lang.Clonable и переопределяет метод java.lang.Clonable.clone(), отвечающий за создание копии объект.

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

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

Используемая в программе иерархия классов, при которой класс NVO является производным по отношению к классу proxy-объекта, предполагает вложенность proxy-объектов в NVO (см. рис. 3.4).

Все proxy-объекты документов расширяют абстрактный класс org.bsuir.diplom.common.data.ProxyObject. Суть класса состоит в наборе методов, позволяющих получить/модифицировать любое свойство объекта-документа, проверить наличие свойства, получить набор свойств, составляющих идентификатор объекта -- прямое отображение первичного ключа связанной таблицы базы данных. Каждое свойство является объектом, в том числе свойство может быть вложенным объектом-документом. NULL-значения полей отображаются в объект org.bsuir.diplom.common.NullObject.

NVO-объект расширяет proxy-объект добавлением следующих методов:

org.bsuir.diplom.common.notification.Message insertObject() throws java.sql.SQLException -- добавление объекта в базу данных;

org.bsuir.diplom.common.notification.Message updateObject() throws java.sql.SQLException -- обновить объект в базе данных;

org.bsuir.diplom.common.notification.Message deleteObject() throws java.sql.SQLException -- удалить объект из базы данных.

Каждая из этих функций возвращает объект типа org.bsuir.diplom.common.notification.Message, который представляет собой сообщение клиентам об изменении объекта, или нулевой объект, если нотификация не требуется. За получение списка документов отвечает метод класса static void selectObjects(org.bsuir.diplom.common.transfer.TransferCommand command, java.io.OutputStream stream).

Рис. 3.4. Внутренние документы приложения

3.1.3Параллельная обработка и синхронизация

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

Существует только одно решение этой проблемы: максимально сокращать транзакции базы данных. Не следует хранить открытыми соединения, не являющиеся необходимыми. Многие пользователи действуют, не объявляя о завершении работы с сервером, и большинство из них прерывают свои соединения путем простого перехода на другой Web-сайт.

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

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

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

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

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

На самом нижнем уровне иерархии находится класс org.bsuir.diplom.client.transfer.TransferableData. Данный класс реализует интерфейс java.lang.Runnable, в методе run() которого происходит сам процесс загрузки данных.

Класс org.bsuir.diplom.client.transfer.TransferableData предоставляет набор методов, позволяющих начать загрузку, ожидать завершения, прервать загрузку и т.д.

Рис. 3.5. Механизм параллельной загрузки данных

Этот класс используется в классе, отвечающем за передачу набора объектов документов, -- org.bsuir.diplom.client.data.DataSet.TransferUnit,. Кроме того, объекты типа org.bsuir.diplom.client.data.DataSet.TransferUnit являются хранилищем уже загруженных наборов данных.

Общие управляющие функции по передаче удаленных данных выполняют объекты класса org.bsuir.diplom.client.data.DataSet именуемые виртуальными курсорами. Каждый виртуальный курсор содержит определенный список объектов типа org.bsuir.diplom.client.data.DataSet.TransferUnit, который (список) представляет собой кэш данных. Курсор является связующим звеном между визуальными элементами управления и удаленными данными. Объекты-курсоры загружают удаленные данные с сервера, а также передают внесенные изменения в обратном направлении.



3.1.4 Обработка событий в приложении

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

Применяемый метод нотификации является расширением модели делегирования событий, впервые появившийся JDK 1.1. Каждый компонент, заинтересованный в получении сообщений о состоянии передачи данных, реализует интерфейс java.awt.event.ActionListener и добавляет себя как получатель сообщений вызовом метода addActionListener().

В приложении существует три типа сообщений, управляющих его работой.

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

Ко второму типу относятся сообщения класса org.bsuir.diplom.client.transfer.TransferableData.Event, посылаемые потоком передачи данных с сервера. Методы объектов данного класса позволяют получить статус процесса передачи данных, а также возникшую при пересылке исключительную ситуацию или переданный документ. В конечном итоге данное сообщение попадает к виртуальному курсору.

Помимо изменения своего внутреннего состояния, задача виртуального курсора состоит в преобразовании полученного события данных в событие, адресованное компонентам. Это событие является конечной реакцией приложения на событие ввода пользователя (класс org.bsuir.diplom.client.data.DataSet.Event). В ответ на его получение визуальные компоненты изменяют свое представление, предоставляя пользователю полученные документы либо отображая код ошибки, возникшей при выполнении операции.

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

Сервлет приложения

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

Задача модуля диспетчеризации -- создать на основании данных запроса NVO и переадресовать его созданному объекту на выполнение. Кроме того, сервлет содержит список соединений пользователей к базе данных, поддерживаемых в отдельном состоянии в течении определенного времени. Это позволяет избежать лишних затрат на повторное открытие соединения при частых обращениях клиента к серверу. Информация о соединении используется при создании NVO.

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

Модуль нотификации и модуль безопасности работы апплета

Модуль нотификации в приложении состоит из трех частей. Две из них нельзя рассматривать отдельно друг от друга. Они составляют способ on-line нотификации клиента. Основная идея состоит в том, что база данных представляет собой сложный документ, редактируемый одновременно несколькими пользователями. Поэтому является важным предоставить механизм, позволяющий в определенной степени синхронизировать совместную работу (см. рис. 3.6).

Изменения данных, которые удовлетворяют определенным условиям фильтрации (например, изменение личной карточки студента, изменение оценки студента по определенному предмету, заполнение всех оценок студента), порождают в системе событие, которое должно быть разослано всем клиентам. NVO после обработки запроса добавляет сообщение в очередь сообщений модуля on-line нотификации сервера.

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

Рис. 3.6 Механизм нотификации пользователя об изменении данных

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

Работоспособность модуля приема on-line сообщений на стороне клиента тесно связана с привилегиями, предоставляемыми апплету. К сожалению, на сегодняшний момент нельзя предложить универсального решения проблемы предоставления привилегий апплету. Так, например, HotJava Browser позволяет редактировать расширенные права апплета непосредственно из команд своего меню.

Internet Explorer требует, чтобы все классы, входящие в апплет были заключены в архив специального формата -- CAB-файл (CABinet file). Кроме того, данный архив должен включать специальный файл деклараций, определяющий запрашиваемые полномочия, а также файл электронной подписи, подтверждающий источник происхождения апплета.

Netscape Navigator требует аналогичной последовательности действий с двумя оговорками. Во-первых, файлы должны быть упакованы в JAR-архив (формат, близкий к известному ZIP-архиву). Во-вторых, архив с апплетом должен содержать файлы Java-классов из специального пакета netscape.security, а апплет должен вызывать определенные методы объектов из данного пакета, запрашивающие необходимые привелегии.

Немаловажным будет подробнее рассмотреть файл электронной подписи. Как правило, для Internet-приложений такой файл необходимо получать от организации- гаранта, такой как VeriSign или BelSign. Однако процедура получения электронной подписи отнюдь не бесплатна. Для подписи коммерческого приложения, схожего с рассматриваемым, потребуется сумма, превышающая 800$. Это связано, прежде всего, с определенными обязательствами и риском, которые несет гарант.

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

создается электронный сертификат Вуза верхнего уровня, не имеющий гаранта;

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

апплет, входящий в приложение, подписывается данным сертификатом.

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

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

Оставшаяся для рассмотрения составляющая модуля нотификации -- модуль off-line нотификации. Его предназначение состоит в оповещении пользователей о значительных изменениях в базе данных. Такие изменения далее будем именовать задачами. К задачам относятся:

составление зачетной/экзаменационной ведомости;

заполнение зачетной/экзаменационной ведомости;

начало/окончание семестра.

В качестве механизма on-line нотификации используется электронная почта. Сообщения, оставляемые модулю off-line нотификации NVO представляют собой обычные электронные письма.

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

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

3.2 Администрирование базы данных

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

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

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

Задача составления зачетной/экзаменационной ведомости появляется при наступлении события «завершение семестра». При наступлении данного события администратор должен создать в базе данных представления, каждое из которых является запросом на выборку данных из таблиц студентов, семестров, отфильтрованным по группе студентов, семестру и предмету. После этого создаются хранимые процедуры, позволяющие добавлять, изменять, удалять записи. Причины, по которым необходимо использовать хранимые процедуры, обсуждаются ниже. Также администратор назначает исполнителя (в данном случае преподавателя, принимающего зачет/экзамен), который обладает правами на заполнение ведомости. Отметим, что таких исполнителей может быть несколько (фактически речь идет не о служебных обязанностях, а о правах доступа; очевидно, что изменять оценки студента могут сотрудники деканата в случае возникших ранее ошибок при вводе).

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

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

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

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

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

Третьим этапом администрирования является репликация данных. Репликация позволяет большему количеству пользователей войти в систему в одно и тоже время, при этом нагрузка распределена по различным серверам. В такой архитектуре несколько сайтов занимаются репликацией данных. Приложение Java пытается соединиться с одним из этих серверов репликаций. Если это не удается, оно может попробовать соединиться со следующим, и т.д. пока не произойдет соединение. С точки зрения программирования, приложение Java можно реализовать при помощи последовательных блоков попыток захвата, каждый из которых передает различный URL JDBC, используя метод java.sql.DriverManager.getConnection().

При трехуровневой архитектуре «клиент-сервер» за поиск наименее загруженного сервера СУБД отвечает серверная часть. Фактически каждый сервер должен выступать в качестве клиента СУБД, что ведет к нарушению идеологии архитектуры. Более правильный подход состоит в использовании архитектуры распределенных данных, что предполагает использование CORBA.

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

3.3 Разработка сервера электронной почты

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

3.3.1Основные принципы работы сервера электронной почты

Почтовый сервер представляет собой программное обеспечение, позволяющее клиентам (пользователям сервиса) иметь доступ к электронной почте в обоих направления. Как правило, компьютеры клиентов не могут быть постоянно включены, и поэтому не в состоянии сами принимать почту безотносительно ко времени ее отправки. Кроме того, пользователи могут не иметь доступа за пределами локальной сети предприятия или организации. Напротив, почтовый сервер всегда размещается на компьютере, имеющем постоянное подключение как к Intranet, так и к Internet. Помимо прочего, такие серверы имеют значительную вычислительную мощность и дисковое пространство, что позволяет им принимать сообщения для всех своих клиентов, а затем перенаправлять почту последним по мере обращения.

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

Сервер поддерживает два протокола:

протокол отправки сообщений SMTP (Simple Mail Transfer Protocol) [RFC 821];

протокол почтового отделения POP3 (Post Office Protocol version 3) [RFC 1939].

Поддержка протокола SMTP выполнена на расширенном уровне. Сервер реализует множество обязательных команд HELO (приветствие), MAIL (задание отправителя), RCPT (задание адресата), DATA (передача текста сообщения), RSET (сброс установок, сделанных командами MAIL и RCPT), NOOP (пустой оператор), QUIT (выход), а так же опциональные команды протокола VRFY (распознать пользователя), EXPN (предоставить всех получателей данного адреса). Команды, характерные для UNIX-систем (SEND -- переслать сообщение на терминал пользователя, SOML -- переслать или отправить по почте, SAML -- переслать и отправить по почте, TURN -- поменять ролями приложение-клиент и приложение-сервер) не включены в данную реализацию.

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

базовый; реализован парой командой POP3 пользователь/пароль (USER/PASS);

аутентификационный; реализован поддержкой команды APOP.

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

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

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

переключение между способами идентификации к POP3-серверу: USER/PASS и APOP;

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

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

Конфигурация сервера электронной почты

В общем случае конфигурация какого-либо параметра или пользователя заключается в изменении соответствующей записи в файле свойств. Файл конфигурации имеет расширение «.properties» и имя той сущности, свойство которой он описывает. Так, свойства POP3-сервера хранятся в файле «pop3.properties», свойства почтового ящика для пользователя «martin» -- в файле «martin.properties». Данный файл имеет формат, схожий с форматом ini-файлов Windows. Файл состоит из строк, каждая из которых представляет собой комбинацию «имя»=«значение». Если какя-либо строка начинается с «;», то оставшаяся часть строки рассматривается как комментарий.

Конфигурация SMTP-сервера

Для конфигурации SMTP используют следующие параметры файла smtp.properties:

Параметр пересылки сообщения на удаленный сервер -- «forward». Возможные значения: «true/false» или «yes/no» (по умолчанию -- «true»). Определяет возможность отправки через данный сервер сообщений для пользователей, не имеющих почтового ящика на данном сервере. Если значение равно «true» (или «yes»), cервер соединяется с хостом, на котором действительно находится почтовый ящик получателя (если он, конечно, вообще где-либо существует) и пересылает туда сообщение. Этот параметр является опциональным.

Каталог пользователей -- «users_dir». Возможные значения: имя каталога, где расположены почтовые ящики пользователей. Описание приведено ниже. Параметр должен либо отсутствовать вообще, либо ссылаться на каталог пользователей.

Конфигурация POP3-сервера

Для конфигурации POP3 используют следующие параметры файла pop3.properties:

Тип идентификации пользователя -- «use_apop». Возможные значения: «true/false» или «yes/no» (по умолчанию -- «false»). Если данный параметр установлен в значение «true» (или «yes»), то для идентификации к серверу клиенты должны использовать команду APOP, иначе -- пару команд USER/PASS. Наличие параметра необязательно.