Содержание к диссертации
Введение
Глава 1. Проектирование систем автоматизации процессов делопроизводства 10
1.1. Архитектура системы автоматизации процессов делопроизводства 10
1.2. Технология взаимодействия компонент системы автоматизации процессов делопроизводства 19
1.3. Принципы построения систем автоматизации процессов делопроизводства на основе технологии CORBA 26
Выводы: .40
Глава 2. Анализ параметров функционирования систем автоматизации процессов делопроизводства 42
2.1. Выбор показателей эффективности функционирования систем автоматизации процессов делопроизводства 42
2.2. Описание двухуровневой модели расчетов параметров функционирования систем автоматизации процессов делопроизводства47
2.3. Описание алгоритмов и методов решения задач статической и динамической оптимизации на уровне узла сети 51
2.4. Описание методов решения задачи по выбору архитектуры вычислительной сети на уровне сети 57
2.5. Описание методов решения задачи по анализу параметров функционирования вычислительной сети на уровне сети 67
Выводы: 75
Глава 3. Проектирование архитектуры САПД с использованием объектно-ориентированных технологий 76
3.1. Выбор первоначальной архитектуры САПД на уровне сети 76
3.1.1..Этап подготовки данных 77
3.1.2. Этап предварительной и заключительной обработки данных 79
3.1.3..Этап обучения сети 87
3.1.4.Этап диагностики 90
3.2. Определение степени влияния исходных параметров САПД на выбор архитектуры с целью корректировки первоначальных требований к этим параметрам 93
3.3. Анализ параметров функционирования вычислительной сети САПД на уровне сети 108
Выводы: 111
Глава 4. Разработка системы автоматизации процессов делопроизводства с использованием объектно-ориентированной технологии CORBA 112
4.1,. Задачи подлежащие решению в процессе разработки системы автоматизации процессов делопроизводства 112
4.2. Интеграция технологии CORBA и баз данных с целью организации доступа пользователей к документам и другим объектам системы автоматизации процессов делопроизводства 113
4.3. Обеспечение параллелизма в работе пользователей системы автоматизации процессов делопроизводства 118
4.4. Управление ресурсами серверов приложение системы автоматизации процессов делопроизводства 125
4.4.1.Управление памятью 125
4,4.2.Управление потоками 129
4.4.2.1.Отдельный поток для каждого соединения (Thread-per- session) 131
4.4.2.2.Пул потоков (Thread pooling) 132
4.4.3.Управление соединениями 133
4.5. Обеспечение масштабируемости 137
4.6. Обеспечение отказоустойчивости 147
Выводы: 159
Выводы по работе в целом 160
Заключение 161
Список литературы 163
Приложения , 166
- Архитектура системы автоматизации процессов делопроизводства
- Выбор показателей эффективности функционирования систем автоматизации процессов делопроизводства
- Этап предварительной и заключительной обработки данных
- Обеспечение параллелизма в работе пользователей системы автоматизации процессов делопроизводства
Введение к работе
В связи с тем, что гетерогенные компьютерные среды стали на сегодняшний день реальностью для многих организаций, повышаются требования к интеграции разнородных приложений в рамках единой корпоративной информационной системы (КИС), которая автоматизирует деятельность предприятия и функционирует в распределенной среде с поддержкой широкого диапазона платформ и сетей. К подобному классу систем относятся и системы автоматизации процессов делопроизводства (САПД). САПД позволяет организовать работу с документами, как с традиционными бумажными документами, реализуя функции ввода, хранения документов в электронном виде, поиска документов по любым критериям, в том числе, и по тексту документа, управления правами доступа к документам и функциям системы, аудита работы пользователей с отдельными документами, безопасности и т.д. Документы и инструменты управления документами (программные продукты различного функционального назначения) приобрели статус информационных ресурсов и концентрируются в рамках САПД. Объединение ресурсов на основе информационно-коммуникационного взаимодействия информационных систем (ИС) выводит их на уровень корпоративных информационных ресурсов и позволяет говорить о Едином Информационном Пространстве (ЕИП). Реализация ЕИП масштаба корпорации возможна при создании и последующем соблюдении международных стандартов на взаимодействие между собой как ИС, так и их отдельных компонентов.
К сожалению, в ряде случаев под информационными ресурсами понимают только данные, т.е. решение проблемы построения ЕИП сводится к организации доступа к удаленным базам данных. В результате понятие ЕИП сужается до понятия Единого Пространства Данных (ЕПД), а ИС выступают в роли клиента и сервера, взаимодействуя друг с другом по следующему сценарию. Информационная система-клиент (ИСК) посылает информационной системе-серверу (ИСС) запрос, получая в качестве результата данные, подлежащие дальнейшей обработке. В качестве языка запросов используется язык манипулирования данными (ЯМД), в роли которого может рассматриваться, например, Structured Query Language (SQL), выступающий как стандарт обращения к реляционным системам управления базами данных (СУБД). Дос-
5 туп к удаленным базам данных (БД) в большинстве случаев осуществляется с помощью общепринятых протоколов, например, с использованием протоколов Open DataBase Connectivity (ODBC), 3ava DataBase Connectivity (JDBC), либо с использованием шлюзов, поставляемые производителями СУБД или третьими фирмами-разработчиками. Фактически, при построении ЕПД используется архитектура доступа к удаленным данным, являющаяся аналогом двухуровневой архитектуры клиент-сервер. Эта архитектура предполагает реализацию на стороне клиента как функций ввода и отображения документов, так и чисто прикладных функций приложения, т.е. методов обработки отдельных документов. Клиент направляет запросы к серверу, который их обрабатывает и возвращает клиенту результат, оформленный как блок данных. Существенным недостатком рассмотренного сценария является дублирование приложений ИСС в ИСК, что приводит к неэффективному использованию ресурсов взаимодействующих ИС. Кроме того, на стороне ИСК необходимо знать особенности используемой СУБД и структуру удаленной БД ИСС САПД, что снижает уровень безопасности всей системы в целом. Затруднено сопровождение и модификация тех приложений ИСК, которые общаются с базами данных ИСС, т.к. любое изменение схемы удаленной БД САПД на стороне ИСС влечет за собой изменение приложений в ИСК, что усложняет обслуживание, обновление или замену приложений, установленных на десятках - сотнях компьютеров. Значительно усложняется администрирование БД ИСС, включающее управление правами доступа пользователей ИСК.
Рост популярности глобальной сети Internet и технологии World-Wide-Web (WWW) в последнее время вызывает повышенный интерес к ним со стороны разработчиков САПД. Изначально WWW создавался только как средство, предоставляющее графический интерфейс в Internet и упрощающее доступ к информации, распределенной по миллионам компьютеров во всем мире. При этом основными компонентами являлись броузеры Web и серверы Web. С использованием данного набора средств пользователям была предоставлена возможность навигации по Internet с использованием технологии гипертекста, поддерживаемой протоколом Hypertext Transfer Protocol (HTTP) и стандартом языка Hypertext Markup Language (HTML). Появление Common Gateway Interface (CGI) решило проблему обмена информацией между сервером Web и такими программами как базы данных, которые не могут непосредственно обмени-
ваться данными с браузерами Web. В результате появилась возможность реализации интерактивного взаимодействия конечного пользователя с программами на стороне Web-сервера, которые обрабатывали информацию, введенную пользователем в браузер, и в качестве результата возвращали сформированную HTML-страницу. Многие из существующих решений доступа к БД в среде Internet и основаны на данном подходе [31]. Однако возможности предоставляемые WWW-технологией, безусловно, расширили спектр решений, которыми руководствуются проектировщики при построении САПД, но не способны решить проблему построения ЕИП. Поскольку при рассмотрении взаимодействия ИС, ИСК с браузером выступает в роли компонента представления, а ИСС с WWW-сервером и приложениями выступает в роли компонента, реализующего бизнес-логику и логику доступа к данным, что, по сути, соответствует двухуровневой архитектуре с интеллектуальным сервером - архитектура сервера-приложений. Так, одним из недостатков, несомненно, является реальное отсутствие возможности реализации процесса обработки данных, поставляемых WWW-сервером, на стороне ИСК. Действительно, ИСК получает информацию от ИСС в виде HTML-страниц, что практически делает невозможным организацию процесса обработки полученных данных компонентами ИСК. Как следствие, это приводит к отсутствию требуемой эффективности использования вычислительных ресурсов ИС. С другой стороны, остро встает проблема поддержания безопасности системы в целом, которая в настоящий момент не имеет целостного решения в среде Internet, что не допустимо для организаций, выдвигающих повышенные требования к безопасности. И, наконец, как и в предыдущем подходе, существенно усложняется администрирование ресурсов ИСС, включающее управление правами доступа пользователей ИСС.
В отличие от рассмотренных подходов, в концепции ЕИП предусматривается, что в роли информационных ресурсов ИС могут выступать не только данные, но и различные приложения ИС. Тогда в каждой из ИС часть методов обработки данных реализуется в виде приложений, доступных из других ИС. Данный подход соответствует распределенной одноранговой архитектуре взаимодействия. Согласно этой архитектуре, любые приложения из различных ИС могут выступать как в роли клиента, так и в роли сервера по отношению друг к другу, совместно решая те или иные задачи. Такой подход минимизирует дублирование приложений. Распределение приложений по различ-
7 ным ИС позволяет добиться оптимального баланса загрузки приложений и аппаратных средств, и, следовательно, приводит к эффективному использованию информационных ресурсов систем в целом. Знание схемы базы данных необходимо только тому приложению, которое обрабатывает данные из этой базы данных. Использование ИСК сервисов, предоставляемых ИСС и реализующих методы обработки данных, позволяет решить проблему изменения схемы удаленной базы данных САПД. При этом статичность интерфейсов компонентов, предоставляющих ИСС набор сервисов, достигается путем применения методологий объектно-ориентированного анализа и проектирования, распределенных объектно-ориентированных технологий (Common Object Request Broker Architecture (CORBA), Distributed Common Object Model (DCOM), Enterprise Java Beans (EJB)) на различных этапах создания САПД [32]. И, наконец, так как в рамках конкретных ИС локализованы не только данные, но методы их обработки, происходит существенное уменьшение затрат на администрирование, сопровождение и модификацию ИС, составляющих ЕИП.
Однако, создание САПД связано со значительными материальными затратами, что определяет необходимость количественного обоснования принимаемых технических решений и требует рассмотрения широкого круга задач анализа и синтеза САПД и ее компонентов. Решение подобных задач основывается на измерениях либо моделировании функционирования исследуемой системы. Однако измерения можно осуществить лишь при наличии уже действующей системы либо ее аналога. На практике часто речь идет о разработке новой системы, не имеющей аналогов, так что моделирование является в таких условиях единственно возможным путем проведения необходимых количественных оценок. Наиболее важное при этом значение приобретают аналитические модели и методы, которые обладают большой гибкостью и удобством использования. Особенно удобен аналитический подход на начальных этапах создания системы, когда при невысокой точности и малом объеме исходных данных построение имитационных моделей отличается громоздкостью и трудоемкостью.
Поэтому в последние годы в связи с широким развертыванием практических работ в области проектирования КИС как у нас в стране, так и за рубежом особенно актуальной становится проблема аналитического моделирования процессов функционирования САПД в составе сетей ЭВМ и поиска оптимальных решений на различных этапах
8 проектирования и эксплуатации выделенного класса систем автоматизации. Однако имеющиеся по данной тематике работы в значительной степени разрознены и отражают, как правило, отдельные частные аспекты указанной проблематики. В связи с этим назрела необходимость в обобщении в рамках единой методики комплекса подходов и методов, позволяющих решать вопросы проектирования архитектуры САПД и проведения количественной оценки различных аспектов их функционирования.
Целью диссертационной работы является разработка методики проектирования и анализа параметров функционирования САПД, ориентированных на использование объектно-ориентированных технологий. Достижением цели диссертационной работы является решение следующих основных задач:
Исследование принципов построения САПД с использованием объектно-ориентированных технологий;
Разработка формализованной модели расчетов параметров функционирования выделенного класса систем автоматизации, ориентированных на использование объектно-ориентированных технологий;
Решение задачи по проектированию архитектуры САПД в рамках представленной формализованной модели расчетов с использованием нейросетевого подхода;
Исследование параметров функционирования САПД с использованием аппарата теории систем массового обслуживания для оценки показателей эффективности данного класса систем автоматизации.
Научная новизна. В диссертационной работе получены и выносятся на защиту следующие научные результаты:
Принципы решения задачи проектирования и анализа параметров функционирования САПД на основе использования двухуровневой модели расчетов;
Метод и алгоритм решения задачи проектирования архитектуры САПД с учетом зависимости между общей и частными задачами проектирования на основе использования нейросетевого подхода.
Принципы решения задачи проектирования и анализа параметров функционирования САПД легли в основу предлагаемой методики проектирования выделенного клас-
9 са систем автоматизации с использованием объектно-ориентированных технологий. Основными этапами методики являются следующие:
Анализ предметной области (выявление информационных потребностей объект автоматизации)
Проектирование САПД
Проектирование архитектуры САПД
Выбор технологии создания САПД
Выбор показателей эффективности функционирования САПД
3. Анализ параметров функционирования САПД в рамках двухуровневой моде
ли расчетов
3.1. Моделирование на уровне узла сети
3.1.1. Выбор архитектуры вычислительных узлов САПД
3.2. Моделирование на уровне сети
Выбор архитектуры вычислительной сети САПД
Анализ параметров функционирования вычислительной сети САПД
4. Разработка САПД
Проектирование структуры БД
Обеспечение параллелизма в работе пользователей
Обеспечение масштабируемости
Обеспечение отказоустойчивости
Управление ресурсами серверов приложений и т.д.
5. Определение и анализ полученного варианта проектного решения
Практическая ценность диссертационной работы заключается в следующем:
Представлена методика проектирования САПД с использованием объектно-ориентированной технологии CORBA (Common Object Request Broker Architecture).
Предлагаемая методика была использована для решения задачи проектирования архитектуры и исследованию параметров функционирования САПД на примере автоматизированной системы "Делопроизводства - М" Аппарата Правительства Российской Федерации.
Архитектура системы автоматизации процессов делопроизводства
Современные тенденции значительного роста объемов документооборота, необходимого для принятия управленческих решений, приводит к тому, что приходится получать, обрабатывать и хранить документы в большем количестве, чем раньше. Только своевременное получение необходимых данных и их анализ позволяют принять правильное решение. Традиционные методы работы с документами становятся при этом малоэффективными. Несомненно, что необходимым элементом организации коллективной работы с документами является единая корпоративная система управления делопроизводством в центре и на местах. В соответствии с ГОСТ Р51 141-98 ("Делопроизводство и архивное дело") под термином делопроизводство понимается отрасль деятельности, обеспечивающая документирование и организацию работы с официальными документами.
Обычно в организациях используется большое число фактографических баз данных (БД), содержащих значения реквизитов различных документов, а сами документы в традиционном бумажном виде собираются при этом в специальные хранилища (архивы). Оперативный поиск этих документов становится серьезной проблемой. Если же поддерживается БД электронных образов документов и она согласована с фактографической БД, хранящей реквизиты этих документов, то во многих случаях вместо извлечения исходного документа достаточно напечатать его электронный вид из БД электронных образов документов или просто просмотреть его на экране монитора. Согласование существующей фактографической БД и БД электронных образов документов позволяет поддерживать полный жизненный цикл документа в организации: создание - корректировка - утверждение - вступление в силу/исполнение - списание/передача в архив -хранение и обеспечение доступа к архивным данным. Использование единого информационного пространства на основе компьютерных сетей со скоростными каналами связи способно решить проблему взаимодействия всех структурных подразделений крупного территориально распределенного предприятия, имеющего многоуровневую структуру управления и сложные документолотоки. Основными частями системы работы с документами являются следующие
Система обработки документов Система обработки документов - является ядром САПД и используется для обеспечения работы с различными типами документов на различных этапах их жизненного цикла (получение, создание, регистрация, хранение и т.д.), а также организации индексирования документов для их дальнейшего быстрого поиска. Средства массового ввода документов - средства сканирования и распознавания образов документов, используются для организации обработки большого количества бумажных документов и перевода их в электронную форму, что указывает на то, что система масштабируема и способна работать как с одним бумажным документом, так и с 100 тысячами бумажных документов в день. Коммуникационные программы - средства передачи электронных документов с использованием средств электронной почты и факс-систем. Программы обработки документов - различного рода программы, используемые на предприятиях для создания, корректировки документов (текстовые процессоры, электронные таблицы и т.п.), тесно интегрированные с системой обработки документов. Средства администрирования - реализуют функции контроля доступа к документам и функции протоколирования работы пользователей с отдельными документами. В качестве основной причины для создания масштабируемых и отказоустойчивых САПД корпоративного масштаба может выступать необходимость создания надежной и доступной системы, обеспечивающую высокую производительность даже при использовании в глобальных сетях и работающую так, как этого ожидает пользователь, причем 24 часа в сутки, семь дней в неделю и 52 недели в году. Среди основных принципов построения современных САПД можно отметить следующие [27]: Открытость — обеспечение естественной расширяемости системы и ее интегрируемости, т.е. возможность добавления новых компонентов в уже существующую систему и возможность интеграции со смежными системами, а это станет возможным, если система будет обладать открытым программным интерфейсом. Кроме того, необходимо обеспечить поддержку различных аппаратных и программных платформ, что позволяет в случае резкого увеличения числа пользователей и, следовательно, нагрузки на систему перейти на более мощную аппаратную платформу. Модульность - система должна состоять из модулей, каждый из которых используется для решения конкретной задачи и, что самое главное они по возможности должны быть независимы друг от друга, при сохранении свойства глубокой интеграции между ними. Масштабируемость — система должна обеспечить работу как с одним пользователем, так и одновременно с 10 тыс. пользователей и более, как с 10, так и с 10 млн. документов. При увеличении нагрузки на систему должна быть предусмотрена возможность постепенного наращивания мощности системы интенсивным способом, т.е. не повышая мощности отдельного сервера, а увеличивая количество серверов на предприятии. Отказоустойчивость - обеспечение надлежащего уровня надежности функционирования, доступности системы для пользователя в случае сбоя в работе одного из компонентов или узлов системы. Согласно концепции построения ЕИП САПД должна состоять из набора взаимодействующих друг с другом программных компонент, взаимодействующих в рамках единой системы. В идеале интеграция программных компонент в САПД должна быть максимально простой, то есть подчиняться принципу "Plug and Play". Однако при разработ 13 ке САПД, часто не уделяют должного внимания этапам анализа предметной области, разработке и проектированию архитектуры системы, что в результате выражается в нежизнеспособности проектов создания систем автоматизации. За свой короткий жизненный цикл такие системы получили название "сгорающих систем" (stovepipe systems). Характерные черты таких систем (Например, САПД "Делопроизводства" Высшего Арбитражного суда, САПД "Контроль" Главного Контрольного управления, САПД "Дело" Аппарата Правительства Российской Федерации): монолитность, закрытость, трудоемкость внесения изменений, дорогостоящая поддержка, отсутствие документации. Кроме указанных недостатков можно отметить еще один неоспоримый факт существующих реализаций систем САПД. Он связан с тем, что в своем стремлении универсализировать построение систем автоматизации данного класса ряд компаний не учитывают особенности организации процессов делопроизводства, присущий отдельным организациям, что не позволяет их достаточно полно использовать или не использовать вообще в целях автоматизации процессов делопроизводства, принятых в организации.
Выбор показателей эффективности функционирования систем автоматизации процессов делопроизводства
САПД, как и любые сложные системы, предназначены для выполнения некоторого, обычно достаточно четко ограниченного набора работ, имеют вполне определенные цели и задачи по организации работы пользователей с документами и предназначены для удовлетворения потребностей пользователей в информационно-вычислительных работах (ИВР). При этом понятие ИВР может трактоваться достаточно широко, включая реализацию процедур сбора, обработки, накапливания и выдачи пользователям необходимой информации о хранящихся в системе документах и т.д. В этой связи качество санкционирования таких систем оценивается с помощью показателей эффективности, т.е. характеристик, определяющих степень приспособленности системы к решению возложенных на нее задач.
Показатель эффективности должен учитывать все основные особенности и свойства системы и условия ее функционирования, а следовательно должен зависеть в общем случае от параметров входящих потоков заявок на выполнение ИВР, характеристик выполняемых ИВР, и структуры и параметров вычислительных мощностей и системы передачи данных, а также параметров характеризующих воздействия внешней среды, например, выход из строя технических средств системы. Таким образом, показатель эффективности функционирования САПД в общем случае может быть представлен в виде некоторой зависимости типа [3]: множество параметров входящего в систему потока заявок на выполнение ИВР (число и интенсивности составляющих поток заявок разных классов, типы и параметры законов распределения интервалов времени между моментами поступления различных заявок, допустимые времена ожидания для различных пользователей и т.п.); M - множество параметров, характеризующих отдельные ИВР, связанные с реализацией заявок соответствующих классов, и определяющих потребные затраты ресурсов системы для выполнения этих ИВР (затраты памяти, времени обработки запроса процессорами, внешними устройствами, каналами передачи данных и т.п.); S — множество системных параметров, определяющих структуру СВС, СПД, характеристики технических и программных средств и т.п.; множество параметров/ характеризующих воздействия внешней среды посредством задания выхода из строя компонент системы под воздействием внешних факторов.
Функционирование САПД связано с реализацией совокупности взаимодействующих процессов передачи и обработки информации по хранящимся в системе документам, т.е. определяется совокупностью взаимодействующих информационных процессов (ИП). Категория ИП определяется формальным образом в виде последовательности этапов передачи и обработки информации на средствах сети ЭВМ, инициируемой при реализации заявки пользователя на выполнение запрашиваемых от сети информационно-вычислительных работ, связанных с обработкой запросов над отдельным документом или некоторой совокупностью документов [2]. Например, в качестве подобных информационных процессов могут рассматриваться операции регистрации документа, модификация реквизитов документа в его регистрационной карточке, модификация текста документа. При этом элементы множеств Л и М позволяют определять для каждого заданного набора параметров S параметры отдельных ИП, рассматриваемая их изолированно, а элементы S и V могут быть использованы для характеристики взаимодействия ИП при их совместной реализации в реальной системе. Отсюда следует, что оценка качества функционирования САПД может быть сведена к оценке качества организации всех ИП, реализуемых в системе в целом.
При выборе показателей эффективности сложных систем, таких как САПД, работающих в условиях воздействия случайных факторов, обычно используют средние значения соответствующих функционалов, либо вероятностями некоторых случайных событий. В качестве таких параметров эффективности могут рассматриваться, например: среднее время цикла обработки заявки пользователя в системе, определяемое как временной интервал, начинающийся с момента поступления запроса в систему и завершающийся мо 44
ментом времени получения результатов ИВР пользователем; вероятность доведения информации за время, не превышающее заданного и т.п. Часто при оценке качества функционирования системы применяют показатели, не являющиеся показателями эффективности, а характеризующие степень использования отдельных элементов системы (например, канала передачи данных, отдельных вычислительных машин и т.д.). Подобные показатели весьма удобны при анализе системы для выявления "узких мест" и изыскания возможностей для перераспределения нагрузки в системе. Подобные показатели рассчитываются по результатам анализа заданной совокупности ИП и алгоритмов управления ИП и позволяют определить потоки запросов на использование каждого элемента системы, а, следовательно, вычислить его загрузку, пропускную способность и т. д.
Для сложных систем, как САПД, практически невозможно выделить единственный показатель эффективности, позволяющий охарактеризовать все интересующие аспекты функционирования системы [22]. В этой связи мы будем рассматривать некоторую совокупность показателей эффективности, каждый из которых характеризует степень достижения системой некоторой частной цели. При этом частные цели и соответствующие показатели эффективности должны быть согласованы в системном плане, т.е. достижение частной цели должно способствовать выполнению основной задачи системы. Любой частный показатель, являющийся характеристикой некоторых аспектов функционирования САПД, может быть рассчитан по результатам анализа совокупности взаимодействующих ИП, отображающих процесс функционирования системы.
Этап предварительной и заключительной обработки данных
Для решения задачи с использованием нейронных сетей необходимо собрать данные для обучения. Обучающие данные представляют собой ряд наблюдений, для которых указаны значения входных и выходных переменных. Входные и выходные переменные определяются исходя из эвристических знаний характерных для области, связанной с делопроизводством. В качестве входных переменных, определяющих число нейронов во входном слое нейронной сети, для настоящей задачи исследования были выбраны следующие: 1. стоимость; 2. количество ЭВМ в сети; 3. возможность будущего расширения САПД; 4. возможность стыковки с другими КИС; 5. сложность установки САПД; 6. возможность динамической реконфигурации САПД; 7. требования к администрированию САПД; 8. возможность использования различных ОС; 9. поддержка ОС предыдущих версий; 10. требования к секретности информации САПД; 11. требован ия к отказоустойчи восги САПД; 12. простота изменения конфигурации; 13. поддержка сети Internet в САПД; 14. требуемая скорость передачи данных; 15. количество документов САПД; 16. максимальная длина сегмента. Количество выходных переменных зависит от количества вариантов решения конкретной частной задачи исследования. В скобках напротив каждого варианта решения указывается кодировка выходного сигнала при его представлении в обучающем множестве. В случае решения частной задачи по выбору ранга сети количество выходных переменных равно трем и каждая переменная соответствует одному из следующих решений указанной задачи: 1. Одноранговая сеть (0); 2. Сеть с выделенным сервером (1); 3. Комбинированная (2). Применительно к задаче по выбору топологии сети количество выходных переменных равно пяти и каждая выходная переменная соответствует одному из следующих решений указанной задачи: 1. Шина (0); 2. Звезда (1); 3. Кольцо (2); 4. Звезда + шина (3); 5. Звезда + кольцо (4). В случае решения задачи по выбору среды передачи данных количество переменных в выходном слое равно пяти и каждая выходная переменная соответствует одному из следующих решений указанной задачи: 1. 100BaseX (0); 2. 100Base4 (1); 3. 100Base-FX (2); 4. 100VG-AnyLAN (3); 5. FDDI (4). При решении задачи по выбору объектно-ориентированной технологии разработки САПД количество нейронов в выходном слое равно трем и каждый из них соответствует одному из следующих решений данной частной задачи исследования: 1. СОМ/СОМ+ (0); 2. CORBA (1); 3. FJB (2). Для решения каждой частной задачи исследования в работе используется отдельная нейронная сеть, которая обучается на примерах, взятых из обучающего множества. Обучающее множество представляют собой экспертные оценки в области делопроизводства и получены из таких информационных источников (периодические издания) как Data Communication International, Сети, LAN, Мир ПК, Открытые системы, а также Центра нейро-информационных технологий А.И. Галушкина. Вопрос о том, сколько наблюдений нужно иметь для обучения сети, часто оказывается непростым. Известен ряд эвристических правил, увязывающих число необходимых наблюдений с размерами сети. В частности в книге Каллана [17] используется результат работ Баума и Хасслера, дающий общие рекомендации относительно размера набора обучающих данных. Рекомендуется выполнение следующего неравенства: N - общее число обучающих образцов; W число весовых коэффициентов в сети; є - доля ошибок, допустимая в ходе обучения. Так при допустимых 10% ошибок число обучающих образцов должно быть в 10 раз больше числа имеющихся в сети весовых коэффициентов. Количество наблюдений, которые будут использоваться для обучения каждой нейронной сети при решении частных задач исследования равно 380. Несколько примеров обучающего множества для задачи по выбору ранга сети представлены в приложении (см. Таблица 49). Для организации независимого контроля процесса обучения и определения момента его "ранней остановки" при обучении используется еще и контрольный набор данных с 40 примерами в каждом наборе применительно к каждой отдельной частной задачи исследования. После завершения процесса обучения каждая нейронная сеть тестируется на отдельно взятом примере из тестового набора данных. После получения решений на базе нейронных сетей, соответствующих частным задачам исследования, формируется решение общей задачи, которое и выступает в качестве варианта проектного решения по выбору архитектуры САПД АП РФ.Поскольку нейронная сеть обрабатывается только числовые данные, а исходные данные, подаваемые на нейронную сеть, могут включать номинальные переменные, указывающие на принадлежность к одному из нескольких классов, даты, целочисленные значения, текстовые строки, графические данные и т.д., то возникает необходимость в рассмотрении процедуры, связанной с кодированием данных, являющейся составной частью этапа предварительной и заключительной обработки данных. Для представления данных различных типов в ИНС используются шкалы различных типов [8]. В настоящей научной работе будут использоваться следующие способы кодирования:
Обеспечение параллелизма в работе пользователей системы автоматизации процессов делопроизводства
При работе с электронными документами САПД очень важно обеспечить возможность работы с ними одновременно нескольким клиентам, нескольким пользователям системы. Для реализации данной возможности используется концепция сеансов [32]. Термин сеанс часто относится к ситуациям, в которых пользователь просматривает реквизиты и текст документа и вносит в них изменения. Сеансы работы пользователей с базами данных, во время которых пользователи вводят определенные данные, с точки зрения транзакций очень сложны. Проблема состоит в том, что пользователю на ввод данных требуется достаточно времени. Транзакции, как правило, классифицируются на коротко- и дол-гоживущие. Многие транзакции в системе являются короткоживущими. В противном случае мы имеем дело с долгоживущими транзакциями. Транзакции, требующие ввода данных со стороны пользователя, являются самыми сложными, так как нельзя точно предсказать, сколько времени потребуется пользователю на ввод данных. Таким образом, мы имеем дело с двумя видами долгоживущих транзакций - транзакциями долгоживущими, потому что они выполняют чрезвычайно сложные запросы и обновления, и транзакциями потенциально долгоживущими, так как они требуют ввода данных пользователя. Если простые транзакции выполняются за доли секунды, время жизни долгоживущих транзакций может измеряться часами.
Продолжительность транзакции оказывает немалое влияние на характер поведения системы. Двумя важными проблемами, связанными с длительностью транзакций являются параллелизм в работе пользователей системы и использование ресурсов базы данных. С точки зрения параллелизма проблема состоит в том, что чем дольше выполняется транзакция, тем больше вероятность того, что она пересечется с другой транзакцией. И что еще хуже, долгоживущая транзакция может заблокировать другую транзакцию, которая даже не пытается получить доступ к тем же самым логическим данным. Помимо проблем, связанных с параллелизмом, проблема, связанная с долгоживущими транзакциями существует и на уровне базы данных. Базы данных должны создавать "снимки" данных, к которым происходит доступ во время долговременных транзакций. В течение длительного времени это приводит к определенным проблемам. Размеры журналов, которые ведет база данных, могут возрасти до невероятных размеров; кроме того, сервер базы данных может использовать очень большой объем памяти.
Использование транзакций управляемые клиентами с помощью службы транзакций - OTS - предполагает тесную связь между сеансами и транзакциями [34]. Это приводит к проблемам параллелизма в использовании ресурсов, связанных с долгоживущей природой сеансов. Подход, основанный на использовании OTS, оправдан только в том случае, если будет найдено подходящее решение указанных проблем. Для решения двух указанных проблем можно реализовать механизм оптимистического управления параллелизмом поверх пессимистического управления транзакциями базы данных с помощью отделения сеансов от транзакций базы данных, реализуя управление сеансами на уровне приложений [30]. Этот механизм предполагает использование транзакций, управляемых сервером приложений. Пессимистическое управление транзакциями базы данных предусматривает перед предоставлением доступа к данным осуществить проверку на предмет блокировки элемента данных. При реализации оптимистического управления параллелизмом все обновление базы данных откладывается до конца транзакции. Это означает, что все обновления во время выполнения транзакции применяются к временным копиям элементов данных. По окончанию выполнения транзакции осуществляется проверка конфликта с другими транзакциями. Выполнение транзакции состоит из трех фаз: Фаза чтения. Во время первой фазы предоставляется доступ к данным с правом только чтения. Все обновления применяются к временным копиям элементов данных. Фаза подтверждения. Во время фазы подтверждения определяются конфликты с другими транзакциями. Фаза записи. Если никаких конфликтов не обнаружено, обновления, которые применялись к временным копиям, теперь применяются к реальным элементам базы данных. В случае обнаружения конфликта все изменения игнорируются, и транзакция прерывается. Это может привести к повторному запуску транзакции. При использовании оптимистического управления параллелизмом все проверки откладываются до фазы подтверждения, после чего они выполняются одновременно. Откладывание подтверждения до конца транзакции позволяет эффективно сократить время, в течение которого транзакция блокирует данные. Однако многие СУБД не обеспечивают прямой поддержки оптимистической блокировки. Для этого все три рассмотренные фазы необходимо реализовать на уровне приложения [30, 42]. На фазе чтения приложение считывает данные, снимая блокировку. Изменения применяются к локальным копиям в памяти. На фазе подтверждения, данные повторно считываются, из базы данных, на этот раз со всем блокировками. Если на этой 4 азе не было обнаружено никаких конфликтов, изменения вносятся в базу данных, после чего транзакция фиксируется. Предложенный механизм позволяет реализовать оптимистический подход с помощью СУБД, которая оптимистическую блокировку явно не поддерживает и ее необходимо реализовать на уровне приложения. В этой ситуации фазы чтения, подтверждения и записи не реализуются од 120 ной и той же транзакцией, вместо чего используется несколько независимых транзакций, а сеанс работы пользователя тем самым реализуется в виде последовательности транзакций только чтения, за которой следует транзакция обновления.
В САПД, как правило, необходимо обеспечить работу нескольких пользователей с различными типами документов. Для обеспечения возможности одновременной работы пользователей с документами в системах автоматизации выделенного класса предлагается использовать концепцию сеанса редактирования. Для сеансов редактирования выбирается стратегия оптимистичного управления параллелизмом. В одном и том же сеансе редактирования могут принимать участие несколько пользователей. Для того чтобы вносить изменения в документ, пользователь должен еойти в сеанс. Если в данный момент сеанс редактирования для определенного документа отсутствует, система создаст новый сеанс и загружает текущую версию документа из базы данных в созданный для данного документа на сервере приложения CORBA-объект. Другие пользователи могут участвовать в сеансе редактирования, проведя сеанс входа. Всегда существует только одна рабочая версия определенного документа - пользователи могут параллельно работать с одним и тем же документом, Пользователи свидетельствуют о завершении внесения изменений, вызывая сеанс выхода. Только в том в случае, если пользователи, прошедшие через сеанс входа, вызвали соответствующие сеансы выхода, все внесенные изменения подтверждаются, и они переносятся в исходную базу.
