Внедрения автоматизированной системы управления в делопроизводство организаций

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

Введение

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

В ходе выполнения заданий я рассмотрела следующие вопросы:

1. Проедпроектное исследование - цели, методики проведения.

2. Общие понятия о делопроизводстве.

3. Общие понятия о клиент-серверном приложении.

1. Предпроектое исследование

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

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

Разделение процесса разработки сложных программных приложений на отдельные этапы способствовало становлению концепции жизненного цикла программы. Жизненный цикл программного обеспечения - период разработки и эксплуатации программного обеспечения, в котором выделяют этапы (согласно стандарту ISO/IEC 12207):

· Анализа предметной области и формулировки требований к программе

· Проектирования структуры программы

· Реализации программы в кодах (собственно программирования)

· Внедрения программы

· Сопровождения программы

· Отказа от использования программы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Делопроизводство организаций

Определение делопроизводства по ГОСТу 16487-83 "Делопроизводство и архивное дело. Термины и определения":

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

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

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

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

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

Определение УСОРД по ГОСТ 6.10.1 -88 ( название ГОСТа).

Основания для разработки УСОРД, ее основная цель. Порядок применения и ведения УСОРД.

Определение УСОРД по ГОСТ 6.10.1 -88 " Унифицированная система документации, используемые в АСУ. Основные положения"

УСОРД - унифицированная система организационно-распорядительной документации.

АСУ - автоматизированная система управления.

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

Основные принципы и основания для разработки УСОРД являются:

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

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

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

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

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

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

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

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

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

3. Клиент-серверное приложение

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

Преимущества:

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

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

· Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т.п.

Недостатки:

· Неработоспособность сервера может сделать неработоспособной всю вычислительную сеть.

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

· Высокая стоимость оборудования.

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

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

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

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

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

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

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

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

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

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

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

Примерами сервером могут служить:

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

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

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

· файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций;

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

Сервер локальной сети предоставляет ресурсы (услуги) рабочим станциям и/или другим серверам.

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

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

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

Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).

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

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

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

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

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

Технология "клиент-сервер" применительно к СУБД сводится к разделению системы на две части - приложение-клиент (front-end) и сервер базы данных (back-end). Эта архитектура совмещает лучшие черты обработки данных на мэйнфреймах и технологии "файл-сервер". От мэйнфреймов технология "клиент-сервер" позаимствовала такие черты, как централизованное администрирование, безопасность, надежность. От технологии "файл-сервер" унаследованы низкая стоимость и возможность распределенной обработки данных, используя ресурсы компьютеров-клиентов. Сейчас графический интерфейс пользователя стал стандартом для систем "клиент-сервер". Кроме того, архитектура "клиент-сервер" значительно упрощает и ускоряет разработку приложений за счет того, что правила проверки целостности данных находятся на сервере. Неправильно работающее клиентское приложение не может привести к потере или искажению данных. Все эти возможности, ранее свойственные только сложным и дорогостоящим системам, сейчас доступны даже небольшим организациям. Стоимость оборудования, программного обеспечения и обслуживания для персональных компьютеров в десятки раз ниже, чем для мэйнфреймов.

Термин "сервер баз данных" обычно используют для обозначения всей СУБД, основанной на архитектуре "клиент-сервер", включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных.

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

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

Это язык по сути дела представляет собой текущий стандарт интерфейса СУБД в открытых системах. Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL.

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

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

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

Упоминавшиеся выше протоколы удаленного вызова процедур особенно важны в системах управления базами данных, основанных на архитектуре "клиент-сервер".

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

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

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

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

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

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

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

Многопоточная архитектура.

Эта архитектура использует только один исполняемый файл, с несколькими потоками исполнения. Главное преимущество - более скромные требования к оборудованию, чем для архитектуры с несколькими процессами. Здесь сервер берет на себя разделение времени между отдельными потоками, иногда давая преимущество некоторым задачам над другими. Кроме того, отпадает необходимость в сложном механизме взаимодействия процессов. По этой архитектуре построены MS SQL Server и Sybase SQL Server.

Трехуровневая архитектура "клиент-сервер".

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

· презентационная логика (Presentation Layer - PL), предназначенная для работы с данными пользователя;

· бизнес-логика (Business Layer - BL), предназначенная для проверки правильности данных, поддержки ссылочной целостности ..;

· логика доступа к ресурсам (Access Layer - AL), предназначенная для хранения данных;

Таким образом можно, можно придти к нескольким моделям клиент-серверного взаимодействия:

Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении как PL, так и BL, таким образом, обеспечивается полная децентрализация управления бизнес-логикой. Однако в случае необходимости выполнения каких-либо изменений в клиентском приложении придется менять исходный код. Серверная часть, при описанном подходе, представляет собой сервер баз данных, реализующий AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access.

Модель, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, поэтому клиент может довольствоваться довольно скромной аппаратной платформой, а сервер объединяет BL и AL. Максимальная загрузка сервера предусматривает выполнение бизнес-логики только с помощью хранимых процедур сервера (Хранимые процедуры - откомпилированные SQL-инструкции, хранящиеся на сервере). Это позволяет максимально централизовать контроль над данными и легко изменять правила работы сразу для целого предприятия. С другой стороны, незначительная корректировка правил, касающаяся только части пользователей, потребует длительной процедуры согласования. В этом случае невозможно реализовать какие-то исключения из общих правил для некоторых пользователей или приложений. В принципе, это хорошо и является залогом безопасности и целостности данных.

Модель с физически выделенным в отдельное приложение блоком BL, таким образом получаем трехуровневую архитектуру "клиент-сервер". На сервере БД может функционировать "универсальная" часть бизнес-логики (правила на уровне предприятия или группы связанных приложений). Такая схема позволяет поддерживать тонких клиентов на пользовательских компьютерах и в то же время разгрузить сервер БД от чрезмерной загрузки при сохранении гибкой системы работы с бизнес-правилами. В качестве промежуточного сервера может использоваться второй SQL-сервер, но чаще рациональней задействовать персональную СУБД, которая менее требовательна к аппаратным ресурсам и может обеспечить удобные средства построения и поддержки бизнес-логики.

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

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

Двухуровневая архитектура "клиент-сервер":

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

Трехуровневая архитектура "клиент-сервер":

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

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

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

Программы расширения серверной части:

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

Существует три категории расширений серверной части: с обычным CGI, с гибридным CGI и с API.

Список использованной литературы

1. А. Горев, С. Макашарипов, Ю. Владимиров "SQL Server 6.5 для профессионалов" изд. "Питер" Санкт-Петербург, 1998.

2. ГОСТ 6.10.1-80 "Унифицированне системы документации, используемые в АСУ. Основные положения"

3. "Архивы и делопроизводство" научно-практический иллюстрированный журнал №1(7), 2000

Размещено на Allbest.ru