91

Компьютерная система управления документооборотом предприятия Черниговгазмонтаж

Дипломная

Информатика, кибернетика и программирование

Необходимость внедрения систем электронного документооборота (Document Management System). Выбор технических средств построения системы. Диаграмма сервисов серверного приложения. Общие положения к организации работы с визуальными дисплеями и терминалами персональных компьютеров (ВДТПК).

Русский

2012-11-14

3.66 MB

252 чел.

Министерство образования и науки, молодежи и спорта Украины

Черниговский государственный технологический университет

Кафедра информационных и компьютерных систем

УТВЕРЖДАЮ

Зав. кафедрой ИКС

д.т.н., профессор

 В.В. Казимир

  “____” ___________201___г.

Компьютерная система управления документооборотом предприятия Черниговгазмонтаж

Квалификационная работа специалиста по специальности 7.091501 “Компьютерные системы и сети”

Исполнитель           студент гр. КС-072

                                   А.В. Примаков

Руководитель        доцент

                                   Д.О. Ульченко

Консультанты по разделам

Разработка аппаратной подсистемы доцент

                                Д.О. Ульченко

Охрана труда и окружающей среды к.ф.-м.н., доцент

                                Е.В. Никитенко

Нормоконтролер                                    к.т.н., доцент

                                С.А. Нестеренко

Чернигов 2012


ТЕХНИЧЕСКОЕ ЗАДАНИЕ

на выполнение квалификационной работы специалиста

Примаков А.В., гр. КС-072

Тема работы: КОМПЬЮТЕРНАЯ СИСТЕМА УПРАВЛЕНИЯ ДОКУМЕНТООБОРОТОМ предприятия Черниговгазмонтаж

Предполагаемые технические и эксплуатационные результаты работы

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

Система должна обеспечить следующую функциональность:

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

Разработать локальную вычислительную сеть для предприятия «Черниговгазмонтаж », состоящею из 45 компьютеров. Локальная сеть должна быть разбита на 7 сегментов и обеспечивать:

  •  скорость передачи информации 100 и 1000 Мбит/сек;
  •  беспроводной доступ к сетевым ресурсам;
  •  предоставлять сервис ip-телефонии;
  •  безопасный доступ к Интернету для сотрудников фирмы;
  •  обмен файлами между компьютерами и доступ к общим сетевым ресурсам фирмы;
  •  защиту от несанкционированного доступа;
  •  разделение сети на сегменты.

Объем текстовой и графической документации

Работа   объемом   120 – 140   с.   формата   А4.

Предполагаемая трудоемкость работы – 1000 чел-часов.

Плановый срок защиты работы

Работа планируется к защите на заседании ГЭК.

Руководитель работы и консультанты по разделам

Руководитель работы и консультант по аппаратной части – доцент Ульченко Д.О., консультант по охране труда – доц. к.ф.-м.н., Никитенко Е.В..

Исполнитель работы       Примаков А.В.

Руководитель работы       Ульченко Д.О. 

Дата выдачи задания

«__»________ 2012 г.

 


РЕФЕРАТ

Квалификационная работа специалиста,  121 с., 46  рис.,  18 табл.

Объект разработки – компьютерная система управления документооборотом.

Цель разработки – создание компьютерной системы  управления документооборотом  (Document Management System). Компьютерная система позволяет: вести учет имеющейся документации, а именно добавлять, удалять, редактировать файлы и каталоги; получить  доступ конкретному пользователю к общедоступной документации; создавать шаблоны, а также документы на их основе и версии документов; учитывать все версии документов;  обеспечивать целостность всех данных и быстрый индексированный поиск; задавать права доступа для всех видов документов с возможностью предварительного ознакомления. Предусмотрена возможность удобного просмотра общедоступных документов, используя веб-интерфейс.  

Основной метод проектирования – нисходящее структурное проектирование.

В ходе разработки:

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

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

КОМПЬЮТЕРНАЯ СИСТЕМА, DATABASE, SQL, MySQL, JAVA, СУБД, КЛИЕНТ-СЕРВЕР, РАСПРЕДЕЛЕННАЯ СИСТЕМА, ВЕБ-ИНТЕРФЕЙС


ABSTRACT

Qualifying work specialist, 121., 46 fig., 18 table.

Object design – Computer Document Management System.
The purpose of development – the creation of a computer document management system (Document Management System). The computer system allows you to: keep track of the available documentation, namely, to add, delete, edit files and directories, have access to a specific user to a public document, create templates and documents based on them, and versions of documents, take into account all the versions of documents , to ensure the integrity of all data and fast indexed search, set permissions for all types of documents with the ability to preview. You can conveniently view the publicly available documents, using the web interface.

The main method of design – Descending structural design.
In the course of development:

  •  analysis of existing methods for constructing computer systems of electronic document;
  •  the requirements to document management computer system;
  •  architecture developed by the CS document management;
  •  the structure of a computer document management system;
  •  developed a Local Area Network.

Further development is possible in the direction of improving the functionality and speed of operation due to the optimization algorithm processing.

COMPUTER SYSTEM, DATABASE, SQL, MYSQL, JAVA, database, client-server, distributed systems, Web-based interface


РЕФЕРАТ

Кваліфікаційна робота спеціаліста, 121 с., 46 рис., 18 табл.

Об'єкт розробки – комп'ютерна система управління документообігом.
Мета розробки – створення комп'ютерної системи управління документообігом (Document Management System). Комп'ютерна система дозволяє: вести облік наявної документації, а саме додавати, видаляти, редагувати файли і каталоги; отримати доступ конкретному користувачеві до загальнодоступної документації; створювати шаблони, а також документи на їх основі і версії документів; враховувати всі версії документів; забезпечувати цілісність всіх даних і швидкий індексований пошук; задавати права доступу для всіх видів документів з можливістю попереднього ознайомлення. Передбачена можливість зручного перегляду загальнодоступних документів, використовуючи веб-інтерфейс.
Основний метод проектування – спадний структурний проектування.
У ході розробки:

  •  проведено аналіз методів побудови існуючих комп'ютерних систем електронного документообігу;
  •  сформульовано вимоги до комп'ютерної системи управління документообігом;
  •  розроблена архітектура КС управління документообігом;
  •  розроблена структура комп'ютерної системи управління документообігом;
  •  розроблена локальна обчислювальна мережа.

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


КОМП'ЮТЕРНА СИСТЕМА, DATABASE, SQL, MYSQL, JAVA, СУБД, КЛІЄНТ-СЕРВЕР, розподілені системи, ВЕБ-ІНТЕРФЕЙС


СОДЕРЖАНИЕ

ВВЕДЕНИЕ 10

1 Анализ Задачи создания системы. Электронный документооборот 11

1.1 Анализ предметной области 11

1.1.1 Необходимость внедрения систем электронного документооборота 11

1.1.2 Основные задачи СУД 12

1.1.3 Системы управления документооборотом 12

1.1.4 Построение базовой модели предметной области 13

1.1.5 Анализ существующих систем управления документооборотом 15

1.1.6 Система управления документооборотом (Document Management System) 15

1.1.7 Hummingbird DM 15

1.1.8 NetDocuments 17

1.1.9 Inforouter 18

1.1.10 Сравнительный анализ существующих систем 19

1.1.11 Вывод 20

1.2 Требования к программной подсистеме 21

1.3 Требования к графическому интерфейсу 25

1.4 Анализ требований к аппаратной подсистеме 26

1.5 Постановка задачи на разработку системы 28

1.5.1 Общие требования к разрабатываемой системе 28

1.5.2 Выводы 31

2 Разработка кс Управления документооборотом 32

2.1 Выбор технических средств построения системы 32

2.1.1 Выбор языка реализации системы 32

2.1.2 Выбор технологий реализации 33

2.1.3 Выбор СУБД 38

2.1.4 Выбор элементной базы для ЛВС 43

2.1.5 Выводы 47

2.2 Разработка архитектура ИКС 48

2.3 Разработка структуры программной подсистемы 50

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

2.5 Диаграмма классов домена серверного приложения 55

2.6 Диаграмма сервисов серверного приложения 56

2.7 Разработка WEB-компонента системы 59

2.7.1 Разработка эскиза интерфейса пользователя 60

2.7.2 Разработка сценария использования интерфейса 63

2.7.3 Разработка карты сайта 64

2.8 Разработка аппаратной подсистемы 65

2.8.1 Проектирование архитектуры ЛВС 65

2.8.2 Разделение сети на сегменты и размещение серверов 68

2.8.3 Выбор сетевого оборудования 70

2.8.4 Моделирование ЛВС 78

3 Реализация системы 89

3.1 Результат реализации базы данных 89

3.2 Диаграмма пакетов 91

3.3 Протоколы классов 92

3.4 Диаграмма развертывания ИКС 102

3.5 Реализация интерфейса пользователя 103

4 Охрана труда 108

4.1 Общие положения к организации работы с визуальными дисплеями и терминалами персональных компьютеров (ВДТПК) 108

4.2 Требования к производственным и лабораторным помещениям для эксплуатации ВДТ ПК 109

4.3 Гигиенические требования к параметрам производственной среды в помещениях с ВДТ ПК 110

4.4 Микроклимат 110

4.5 Освещение 111

4.6 Неионизирующие электромагнитные излучения 112

4.7 Пожарная безопасность 113

4.8 Санитарные требования к организации и оборудованию рабочих мест с ВДТ ПК 114

4.9 Требования к режимам работы и отдыха при работе с ВДТ ПК 115

4.10 Расчет инженерной задачи 116

Выводы 118

Перечень использованных источников 119


ВВЕДЕНИЕ

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

За время развития IT индустрии были созданы различные программы для работы с электронными документами[1]. Их основными функциями являются:

  •  сохранение документов;
  •  хранение версий;
  •  интеграция с современными офисными пакетами;
  •  генерация отчетов и ведение статистики.

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

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

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


  1.  Анализ Задачи создания системы. Электронный документооборот
    1.  Анализ предметной области
      1.  Необходимость внедрения систем электронного документооборота

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

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

Внедрение системы электронного документооборота позволяет решить эти проблемы, а также:

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

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

  1.   Основные задачи СУД

Основными задачами систем управления документооборотом являются[3]:

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

Внедрение корпоративных СУД дает организациям два типа преимуществ: тактические и стратегические[4].

Тактические преимущества:

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

Стратегические преимущества:

  •  улучшение в доступе к информации;
  •  улучшение в скорости реагирования;
  •  улучшение в контролируемости процессов;
  •  более быстрое и качественное принятие решений;
  •  усиление степени контроля со стороны руководства.
    1.  Системы управления документооборотом

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

Современная система электронного документооборота должна быть:

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

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

Сущность «Пользователь» – это сущность, содержащая информацию о пользователе системы: данные аутентификации (логин, пароль), имя и фамилия пользователя, адрес пользователя и телефон, подразделении, e-mail адрес, роль (пользователь, администратор).

Данные аутентификации удобно хранить в отдельной сущности. Таким образом, сущность будет содержать ссылки на сущности: данные аутентификации, роль, ФИО и адрес.

По роли пользователя определяются основные возможности взаимодействия в системе.

Сущность «Библиотека» – это сущность, содержащая всю необходимую информацию о пользовательской библиотеке: дата создания, название, описание библиотеки, владелец библиотеки.

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

Сущность «Папка» предназначена для представления пользовательских документов в упорядоченном виде.

Информация о папке: дата создания, название, описание папки, владелец папки, тип хранимого документа (либо документ, либо шаблон документа).

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

Сущность «Документ» содержит информацию о документе: название документа, дата создания, версия документа, описание, создатель документа.

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

Сущность «Шаблон» содержит информацию о шаблоне создания документа: название шаблона, дата создания, описание, создатель документа.

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

Как видно с рисунка 1.1 между сущностями присутствуют отношения «один к одному», «один ко многим» и «многие ко многим».

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

У пользователя может быть только одна роль и только одни личные данные, поэтому между сущностями «ФИО» и «Пользователь», «Роль» и «Пользователь», «Данные аутентификации» и «Пользователь», «Адресс» и «Пользователь» реализовано отношение «один к одному».  

Между сущностями «Библиотека» и «Папка» организовано отношение «один ко многим».

Сущность «Папка» может хранить ссылки как на сущности «Документ», так и на «Шаблон», потому между ними реализованы связи «один ко многим».

Рисунок 1.1 – Концептуальная модель предметной области

  1.  Анализ существующих систем управления документооборотом

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

  1.  Система управления документооборотом (Document Management System)

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

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

  1.  Hummingbird DM

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

Функциональный пользовательский интерфейс: Hummingbird DM обладает стандартным функциональным интерфейсом Windows, обеспечивая иерархическое представление содержимого и поддержку операций "drag and drop". Подключаемые модули Hummingbird DM Extensions позволяют максимально полно использовать возможности продукта без дополнительного обучения, т.к. предполагают работу с уже знакомыми интерфейсами: Windows Desktop, Windows Explorer, Microsoft Outlook и другими.

Масштабируемость DM Engine: Hummingbird DM Server – это высокопроизводительная, многопоточная платформа, которая соединяет репозитории DM с удаленными филиалами компании. Системные функции устойчивости к сбоям и балансировки нагрузки обеспечивают сохранность и доступность данных, а сжатие документов увеличивает производительность системы во время передачи данных.

Прогрессивная технология поиска: Индексирование и поиск по содержимому производится с помощью встроенного модуля Hummingbird SearchServer™, который упрощает обычный и сложный поиск. DM Indexer позволяет создавать множественные индексы на 15 различных языках для использования в тех случаях, когда первичный индекс недоступен, или для распределения загрузки на сервер. Существует возможность комбинации одновременного и глобального поиска по корпоративным файлам и метаданным SQL для получения списка интуитивно понятных и консолидированных результатов поиска.

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

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

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

Гладкая интеграция с другими решениями Hummingbird: Репозитории Hummingbird DM могут быть проиндексированы и категоризированы с помощью Hummingbird KM, что позволит находить как структурированные, так и неструктурированные данные. Hummingbird Portal предоставляет доступ ко всем корпоративным ресурсам и приложениям через настраиваемую с учетом пожеланий пользователя среду. Кроме того, заказчикам предлагается пакет решений, расширяющий и дополняющий систему управления документами Hummingbird DM: Hummingbird Collaboration, Hummingbird Web Publishing, Hummingbird DM WorkFlow, Hummingbird Imaging и Hummingbird AutoCAD Extention.

  1.  NetDocuments

NetDocuments позволяет совершать свободный доступ и работу над документами в любом месте: создавать, редактировать и обмениваться ними  с другими пользователями, совершать поиск Word-, Excel-, PowerPoint- и PDF-документов и электронных писем. Все данные хранятся в защищенных датацентрах[7].

Включает в себя все основные особенности DMS: глобальный доступ с любого места, подключенного к Интернету, включая мобильные устройства. Доступны In-Out параллельный контроль, контроль версий, настраиваемое профилирование, истории, права, поиск по всему тексту и поиск по профилю, навигационные папки, недавно открытые / редактируемые / добавленные списки и т.д.

Matter-Centric Workspaces – поддержка автоматической иерархической струтуры папок на основе шаблонов: доступен поиск в папках, открытие доступа другим пользователям, Drag and drop  поддержка содержимого папок.

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

Возможность настроить собственную страничку, на которой можно разместить ссылки на нужные документы, а так же интернет-ресурсы

Управление электронной почтой – возможна настройка MS Outlook для отображения папок и их содержимого. Электронная почта NetDocuments поддерживает MS Outlook, Lotus Notes и Novell GroupWise.

Мобильный доступ – доступ: просмотр, поиск и добавление своих документов используя КПК и смартфоны.

Особенности NetDocuments, связанные с администрированием:

  •  поддержка Active Directory аутентификации;
  •  интеграция в MS Office;
  •  управление правами доступа к ресурсам;
  •  управление правами доступа пользователей;
  •  поддержка SOAP-based веб-сервисов, это упрощает работу разработчиков, занимающихся интеграцией NetDocs в свих приложениях;
  •  возможность установить свою Policy при работе с документами, например, добавить исключения.
    1.  Inforouter

Ниже будут рассмотрены основные особенности Inforouter DMS 

Библиотеки – изолированные окружения, в которых группы пользователей могут работать, сотрудничать и создавать документы. Доступ к библиотекам зависит уровня доступа. Только члены библиотеки могут их использовать. Статус «Член библиотеки» присваивается пользователям и группам пользователей администратором.

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

Документы – любые файл, хранимый в Inforouter. Это может быть документ Microsoft Word, Microsoft Excel, Microsoft PowerPoint , WordPerfect, Visio либо документ другого формата, вплоть до медиа-файлов. InfoRouter управляет всеми типами электронных документов в исходном формате.

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

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

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

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

  1.  Сравнительный анализ существующих систем

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

Базовые требования:

  •  иерархическое представление хранения документов;
  •  использование библиотек и папок для хранения;
  •  сохранность и доступность данных;
  •  сжатие документов;
  •  индексирование;
  •  улучшенный поиск;
  •  управление правами пользователей;
  •  возможность общения клиентов;
  •  поддержка LDAP;
  •  интеграция с MS Office.

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

Таблица 1.1 – Таблица оценки существующих систем

Критерии оценки

Система «Hummingbird DM»

Система «NetDocuments»

»

Система «Inforouter»

Разрабаты-ваемая система

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

+

+

+

+

использование библиотек и папок для хранения

+

+

+

+

сохранность и доступность данных

+

+

+

+

сжатие документов

+

+

+

индексирование

+

-

+

улучшенный поиск

+

+

+

управление правами пользователей

+

+

+

+

возможность общения клиентов

+

+

+

поддержка LDAP

+

-

+

интеграция с MS Office

+

+

-

+

Примечания:

  1.  “–” означает отсутствие реализации данного требования у рассматриваемой системы.
  2.  “+” означает наличие реализации данного требования у рассматриваемой системы.
    1.  Вывод

Все рассмотренные системы управления документооборотом имеют общие черты: это иерархическое представление хранения документов, использование библиотек и папок  для визуализации хранимой информации. Библиотеки выполняют роль корневых каталогов для папок, в то же время папки содержат в себе документы   и шаблоны документов. Важно отметить, что все представленные DMS’s имеют контроль версий и подверсий одного и того же документа, управление правами пользователей для доступа к системе. Различия между рассмотренными системами управления документооборотом только в том, что некоторые имеют интеграцию с MS Office, например HummingBird и NetDocs, некоторые поддерживают LDAP (NetDocuments). HummingBird, например, уже содержит встроенный инструментарий для создания собственных форм, NetDocuments поддерживает веб-сервисы, что упрощает интеграцию NetDocs в  приложениях. Хотелось бы отметить важное достоинство InfoRouter – порталы, просматриваемая информация формируется динамически для пользователя, которому дали доступ к просмотру документов, это значит, что указав конкретные каталоги, пользователь может открыть к ним доступ через персонализированную веб-страницу.

  1.  Требования к программной подсистеме

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

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

На рисунках 1.2 –1.5 приведены диаграммы вариантов использования КС управления документооборота.

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

Рисунок 1.2 – Диаграмма наследования ролей пользователей

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

Рисунок 1.3 – Диаграмма вариантов использования для гостя

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

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

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

Рисунок 1.4 – Диаграмма вариантов использования для клиента

Рисунок 1.5 – Диаграмма вариантов использования для администратора

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

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

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

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

Операции с библиотекамидоступны две операции: создать и удалить библиотеку. Библиотека – это всего лишь корневой каталог пользователя.

Операции с документамиобщие операции с документами.

Операции с шаблонамиобщие операции для работы с шаблонами

Помещение шаблона в папку  – после создания – шаблон помещается в папку, ранее созданную администратором.

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

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

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

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

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

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

Создание документа на основе шаблонадокумент создается на основе доступного шаблона документа.

Создание новой версии уже существующего документадокумент создается на основе другого документа как новая версия того документа

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

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

Создание шаблонапользователь может создать собственный шаблон документа  и поместить его в свою папку для шаблонов.

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

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

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

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

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

Удаление шаблонапользователь может удалить неиспользуемый либо устаревший шаблон.

Удалить библиотекуудаление библиотеки включает в себя удаление в себя всех документов и шаблонов документов, находящихся в папках.

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

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

  1.  Требования к графическому интерфейсу

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

.

Рисунок 1.6 – Требования к интерфейсу пользователя

Создание шаблона – пользователю предоставляется возможность создавать собственные шаблоны.

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

Сохранение документа/шаблона – предоставляется сохранение документов/шаблонов с возможностью выбора папки сохранения, либо это папки для документов, либо для шаблонов.

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

Создание и удаление папки – администратор создает каждому пользователю каталоги для хранения документов. Если каталог больше не нужен, он удаляется администратором.

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

  1.  Анализ требований к аппаратной подсистеме

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

Здание состоит из отделов различного назначения.

Можно выделить такие подразделения:

  •  отдел администрации;
  •  бухгалтерия;
  •  отдел менеджеров;
  •  отдел по работе с клиентами;
  •  отдел управления транспортировки газа;
  •  отдел тех-поддержки;
  •  отдел кадров.

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

Отдел бухгалтерии управляет денежными переводами и расчетом заработных плат для сотрудников фирмы. В данном сегменте количество сотрудников не будет превышать трех. Кроме трех рабочих компьютеров, данный отдел содержит принтер, IP-телефоны, доступ к которым можно получить через сеть в данном сегменте. Все эти устройства будут соединены через коммутатор, который в свою очередь выходит на маршрутизатор. Роль маршрутизатора заключается в том, что он, во-первых, выделяет данный сегмент в отдельную подсеть,  а во-вторых, содержит firewall, который необходим для ограничения доступа к данной подсети. Маршрутизатор должен быть с поддержкой стандарта 802.1Q, так как одна из его подзадач перенаправлять пакеты внутри нашей всей сети. Скорость обмена между двумя коммутаторами 100Mbps.

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

Четвертый отдел, который мы выделяем, является отдел управления транспортировкой газа. Общее количество сотрудников в данном отделе не будет превышать 8. Кроме сотрудников в сети предусмотрены сетевой принтер и IP телефония. Данный сегмент сети выделен в отдельный VLAN.  Поэтому, при выборе коммутатора необходимо будет учитывать количество портов на нем,  а также поддержка технологии VLAN. Выход коммутатора будет подключен к коммутатору на Backbone. Скорость передачи данных в сегменте 1Gbps.

Пятый отдел, который мы выделяем, является отдел по работе с клиентами. Общее количество сотрудников в данном отделе не будет превышать 10. Кроме сотрудников в сети предусмотрены сетевой принтер и IP телефония. Данный сегмент сети выделен в отдельный VLAN.  Поэтому, при выборе коммутатора необходимо будет учитывать количество портов на нем,  а также поддержка технологии VLAN. Выход коммутатора будет подключен к коммутатору на Backbone. Скорость передачи данных в сегменте 1Gbps.

Шестым отделом, который мы выделяем, является отдел кадров. К нему относятся сотрудники, которые занимаются трудовыми отношениями персонала. Общее количество сотрудников в данном отделе не будет превышать 7. Кроме сотрудников в сети предусмотрены сетевой принтер, факс и IP телефония. Скорость обмена между двумя коммутаторами 100Mbps.

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

Также в сегменте сети необходимо выделить некоторый набор адресов для серверов общего пользования (DMZ). Поскольку доступ к данным серверам должен быть равноправный, то установим их на Backbone. Так как файловый сервер будет передавать по сети большие объемы данных, то необходимо обеспечить доступ не менее 1Gbps. Такие же требования и к серверу базы данных.

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

  1.  Постановка задачи на разработку системы

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

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

Так же должна быть разработана локальная вычислительная сеть для предприятия «Черниговгазмонтаж », состоящею из 45 компьютеров.

Локальная сеть должна быть разбита на сегменты и обеспечивать:

  •  скорость передачи информации 100 и 1000 Мбит/сек;
  •  беспроводной доступ к сетевым ресурсам;
  •  предоставлять сервис ip-телефонии;
  •  безопасный доступ к Интернету для сотрудников фирмы;
  •  обмен файлами между компьютерами и доступ к общим сетевым ресурсам фирмы;
  •  защиту от несанкционированного доступа;
  •  разделение сети на сегменты используя стандарт VLAN.
    1.  Общие требования к разрабатываемой системе

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

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

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

 На рисунке 1.7 представлена диаграмма требований по жизненному циклу документа.

Жизненный цикл документа  – данная система является универсальным помощником, который ускорит и оптимизирует все действия, связанные с управлением электронными документами

Создание документа – так как для редактирования документа будет использоваться привычная для пользователя среда, а именно текстовый редактор MS Word, пользователь не будет ощущать дискомфорта при пользовании системы.

Рисунок 1.7 – Создание новой версии документа

Редактирование документа - редактирование документа производится с учетом шаблона, на основе которого создан документ. При изменении шаблонов – документ тоже претерпит изменения.

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

Так как существуют некоторые нюансы, связанные с созданием новых документов, то есть смысл их рассмотреть.

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

На рисунке 1.8 представлена диаграмма требований к созданию нового документа.

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

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

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

Рисунок 1.8 – Создание документа

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

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

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

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

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

Рисунок 1.9 – Создание новой версии документа

  1.  Выводы

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

Задачей системы будет являться: создание документов, сохранение их в базе данных. Данная система должна быть правильно спроектированной и отвечать всем требованиям, которые были предъявлены выше.


  1.  Разработка кс Управления документооборотом
  2.  
    1.  Выбор технических средств построения системы

В данном разделе будет изложен процесс выбора технологий и языков реализации системы. А именно будет произведен выбор конкретного языка web-программирования, выбор способа объектно-реляционного отображения. Будет произведен обзор выбранных технологий.

  1.  Выбор языка реализации системы

Существуют клиентские и серверные языки web-программирования, их классификация представлена на рисунке 2.1[7].

Рисунок 2.1 – Классификация языков web-программирования

Клиентские языки используются для написания программ, выполняемых на стороне клиента (браузер), а серверные – для программ, выполняемых на сервере.

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

Другие популярные клиентские языки, а точнее фреймворки – это Adobe Flash (язык Action Script) и Silver Light (любые .NET языки). Adobe Flash применяется веб-мастерами довольно долгое время. Основное применение этой технологии – интерактивные сайты и сервисы, онлайновые игры, мультимедийный контент, реклама. Silver Light – это новая технология, разработанная компанией Microsoft и позиционируемая как замена Adobe Flash. Не смотря на то, что с помощью Adobe Flash и Silver Light можно построить полностью весь сайт, этого делать не следует, потому, что современные поисковые системы не могут индексировать ни Adobe Flash ни Silver Light.

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

Если говорить про ОС Windows, то здесь лучше всего и быстрее всего работает технология ASP .NET, разработанная компанией Microsoft. С помощью ASP .NET можно создавать сайты любого уровня сложности – от самых простых, состоящих из нескольких страниц, до очень сложных, обрабатывающих миллионы запросов в день. Сайты Microsoft, написанные на ASP .NET, являются одними из самых посещаемых в Интернет. Здесь основным языком веб-программирования служит C#. Основной недостаток этой технологии – меньшее, по сравнению с Unix, количество дешевых хостингов и необходимость покупки серверной лицензии, в случае с выделенным хостингом.

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

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

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

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

  1.  Выбор технологий реализации

В процессе создания корпоративного приложения традиционно используются проверенные временем стратегии проектирования (разбиение приложения на слои, выбор стратегии проектирования каждого слоя) и технологии реализации отдельных частей программной системы. К таким технологиям относятся JSF (служит для реализации слоя представления), Hibernate (для реализации слоя интеграции), технология аспектно-ориентированного программирования и т.д[8].

Реализация object-relational mapping (O/R mapping) является общей потребностью для множества проектов по разработке программного обеспечения. Обычно работа над автоматизацией процесса хранения данных очень скучна, и при ручной реализации существует опасность возникновения ошибок. Если к этому прибавить постоянно меняющиеся требования, разработчику необходимо учитывать сложный процесс синхронизации исходного кода и структуры хранения данных. Также необходима переносимость приложений между платформами, и все становится еще более сложным и запутанным.

  1.  
  2.  
    1.  
      1.  
      2.  
        1.  Библиотека объектно-реляционного отображения Hibernate

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

У Hibernate есть ряд преимуществ перед другими подобными подходами к объектно-реляционному управлению (JDO, компоненты управления данными, внутренняя разработка программ и т.д.): это доступная исходная программа, достигшая высокой степени зрелости, она широко используется и активно обсуждается.

Hibernate предусматривает язык запросов, который называется Hibernate Query Language, схожий с SQL. Тем из вас, кто предпочитает старые добрые SQL-запросы, Hibernate все еще дает возможность использовать их.

К основным компонентам архитектуры библиотеки относятся:

  •  интерфейсы для выполнения базовых CRUD (create/read/update/delete) операций и запросов. Session, Transaction и Query;
  •  интерфейсы для конфигурации Hibernate Configuration;
  •  интерфейсы обратного вызова (Callback-интерфейсы). Interceptor, Lifecycle и Validatable;
  •  интерфейсы, предназначенные для расширения возможностей библиотеки. UserType, CompositeUserType, IdentifierGenerator и Dialect.

Архитектура библиотеки приведена на рисунке 2.2.

Рисунок 2.2 – Архитектура библиотеки Hibernate

Session – основной интерфейс, используемый приложениями Hibernate. Представляет собой сеанс взаимодействия клиентского кода с Hibernate. Также называется менеджером постоянства (persistence manager). Объекты сеанса создаются очень быстро и не требуют большого количества ресурсов. Они не являются потокобезопасными.

Session Factory. Предназначен для получения объектов сеанса. Экземпляры требуют много ресурсов и должны создаваться один раз для всего приложения в самом начале. Может содержать кэш 2-го уровня.

Configuration. Предназначен для хранения настроек Hibernate. Обычно создается на основе файлов конфигурации. Необходим прежде всего для создания экземпляров Session Factory.

Transaction. Предназначен для управления транзакциями. Основное преимущество состоит в сокрытии конкретного механизма управления транзакциями от клиентского кода.

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

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

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

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

  1.  Фреймворк Java Server Faces (JSF)

Java Server Faces (JSF) — это фреймворк для веб-приложений написанный на Java. Он служит для того, чтобы упростить разработку пользовательских интерфейсов для Java  EE приложений. В отличие от прочих MVC (Model-view-controller, «Модель-представление-поведение») фреймворков, которые управляются запросами, подход JSF основывается на использовании компонент. Состояние компонентов пользовательского интерфейса сохраняется, когда пользователь запрашивает новую страницу и затем восстанавливается, если запрос повторяется. Для отображения данных обычно используется JSP, но JSF можно приспособить и под другие технологии.

Технология Java Server Faces включает в себя:

– набор API для представления компонент пользовательского интерфейса (UI) и управления их состоянием, обработкой событий и проверкой на достоверность вводимой информации, определения навигации, а также поддержку интернационализации и доступности (accessibility);

– специальная библиотека JSP тегов для выражения интерфейса JSF на JSP странице.

Разработанная быть гибкой, технология Java Server Faces усиливает существующие, стандартные концепции пользовательского интерфейса (UI) и концепции Web-уровня без привязки разработчика к конкретному языку разметки, протоколу или клиентскому устройству. Классы компонент пользовательского интерфейса, поставляемые вместе с технологией Java Server Faces, содержат функциональность компонент, а не специфичное для клиента отображение, открывая тем самым возможность передачи JSF-компонент на различных клиентских устройствах.

  1.  Технология OpenSocial

OpenSocial – это набор программных интерфейсов для построения web-приложений. Цель данной технологии сделать больше приложений доступных большему числу пользователей с использованием общего API который может быть использован для самых разных целей. Разработчики могут создавать приложения используя стандартный JavaScript и HTML, которые могут работать на Web-сайтах, которые имеют реализацию программных интерфейсов OpenSocial. Такие веб-сайты, называют OpenSocial контейнеры, которые позволяют разработчикам получить доступ к информации на сайте, в результате разработчик реализации программных интерфейсов OpenSocial получает большое количество приложений для своих пользователей.

Фактически, OpenSocial контейнер – это Web-сайт на котором могут выполняться любые приложения написанные с использованием OpenSocial API.

Для того, чтобы реализовать эту возможность необходимо:

  1.  Контейнер должен реализовывать все интерфейсы из OpenSocial API Reference. Если какие-то из методов не были реализованы, то они должны содержать стандартную заглушку, которая возвращает код ошибки opensocial.ResponseItem.NOT_IMPLEMENTED;
  2.  Контейнер должен использовать только определенные механизмы расширяемости для любых контейнерно-ориентированных приложений;
  3.  Контейнер должен выполнять требования Gadgets API Specification;
  4.  Контейнер должен поддерживать RESTful протокол;
  5.  Контейнер должен поддерживать RPC протокол.
    1.  Технология Apache Shindig

Shindig – это новый проект Apache Software Foundation, который имеет цель внедрить свободно распространяемую реализацию OpenSocial интерфейсов и их описание. Цель Shindig – позволить создателям новых сайтов упростить работу с технологией OpenSocial.

Компоненты Shindig – можно разбить на следующие части:

  •  gadget Container JavaScript – ядро, написанное на JavaScript, для базового функционирования гаджетов. Управляет безопасностью, коммуникациями, расположением в окне браузера и разными расширениями, такими как OpenSocial API;
  •  gadget Server – свободно распространяемая версия gmodules.com, которая используется для обработки и преобразования данных в формате xml поступающих от гаджетов в JavaScript и HTML для контейнера, отображаемого в браузере;
  •  OpenSocial Container JavaScriptJavaScript среда которая управляет гаджетом и предоставляет OpenSocial функциональность;
  •  OpenSocial Gateway Server – свободно распространяемая реализация интерфейса сервера контейнера, включающая реализацию протокола OpenSocial REST, которая позволяет подключать собственные реализации.
    1.  Выбор СУБД

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

  1.  
    1.  Определение требований к СУБД

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

Моделирование данных:

  •  используемая модель данных;
  •  триггеры и хранимые процедуры;
  •  средства поиска;
  •  предусмотренные типы данных;
  •  реализация языка запросов.

Особенности архитектуры и функциональные возможности:

  •  мобильность;
  •  масштабируемость;
  •  распределенность;
  •  сетевые возможности.

Контроль работы системы:

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

Особенности разработки приложений:

  •  средства проектирования;
  •  многоязыковая поддержка;
  •  возможности разработки Web-приложений;
  •  поддерживаемые языки программирования.

Производительность:

  •  рейтинг TPC (Transactions per Cent);
  •  возможности параллельной архитектуры;
  •  возможности оптимизирования запросов.

Надежность:

  •  восстановление после сбоев;
  •  резервное копирование;
  •  откат изменений;
  •  многоуровневая система защиты.

Требования к рабочей среде:

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

Смешанные критерии:

  •  качество и полнота документации;
  •  локализованность;
  •  модель формирования стоимости;
  •  стабильность производителя;
  •  распространенность СУБД.

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

  1.  Microsoft SQL Server

Microsoft SQL Server — система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для небольших и средних по размеру баз данных, и в последние 5 лет — для крупных баз данных масштаба предприятия, конкурирует с другими СУБД в этом сегменте рынка.

Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных). Протокол TDS также был реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server и Sybase.

Microsoft SQL Server также поддерживает Open Database Connectivity (ODBC) — интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server. Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000 и 2005.

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

SQL Server поддерживает избыточное дублирование данных по трем сценариям:

Снимок: Производится «снимок» базы данных, который сервер отправляет получателям.

История изменений: Все изменения базы данных непрерывно передаются пользователям.

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

В SQL Server 2005 встроена поддержка .NET Framework. Благодаря этому, хранимые процедуры БД могут быть написаны на любом языке платформы .NET, используя полный набор библиотек, доступных для .NET Framework, включая Common Type System (система обращения с типами данных в Microsoft .NET Framework). Однако, в отличие от других процессов, .NET Framework, будучи базисной системой для SQL Server 2005, выделяет дополнительную память и выстраивает средства управления SQL Server вместо того, чтобы использовать встроенные средства Windows. Это повышает производительность в сравнении с общими алгоритмами Windows, так как алгоритмы распределения ресурсов специально настроены для использования в структурах SQL Server.

  1.   MySQL

MySQL — свободная система управления базами данных (СУБД). MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

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

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

Несмотря на то, что версия 4.0 является устаревшей, она всё ещё имеет значительное распространение. Основные возможности этой версии:

  •  практически полная реализация ANSI SQL-99, плюс расширения;
  •  межплатформенная совместимость;
  •  независимые типы таблиц (MyISAM для быстрого чтения, InnoDB для транзакций и ссылочной целостности);
  •  транзакции;
  •  поддержка SSL;
  •  кеширование запросов;
  •  репликация: один головной сервер на одного подчинённого, много подчинённых на одного головного;
  •  полнотекстовая индексация и поиск с использованием типа таблиц MyISAM;
  •  внедрённая библиотека базы данных;
  •  поддержка Юникода (UTF-8);
  •  таблицы InnoDB обеспечивают соответствие требованиям ACID;
  •  встроенный сервер, позволяющий включать MySQL в автономные приложения.

Рекомендованной версией на 2005 год является MySQL 4.1 вышла 27 октября 2004.

Она содержит следующие нововведения:

  •  вложенные запросы и производные таблицы;
  •  новая система кодировок и сортировок;
  •  более быстрый и гибкий протокол клиент-сервер с поддержкой подготовленных запросов, обеспечивающий их оптимальное исполнение;
  •  новая программа установки и настройки для Microsoft Windows и GNU/Linux;
  •  защищённые через OpenSSL соединения клиент-сервер;
  •  высоко-оптимизированная библиотека, которая может быть использована в сторонних программах;
  •  полноценная поддержка Юникода (UTF-8 и UCS2);
  •  стандартные пространственные типы данных GIS, для хранения географической информации;
  •  улучшенный полнотекстовый поиск и система помощи.

Версия MySQL 5.0 вышла 24 октября 2005 года, в этой версии значительно расширена функциональность, которая ставит MySQL в один ряд с коммерческими СУБД. Если раньше СУБД MySQL обвиняли в недостаточной поддержке стандарта SQL, то с появлением пятой версии этой популярной базы данных, появилась практически полная поддержка стандарта SQL. MySQL 5.0 содержит следующие нововведения:

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

Версия MySQL 5.1 продолжает путь к стандарту SQL:2003. MySQL 5.1 содержит следующие нововведения :

  •  сегментирование — возможность разбить одну большую таблицу на несколько частей, размещенных в разных файловых системах, основываясь на определенной пользователем функции. При определенных условиях это может дать серьезное увеличение производительности и, кроме того, облегчает масштабирование таблиц;
  •  изменено поведение ряда операторов, для обеспечения большей совместимости со стандартом SQL2003;
  •  встроенный планировщик периодически запускаемых работ. По синтаксису добавление задачи похоже на добавление триггера к таблице, по идеологии - на crontab;
  •  дополнительный набор функций для обработки XML, реализация поддержки XPath;
  •  MySQL Cluster отныне выпущен как отдельный продукт, базирующийся на MySQL 5.1 и хранилище NDBCLUSTER;
  •  значительные изменения в работе MySQL Cluster, такие, как, например, возможность хранения табличных данных на диске;
  •  возврат к использованию встроенной библиотеки libmysqld, отсутствовавшей в MySQL 5.0;
  •  API для плагинов, которое позволяет загружать сторонние модули, расширяющие функциональность (например, полнотекстовый поиск), без перезапуска сервера.
  •  реализация парсера полнотекстового поиска в виде plug-in;
  •  новый тип таблиц Maria (устойчивый к сбоям клон MyISAM).

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

MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

  1.  Выбор элементной базы для ЛВС

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

В такой локальной сети чаще всего нет отдельных компьютеров — серверов, которые выполняют служебные для всей сети функции. Все компьютеры в ней равноправны и представляют собой обычные персональные компьютеры (рабочие станции), на которых работают пользователи. Как правило, используются операционные системы Linux и Windows XP/Seven. Из программного обеспечения — стандартный набор Microsoft Office и несколько программ других производителей.


Рисунок 2.3 – Стандартный пример сети

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

Хаб – наиболее простое устройство для соединения группы компьютеров в локальную сеть. Небольшая коробочка или печатная плата, вставляемая в слот компьютера, снабжена розетками – портами – для подключения сетевых кабелей. Наиболее популярны варианты, когда количество розеток составляет 8 и 16 для внешних хабов и 5 – для внутренних. Внутри хаба находятся усилители, которые связывают все сетевые розетки друг с другом. Отличительная черта хаба –  все входные сигналы транслируются на все выходные линии без всяких преобразований (что поступило, то и вышло). Некоторая аналогия хаба – это электрический удлинитель, к которому можно подключить столько устройств, сколько нужно, но каждое получает одинаковое напряжение. Отсюда и некоторое неудобство хаба -подключать можно только такие сетевые платы, которые могут дружно работать на скорости 10 или 100 Мбит/с. А вариант, когда одна плата использует стандарт 10, а остальные более совершенный стандарт 100 Мбит/с, невозможен. Для согласования скоростей в различных частях сети используют либо двухскоростные хабы, либо коммутаторы.

Рисунок 2.4 – Устройство коммутации

Коммутатор – это усовершенствованная версия хаба, у которого есть некоторый "интеллект". В отличие от хаба, коммутатор может определить маршрут, по которому должны пересылаться данные. То есть пакеты, поступившие на какой-либо порт, отправляются по нужному адресу. Кроме того, коммутатор преобразовывает входные сигналы, обеспечивая согласование работы всех сетевых плат, подключенных к нему, поэтому с помощью коммутатора можно соединить две сетевые платы, работающие в разных стандартах 10 и 100 Мбит/с. Для этого используется функция Auto MDI/MDIX.

Рисунок 2.5 – Устройство маршрутизации

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

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

Долгое время коммутаторы и маршрутизаторы были отдельными и обособленными устройствами.

Термин "коммутатор" (switch) был зарегистрирован для аппаратной платформы, которая функционировала на втором уровне эталонной модели OSI. Например ATM-коммутатор реализует аппартную передачу ячеек фиксированной длинны (cells), в то время как Ethernet-коммутаторы для передачи используют MAC-адреса.

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

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

Различают две реализации коммутации третьего уровня:

  •  с использованием маршрутизирующих коммутаторов (routing switches);
  •  использованием коммутирующих маршрутизаторов (switching routers).

Рисунок 2.6 – Маршрутизирующий коммутатор/Routing switch. Типовое изображение на схемах.

Первыми устройствами, реализовавшими коммутацию третьего уровня, были маршрутизирующие коммутаторы. Основа работы маршрутизирующего коммутатора это нахождение кратчайшего пути (путей) через сердцевину сети используя аппаратное обеспечение в обход традиционных программных маршрутизаторов. Т. е. суть работы устройства видна из его названия: сам процесс обработки (передачи) данных осуществляется на 2-м (канальном) уровне, предварительный же поиск оптимального маршрута осуществляется при помощи 3-го уровня. Обычно задействуется внешний маршрутизатор или плата маршрутизации которую коммутатор воспринимает как отдельное (внешнее) устройство. Исходя из вышесказанного, можно утверждать следующее:маршрутизируемые протоколы (3-го уровня), ни как не связаны с маршрутизирующими коммутаторами (в отличии от маршрутизаторов), т. е. это протокольно-независимые устройства;маршрутизирующие коммутаторы не могут использовать в своей работе протоколы маршрутизации, такие как RIP, OSPF, EIGRP, вместо этого в них применяются различные методы обнаружения, создания или кэширования (cache) информации о кратчайшем маршруте.В качестве примера можно привести мультипротокольную передачу данных по сетям ATM (Multiprotocol over ATM - MPOA). Такая стандартизированная технология позволяет присоединенным к ATM-сети устройствам создавать виртуальный канал, который дает маршрутизаторам возможность избегать перегрузок. Cisco разработала другую методику поиска кратчайшего пути, не требующую наличия ATM-магистрали, - многоуровневая коммутация (Multilayer Switching - MLS) или LAN-коммутация NetFlow (NetFlow LAN Switching - NFLS). Последним комплексным "проявлением" маршрутизирующей коммутации является технология Мультипротокольной Коммутации Меток (MultiProtocol Label Switching - MPLS), которая пытается сразу решить как задачи непосредственно быстрой передачи данных (Switching), так и качества обслуживания и приоритезации трафика (QoS) плюс изоляции и безопасности (VLAN). Собственно VLAN и является основой MPLS, чей алгоритм работы похож на MPOA, только вместо создания виртуального канала

Рисунок 2.6 – Коммутирующий маршрутизатор/Switching router. Типовое изображение на схемах.

Коммутирующие маршрутизаторы появились на рынке позже своих "кузенов". В них, как и в традиционных маршрутизаторах, обработка пакетов осуществляется с помощью процессора общего назначения. Однако в отличии от традиционных маршрутизаторов, коммутирующие маршрутизаторы используют процессор общего назначения только для управления (control-plane). Передача же данных (data plane) осуществляется при помощи высокоскоростных специализированных интегральных микросхем (application scesific integrated circuit - ASIC). Так как процессор не участвует в передаче данных, достигается производительность, сравнимая с максимальной физической скоростью среды передачи данных (wire speed perfomance). В связи с тем что коммутирующие маршрутизаторы по сути являются обыкновенными маршрутизаторами, только "под завязку нашпигованными" аппаратными верно практически для любого маршрутизатора). 

  1.  Выводы

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

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

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

В качестве системы управления базами данных была выбрана MySQL так как эта СУБД соответствует практически всем поставленным требованиям, является кроссплатформенной, поддерживает множество языков программирования, в том числе и Java, и что самое главное – является свободно распространяемой СУБД с открытым исходным текстом.

Для ЛВС были выбраны коммутаторы уровня 3 с возможной скоростью до 1000 Мбит/c.

  1.  Разработка архитектура ИКС

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

Серверная составляющая КС тесно взаимодействует с клиентской стороной, посредством http-протокола. Это предусматривает наличие web-сервера, который будет обрабатывать все запросы клиентской составляющей разрабатываемой системы.

Доступ персонала к серверам системы и интернету осуществляется средствами VPN. Для постояльцев присутствует возможность пользоваться WI-FI для доступа в интернет.

На рисунке 2.7 изображена архитектура КС управления документооборотом предприятия «Черниговгазмонтаж».

Рисунок  2.7 – Архитектура  КС управления документооборотом предприятия «Черниговгазмонтаж»

На рисунке 2.8 представлена архитектура сети предприятия «Черниговгазмонтаж»

Рисунок 2.8 – Архитектура ЛВС предприятия «Черниговгазмонтаж»

Представленная архитектура сети имеет топологию звезда. ЛВС включает в себя ядро(“Backbone”), внешний маршрутизатор (предоставляет доступ в интернет и к серверам) и сервера(DNS, LDAP, WEB, DHCP, FTP). Ядро является коммутатором уровня 3 и содержит в себе 5 отделов предприятия. Каждый отдел размещен в vlan  и требует доступ к специфическим сервисам и серверам.

  1.  Разработка структуры программной подсистемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 2.9 – Структура программной  подсистемы КС управления документооборотом предприятия «Черниговгазмонтаж»

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

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

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

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

В качестве системы управления реляционными базами данных был выбран Microsoft SQL Server. Microsoft SQL Server — система управления реляционными базами данных, разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с небольшими и средними по размеру базами данных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка.

В ходе разработки было принято решение использовать Microsoft SQL Server Express, который является бесплатно распространяемой версией SQL Server, развитием системы MSDE. Данная версия имеет некоторые технические ограничения. Такие ограничения делают её непригодной для развертывания больших баз данных, но она вполне годится для ведения программных комплексов в масштабах небольшой компании. Содержит полноценную поддержку новых типов данных, в том числе XML-спецификации. Фактически, это полноценный MS SQL Server, включая все его компоненты программирования, поддержку национальных алфавитов и Unicode. Поэтому используется в приложениях, при проектировании или для самостоятельного изучения. Нет никаких препятствий для дальнейшего развёртывания накопленной базы данных на MS SQL Server неэкспрессной версии.

Таблица User - данная таблица сохраняет всю имеющуюся информацию о пользователях. Описание полей таблицы:

  •  ID – уникальный идентификатор пользователя;
  •  Fname – имя пользователя;
  •  LName – фамилия пользователя;
  •  Phone – рабочий телефон;
  •  Address – Рабочий адрес пользователя;
  •  login – логин пользователя, используется для авторизации;
  •  passwd –  хранит пароль пользователя;
  •  Role – роль пользователя в системе.

Таблица Role - данная таблица хранит типы ролей в системе. Содержит поля:

  •  ID – идентификатор;
  •  RoleName – сама роль, это может быть либо администратор, либо пользователь.

Таблица Library  - хранит информацию о библиотеке. Имеет такие поля:

  •  ID – идентификатор библиотеки;
  •  Name – название библиотеки;
  •  Description – описание библиотеки;
  •  Owner – пользователь – владелец библиотеки;
  •  CreationDate – дата создания библиотеки;

Таблица Folder - содержит всю необходимую информацию о каталоге:

  •  ID – идентификатор каталога;
  •  Name – название каталога;
  •  Description – описание каталога;
  •  Owner – пользователь – владелец каталога;
  •  CreationDate – дата создания каталога;
  •  Library – библиотека, которая содержит каталог;
  •  Folders – каталоги, для которых данный является корневым.

Таблица DocType - содержит типы хранимых файлов. Содержит поля:

  •  ID – идентификатор;
  •  DocType – тип хранимого документа, а именно либо шаблон, либо документ.

Таблица Folders - содержит дочерние каталоги. Содержит поля:

  •  ID – идентификатор;
  •  Foder – содержит идентификатор дочернего каталога.

Таблица Document - содержит всю необходимую информацию о документе:

  •  ID – идентификатор документа;
  •  Name – название документа;
  •  Description – описание документа;
  •  Creator – пользователь – создатель документа;
  •  CreationDate – дата создания документа;
  •  Document – содержит путь к документу;
  •  Version – версия документа;
  •  Template – идентификатор шаблона, по которому создан документ;
  •  Folder – каталог, содержащий документ.

Таблица Version - содержит версии документов. Имеет поля:

  •  ID – идентификатор;
  •  Version – версия документа;
  •  ParentID – идентификатор версии, для которой эта является подверсией.

Таблица Template - содержит всю необходимую информацию о шаблоне:

  •  ID – идентификатор шаблона;
  •  Name – название шаблона;
  •  Description – описание шаблона;
  •  Creator – пользователь – создатель шаблона;
  •  CreationDate – дата создания шаблона;
  •  Template – содержит путь к шаблону;
  •  Folder – каталог, содержащий шаблон.

Рисунок 2.10 – Схема БД КС управления документооборотом предприятия «Черниговгазмонтаж»

  1.  Диаграмма классов домена серверного приложения

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

Диаграмма классов домена для сервера показана на рисунке 2.11.

Рисунок 2.11 – Диаграмма классов домена

  1.   Диаграмма сервисов серверного приложения

Данный класс содержит все необходимые сервисы системы. Диаграмма представлена на рисунке 2.12.

SystemId - данный класс содержит уникальный идентификатор объекта в системе. Каждая сущность разрабатываемой системы будет иметь этот идентификатор.

UserService - данный класс содержит сервисы пользователя:

  •  changePassword – позволяет изменить пароль пользователя в системе;
  •  getUserAttribute – позволяет получить необходимые пользовательские данные;
  •  login – используется для аутентификации пользователя;
  •  getUserAttribute – позволяет установить пользовательские атрибуты.

UsersService - данный класс используется исключительно администратором и служит для управлениями аккаунтами пользователей, а именно:

  •  findUser – позволяет получить уникальный идентификатор пользоваетля по его имени;
  •  listUsers – администратор имеет возможность получить полный список всех зарегистрированных пользователей системы;
  •  registerUser – позволяет зарегистрировать нового пользователя в системе;
  •  removeUser – дает возможность удалить пользователя из системы по его уникальному идентификатору.

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

  •   newLibrary – позволяет администратору создать новую библиотеку на основе уникального идентификатора пользователя и названия самой библиотеки;
  •  removeLibrary – администратор может удалить существующую библиотеку по ее уникальному идентификатору;
  •  listDirectories – дает возможность пользователю получить список всех каталогов библиотеки, в данном случае в качестве параметра выступает уникальный идентификатор библиотеки;
  •  addDirectory – позволяет добавить новый каталог, в качестве параметров метод принимает значения идентификатора библиотеки и название каталога;
  •  removeDirectory – позволяет удалить существующий каталог по уникальному идентификатору этого каталога, а также идентификатору содержащей его библиотеки;
  •  addUser – данный метод позволяет добавить пользователя в список пользоваетлей, которым будет доступна библиотека. Метод принимает такие параметры. Как идентификатор библиотеки и уникальный идентификатор пользователя;
  •  removeUser – позволяет удалить пользователя из списка пользователей библиотеки по идентификатору библиотеки и идентификатору пользователя;
  •  listUsers – этот метод дает возможность  получить список пользователей библиотеки по идентификатору библиотеки;
  •  getLibraryAttribute – данный метод позволяет получить указанный атрибут библиотеки, в данном случае в качестве параметров передается идентификатор библиотеки и тип атрибута;
  •  setLibraryAttribute – позволяет установить атрибуты библиотеки.

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

  •  newDirectory – позволяет администратору создать новый каталог на основе уникального идентификатора пользователя и названия каталога;
  •  removeDirectory – администратор может удалить существующий каталог по его уникальному идентификатору;
  •  getLibraryAttribute – данный метод позволяет получить указанный атрибут каталога, в данном случае в качестве параметров передается идентификатор каталога и тип атрибута.

FileService - данный сервис используется для управления файлами пользователей, содержит такие методы:

  •  findFiles – поиск файлов в библиотеке по идентификатору библиотеки и строке запроса;
  •  newFile – данный метод позволяет создать новый файл, в качестве параметров метод получает уникальный идентификатор каталога, название файла и булевскую переменную, которая определяет, является ли документ шаблоном;
  •  retrieveLastFileVersion – данный метод возвращает последнюю версию документа, на вход получает идентификатор файла;
  •  retrieveFileVersion – данный метод возвращает указанную версию документа, на вход получает идентификатор файла и номер версии;
  •  getFileTemplateId – получение шаблона документа по идентификатору документа;
  •  listFileVersions – дает возможность получить текущий список версий документа, идентификатор которого передается в качестве параметра;
  •  createNewVersion – этот метод позволяет создать новую версию существующего документа  на основе идентификатора документа и самого файла.

Рисунок 2.12 – Диаграмма сервисов серверного приложения

  1.  Разработка WEB-компонента системы 

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

  1.  Разработка эскиза интерфейса пользователя 

Проведя анализ пользователей, можно выделить ряд задач,  которые должен решить WEB-компонент системы:

  1.  просмотр всех библиотек, к которым открыт доступ, а так же просмотр своей собственной библиотеки;
  2.   просмотр дерева папок и документов, а также создание собственных папок;
  3.   просмотр информации об отдельно взятом  документе или о конкретно взятой папке;
  4.  просмотр и создание пользовательских веб-порталов.
  5.  управление пользователями - администраторам необходимо просматривать список пользователей, изменять их права, редактировать профиль, подтверждать активацию;
  6.  управление услугами – администраторам необходимо добавлять новые услуги, удалять уже устаревшие или не пользующие популярностью.
  7.  предоставлять пользователям полную контактную информацию (телефонные номера, адреса).

Проанализировав задачи, были разработаны прототипы интерфейса пользователя. На рисунке 2.13 представлен эскиз главной страницы web-сайта предприятия.

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

Рисунок 2.13 – Главное окно

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

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

Рисунок 2.14 – Регистрация пользователя

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

Рисунок 2.15 – Предполагаемый интерфейс пользователя просмотра пользовательских документов

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

Рисунок 2.16 – Предполагаемый интерфейс пользователя открытия документа

На рисунке 2.17 представлен предполагаемый интерфейс пользователя для сохранения документа. Справа клиент может выбрать библиотеку, куда сохранить файл, а справа – дерево папок. Так же есть возможность выбрать: сохранить файл как шаблон, либо как документ.

Рисунок 2.17 – Предполагаемый интерфейс пользователя сохранения документа

  1.  Разработка сценария использования интерфейса
    1.  Сценарий «Регистрации пользователя»

С главного окна (рисунок 2.13) зарегистрированный пользователь может войти в систему, а гость – перейти к регистрации. Для того чтобы зарегистрироваться нужно слева в главном окне  нажать кнопку «Register» после чего появится форма регистрации, показанная на рисунке 2.14. Пользователю нужно заполнить несколько полей и нажать на кнопку «Registration», после этого  уже зарегистрированный пользователь может войти в систему.

  1.  Сценарий «Просмотр сведений о документе»

С главного окна (рисунок 2.13) зарегистрированный пользователь может войти в систему, после того как в левом углу главного окна введет свой логин и пароль и нажмет на кнопку «Enter».

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

  1.  Сценарий «Сохранение документа»

С главного окна (рисунок 2.13) зарегистрированный пользователь может войти в систему, после того как в левом углу главного окна введет свой логин и пароль и нажмет на кнопку «Enter».

Появится страница, приведенная на рисунке 2.15. Здесь пользователь может просматривать  все библиотеки, к которым ему открыт доступ, а так же просмотр своей собственной библиотеки, просмотреть дерево папок и документов. Создав документ, пользователь справа на рисунке 2.17 может выбрать библиотеку, куда сохранить файл, а справа – дерево папок. Так же есть возможность выбрать: сохранить файл как шаблон, либо как документ.

  1.  Разработка карты сайта 

Карта сайта разрабатывается для трёх ролей пользователей. На рисунке 2.18 представлена карта административной части сайта.

Рисунок 2.18 – Карта административной части сайта

На рисунке 2.19 представлена карта зарегистрированного пользователя сайта.

Рисунок 2.19 – Карта зарегистрированного пользователя сайта

На рисунке 2.20 представлена карта незарегистрированного пользователя сайта.

Рисунок 2.20 – Карта незарегистрированного пользователя сайта

  1.  Разработка аппаратной подсистемы 
    1.  Проектирование архитектуры ЛВС 

Первым отделом, который необходимо выделить в отдельный сегмент сети, является отдел администрации. К нему относятся секретарь и директор. Общее количество ПК в данном отделе не будет превышать 2. Кроме сотрудников в данном отделе предусмотрены 2 сетевых принтера и 2 IP телефона. Данный сегмент сети выделен в отдельный VLAN.  Поэтому, при выборе коммутатора необходимо будет учитывать количество портов на нем,  а также поддержка технологии VLAN. Выход коммутатора будет подключен к коммутатору на Backbone. Скорость обмена между двумя коммутаторами 100Mbps.

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

Третиий отдел, который выделяем, является отдел управления транспортировкой газа. Общее количество сотрудников в данном отделе не будет превышать 10. Кроме сотрудников в сети предусмотрены сетевой принтер и IP телефон. Данный сегмент сети выделен в отдельный VLAN.  Поэтому, при выборе коммутатора необходимо будет учитывать количество портов на нем,  а также поддержка технологии VLAN. Выход коммутатора будет подключен к коммутатору на Backbone. Скорость передачи данных в сегменте 1Gbps.

Четвертый отделом, который мы выделяем, является отдел по работе с клиентами. Общее количество сотрудников в данном отделе не будет превышать 10. Кроме сотрудников в сети предусмотрены сетевой принтер и IP телефония. Данный сегмент сети выделен в отдельный VLAN.  Поэтому, при выборе коммутатора необходимо будет учитывать количество портов на нем,  а также поддержка технологии VLAN. Выход коммутатора будет подключен к коммутатору на Backbone. Скорость передачи данных в сегменте 1Gbps.

Таким образом, на первом этаже предприятия будут следующие отделы:

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

Рисунок 2.21 – План здания на первом этаже

Следующим отделом, который необходимо выделить в отдельный сегмент сети, является бухгалтерия. Данный отдел управляет денежными переводами и расчетом заработных плат для сотрудников предприятия. В данном сегменте количество сотрудников не будет превышать шести. Кроме шести рабочих компьютеров, данный отдел содержит сетевой принтер, факс, IP-телефоны, доступ к которым можно получить через сеть в данном сегменте. Все эти устройства будут соединены через коммутатор, который в свою очередь выходит на маршрутизатор. Роль маршрутизатора заключается в том, что он, во-первых, выделяет данный сегмент в отдельную подсеть,  а во-вторых, содержит firewall, который необходим для ограничения доступа к данной подсети. Маршрутизатор должен быть с поддержкой стандарта 802.1Q, так как одна из его подзадач перенаправлять пакеты внутри нашей всей сети. Скорость обмена между двумя коммутаторами 100Mbps.

Шестым отделом, который мы выделяем, является отдел кадров. К нему относятся сотрудники, которые занимаются трудовыми отношениями персонала. Общее количество сотрудников в данном отделе не будет превышать 7. Кроме сотрудников в сети предусмотрены сетевой принтер, факс и IP телефония. Данный сегмент сети выделен в отдельный VLAN.  Поэтому, при выборе коммутатора необходимо будет учитывать количество портов на нем,  а также поддержка технологии VLAN. Выход коммутатора будет подключен к коммутатору на Backbone. Скорость обмена между двумя коммутаторами 100Mbps.

Седьмым отделом является отдел тех-поддержки. К нему относятся сотрудники, которые поддерживают работоспособность компьютерной сети всего предприятия. Общее количество сотрудников в данном отделе не будет превышать 2. Кроме сотрудников в сети предусмотрены IP телефония. Данный сегмент сети выделен в отдельный VLAN.  Поэтому, при выборе коммутатора необходимо будет учитывать количество портов на нем,  а также поддержка технологии VLAN. Выход коммутатора будет подключен к коммутатору на Backbone. Скорость обмена между двумя коммутаторами 100Mbps.

Таким образом, на втором этаже предприятия будут следующие отделы:

  •  отдел бухгалтерии;
  •  отдел кадров;
  •  отдел тех-поддержки.

Также в сегменте сети необходимо выделить некоторый набор адресов для серверов общего пользования (DMZ). Поскольку доступ к данным серверам должен быть равноправный, то установим их на Backbone. Так как файловый сервер будет передавать по сети большие объемы данных, то необходимо обеспечить доступ не менее 1Gbps. Такие же требования и к серверу базы данных.

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

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

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

Рисунок 2.22 – План здания на втором этаже

  1.  Разделение сети на сегменты и размещение серверов 

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

Число ПК в каждом помещении выбирается в зависимости от его назначения. Общее число рабочих станций в сети – 80 следовательно, будет целесообразно разделить сеть с помощью коммутаторов на подсети (используя стандарт VLAN). Также к сети относятся сетевые принтеры и IP телефоны.

Как правило, сеть разделяют на демилитаризованную зону и основную приватную сеть c помощью «внешнего» маршрутизатора. Если необходима защита отдельных отделов предприятия от остальных, то дополнительно вводится безопасная внутренняя сеть, которая отделяется от основной приватной сети «внутренним» маршрутизатором.

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

В публичные адреса корпоративной сети были вынесены в кластер сервера: DNS, WEB, файловый сервер,  VoIP.

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

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

Полученная схема сети отображена на рисунке 2.23.

Рисунок 2.23 – Логическая схема ЛВС предприятия «Черниговгазмонтаж»

  1.  Выбор сетевого оборудования 

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

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

Таблица 2.1 – Характеристики витых пар

Наименование

Описание

FTP, 4 пары, кат.5e одножильный

4-е экранированные витые пары с общей оболочкой, полоса частот 125 МГц

UTP, 4 пары, кат 5е, одножильный

4-е неэкранированные витые пары, для передачи на скорости до 1000 Мбит/c, полоса частот 125 МГц

UTP, 2 пары, кат.5e одножильный

2-е неэкранированные витые пары с общей оболочкой, для передачи на скорости до 100 Мбит/c, полоса частот 125 МГц

UTP, 4 пары, кат.6 одножильный

Используется в сетях Fast Ethernet и Gigabit Ethernet, полоса частот 250 МГц

Как можно увидеть из таблицы 2.1 кабель UTP 4 категории 6 имеет полосу частот 250 МГц, используется в сетях Fast Ethernet и Gigabit Ethernet для передачи данных на скорости до 1000 Мбит/c. Использовать этот вид витой пары в данной фирме нерационально.

Поэтому будем использовать витую пару UTP категории 5е, как с 2-мя парами, так и с 4-мя, т.к. для некоторых сегментов необходима пропускная способность до  1 Гбит/c.

Расстояние от соединительного коммутатора до коммутатора в администрации составляет 33м, до коммутатора в отделе инструкторов 2.5м, до коммутатора в отделе менеджеров 8.6м, до коммутатора в отделе управления и транспортировки газа 44м, до коммутатора в бухгалтерии 40м. Для соединения каждого ПК в отделах необходимо взять две бухты по 350м кабеля.

Для прокладки кабелей необходимо около 70 ш. коробов.

Теперь выберем коммутаторы для отделов рабочих групп (таблица 2.2).

Таблица 2.2 – Выбор коммутаторов рабочих групп

Фирма производитель

ZyXEL

D-Link

D-Link

Cisco

Модель

MES-3528

DGS-3016

DES-3028

Catalyst 2960-24LT-L

Количество портов

24х 10/100

BASE-T

4x 1000

BASE-T/SFP

24х 10/100 BASE-TX

24х 10/100 BASE-TX,

2x 10/100/

1000Base-T/SFP

24 x 10/100Base-TX,

2x10/100/1000Base-T/SFP

Консольный порт

RS-232, RJ-45

RS-232,

RJ-45

RS-232,

RJ-45

RS-232

Количество портов (общее)

30

26

28

27

Поддерживаемые стандарты IEEE

802.3x, 802.1p

802.1Q, 802.1d, 802.1s,   802.1w, 802.1x

802.1p,

802.1Q, 802.1d, 802.1w, 802.1x 

802.1p

802.1Q, 802.1d, 802.1w,

802.1s,  802.1x 

802.1p

802.1Q, 802.1d, 802.1w,

802.1s,  802.1x 

Буфер пакетов

448K

256К

512К

384K

Размер таблицы

МАС-адресов

16K

Скорость коммутации кадров, Mpps

9.6

2,3

9.5

6.5

Потребляемая мощность, Вт

20

15

25

123

Цена, грн.

2700

1700

4800

12120

Коммутатор ZyXEL MES-3528 на 28 портов был выбран для перечисленных выше рабочих групп. Цена у данного коммутатора небольшая, есть поддержка стандарта 802.1q, 28 портов, и  удовлетворительная пропускная способность, наличие 4-х портов  с пропускной способностью 1000Mb. Таких коммутаторов нам необходимо 3 шт.

Для отделов бухгалтерия и администрация был выбран коммутатор D-Link DGS-3016, так как для этих отделов не нужны порты с пропускной способностью 1000 Мб.  

Следующим этапом был выбор центрального коммутатора.

К данному коммутатору выдвигаются следующие требования: наличие 6 портов 100Base-T, 2 порта 1000Base-T и одного порта 100Base-FX, а также присутствие достаточно высокой скорости передачи пакетов.

Таблица 2.3 – Выбор центрального коммутатора



Фирма производитель

3COM

D-Link

HP

Cisco

Модель

SuperStack 3 Switch 3824

DES-3528P

ProCurve Switch 2510G-24 (J9279A)

2960 WS-C2960-8TC

Количество портов

24х 10/100/1000

BASE-T, 4x 10/100/1000 BASE/SFP

24x 10/100/1000

BASE-TX, 2x

10/100/1000 BASE-T, 2x 10/100/1000 BASE/SFP

24x 10/100/1000

BASE-TX

8x 10/100/BASE-TX,

1x 10/100/1000 BASE-T, 1x 1000 SPF

Консольный порт

RS-232, RJ-45

RS-232

RS-232, RJ-45

RJ-45

Количество портов (общее)

26

28

26

10

Поддерживае-мые стандарты IEEE

802.1p

802.1Q, 802.1d, 802.1w,

802.1s,  802.1x

802.1p

802.1Q, 802.1d, 802.1w,

802.1s,  802.1x,

802.3ah, 802.3x

802.1p

802.1Q,

802.1s,  802.1x,

802.3ad, 802.3x, 802.1ab

802.1p

802.1Q,

802.1s,  802.1d

Параметры VLAN

До 255 статических групп

До 4K статических групп, до 255 динамических групп

н/а

До 255 статических групп

Буфер пакетов

1Mb

2Mb

1Mb

1Mb

Размер таблицы

МАС-адресов

16K

16К

8К

Скорость коммутации кадров, Mpps

35,7

35,7

23,8

6,5

Потребляемая мощность, Вт

35

30

30

20

Цена, грн.

7900

7450

6500

4440

Так как главным критерием является стоимость и высокая пропускная способность, то для центрального коммутатора был выбран коммутатор D-Link DES-3528P.

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

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

К основным требованиям к внешнему маршрутизатору нужно отнести наличие 4 портов, один из которых будет поддерживать VPN, VLAN, DHCP, возможность обеспечения базовой безопасности от неправомерного доступа из глобальной сети в локальную сеть, поддержка IP-телефонии. Представленные маршрутизаторы поддерживают NAT и фильтрацию MAC/IP адресов.  

 

Таблица 2.4 – Выбор внешнего маршрутизатора

Фирма производитель

Cisco

D-Link

DrayTek

Модель

2811

DI-2630

Vigor 2955

Количество портов (LAN)

2x 10/100 BASE-TX Ethernet

2x 10/100BASE-TX Ethernet

5x 10/100/1000 BASE-T Ethernet

Количество портов (WAN)

4х 10/100Мб

2x 10/100Мб

2x 10/100Мб

Скорость передачи, Gbps

11,6

20

9,6

Объем оперативной памяти, Mb

256

64

н/а

Алгоритмы шифрования

DES, 3DES, AES

DES, 3DES, AES

DES, 3DES, AES

Кол-во VPN-туннелей, max

300

300

200

Маршрутизация

Static routing

RIP v1, v2

OSPF v1, v2

BGP-4

IP Multicasting

Static routing

RIP v1, v2

OSPF v1, v2

BGP-4

IP Multicasting

RIP v2

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

Telnet,

SNMP 3,

HTTP,

HTTPS

SNMP v1, v2, v3

Telnet

HTTP

SNMP

Telnet

HTTP

Потребляемая мощность, Вт

80

50

48

Цена, грн

12 800

12 770

2840

Поскольку главными критериями при выборе внешнего маршрутизатора была стоимость и высокая пропускная способность, то был выбран маршрутизатор D-Link DI-2630.

Далее был произведен выбор «внутреннего» маршрутизатора.

К основным требованиям нужно отнести наличие 2 портов и специализированного файрвола, позволяющего произвести надлежащую защиту отдела бухгалтерии, фильтрацию MAC/IP-адресов и наличие NAT.

Таблица 2.5 – Выбор внутреннего маршрутизатора

Фирма производитель

D-Link

Cisco

3COM

Модель

DFL-260

815

3040

Количество портов

4 порта 10/100BASE-TX Ethernet

4 порта 10/100BASE-TX Ethernet

4 порта 10/100BASE-TX Ethernet

Скорость передачи, Gbps

8

16

8

Объем оперативной памяти, Mb

0.512 на устройство

64

64

Алгоритмы шифрования

DES, 3DES, Twofish, Blowfish, CAST-128

DES, AES, Triple DES

DES

Методы аутентификации

MD5, SHA-1

MD5

–

Кол-во IPSec-туннелей, max

100

50

10

Маршрутизация

IGMP v1, v2, v3

RIP v1, RIP v2

RIP v1, RIP v2, OSPF

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

SNMP

HTTP, SNMP, Telnet, RMON

HTTP, Telnet

Потребляемая мощность, Вт

30

35

32

Цена, грн

4200

4800

3500

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

Далее произведем выбор сетевых адаптеров (таблица 2.6).

Таблица 2.6 – Выбор сетевых адаптеров

Фирма производитель

3COM

Intel

D-Link

Zyxel

Модель

3C2000-T

Pro/1000 G

DFE-528T

GN680-T

Цена, у.е.

14

16

7

12

Пропускная способность

10/100/1000

10/100/1000

10/100/1000

10/100/1000

Светодиодные индикаторы

10-100/1000

Link/Activity

Link/Activity

/100Tx

Link/Activity

Link/Activity

Wake-On-LAN

+

+

+ v2.0

+ v2.2

Сетевой чип

3Com 920-ST06

Intel 82551QM

D-Link DL10038C

GN680-T

Поддержка SNMP/DMI, WfM

+

+

        -

+

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

Наилучшие результаты принадлежат сетевым контроллерам Intel и 3Com. Они используют так называемые «адаптивные технологии», позволяющие регулировать объем, передаваемой в сети, информации и величину задержки с тем, чтобы максимально полно использовать возможности конкретного окружения и достигать наибольшей общей пропускной способности сети. Но поскольку их цена почти в два раза больше да DFE-528, то в качестве сетевого адаптера будет выбран он.

Большой вред работе сети может нанести отключение электропитания или значительное падение напряжения в сети. Ведь если сбой электропитания произойдет во время записи данных на диск, файл может оказаться испорченным. Для защиты данных в случае возникновения таких ситуаций в ЛВС применяются источники бесперебойного питания. ИБП – это устройство, основным элементом которого является аккумуляторная батарея. При отключении питания или при резком падении напряжения необходимый уровень напряжения поддерживается ИБП. Батареи ИБП непрерывно подзаряжаются от внешней электросети. Даже в случае отключения питания в сети ИБП способен сохранять работоспособность компьютера в течение длительного периода времени. Этот период зависит от мощности, потребляемой компьютером, и от мощности ИБП, которая измеряется в вольт-амперах. Так, ИБП мощностью 600 ВА может автономно поддерживать работу 300 Вт компьютера примерно в течение двадцати минут.

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

Наиболее оптимальные вариант это использование источника бесперебойного питания UPS 400VA PowerCom <BNT 400A>, стоимость которого равна 400 грн.

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

Таблица 2.7- Стоимость монтажного оборудования

Фирма производитель

Описание

Ед. измерен.

Кол-во

Стоимость за единицу, грн/м

Сумма, грн

Efapel

Кабельный канальный короб пластиковый 40х25mm

шт

70

4,18

1463

Efapel

Заглушка для короба 40х25mm

шт

25

4

100

Efapel

Внешний угол для канала 80х50mm

шт

70

3

210

PCNet

Розетка внешняя настенная UTP 1 порт RJ45 категории 5е

шт

70

8

480

PCNet

Коннектор разъем вилка RJ45 под UTP категории 5е

шт

70

0,5

35

MOLEX

Кабель UTP cat. 5E 305м

шт

2

271

542

Всего, грн.

2779

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

Следуя изложенным требованиям, подобран сервер с параметрами, представленными в таблице 2.8.

Таблица 2.8- Для Web-сервера, DNS-сервера и сервера БД

Процессор

Материнская плата

ОЗУ, МБ

НЖМД, ГБ

Цена

Гарантия

Intel Core 2 Duo 2.0 Ghz

ASUS P5N-MX

Apacer DDR2 SDRAM 1024Mb

Samsung HD160JJ/HJ/161HJ

160Gb

250$

36 мес

 

Таблица 2.9- Для файлового сервера

Процессор

Материнская плата

ОЗУ, МБ

НЖМД, ГБ

Цена

Гарантия

Intel Core 2 Duo 2.0 Ghz

ASUS P5N-MX

Apacer DDR2 SDRAM 2048Mb

Samsung HD501LJ

500Gb

340$

36 мес

Для данной ЛВС необходим 1 Web-сервер, 1 сервер БД, 1 файл-сервер, 1 DNS-сервер.

  1.  Моделирование ЛВС

Моделирование сети было произведено с помощью утилиты PacketTraser5.0 – бесплатный эмулятор сетевой среды, выпускаемый фирмой Cisco, который позволяет делать работоспособные модели сети, настраивать (командами ICSO IOS) маршрутизаторы и коммутаторы, взаимодействовать между несколькими пользователями. Включает в себя серии маршрутизаторов Cisco 1800, 2600, 2800 и коммутаторов 2950, 2960, 3650. Кроме того есть серверы DHCP, HTTP, TFTP, FTP, TIME, рабочие станции, различные модули к компьютерам и маршрутизаторам, устройства WiFi, различные кабели.

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

Рисунок 2.27 – Модель сети

Листинг проверки правильности работы с моделированной сети приведен в листинге 2.6.

Листинг 2.6 – Проверка корректности работы сети

FROM 192.158.1.35

PC>tracert 192.168.0.3

Tracing route to 192.168.0.3 over a maximum of 30 hops:

 1   110 ms    85 ms     109 ms    192.168.1.33

 2   110 ms    98 ms     109 ms    192.168.3.2

 3   109 ms    204 ms    127 ms    192.168.0.3

Trace complete.

PC>tracert 172.17.197.2

Tracing route to 172.17.197.2 over a maximum of 30 hops:

 1   47 ms     46 ms     94 ms     192.168.1.33

 2   78 ms     110 ms    151 ms    192.168.3.2

 3   141 ms    156 ms    188 ms    172.17.197.2

Trace complete.

PC>ping 192.168.1.98

Pinging 192.168.1.98 with 32 bytes of data:

Reply from 192.168.1.98: bytes=32 time=172ms TTL=127

Reply from 192.168.1.98: bytes=32 time=172ms TTL=127

Reply from 192.168.1.98: bytes=32 time=143ms TTL=127

Reply from 192.168.1.98: bytes=32 time=171ms TTL=127

Ping statistics for 192.168.1.98:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 143ms, Maximum = 172ms, Average = 164ms

PC>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Reply from 192.168.1.2: bytes=32 time=141ms TTL=127

Reply from 192.168.1.2: bytes=32 time=109ms TTL=127

Reply from 192.168.1.2: bytes=32 time=140ms TTL=127

Reply from 192.168.1.2: bytes=32 time=156ms TTL=127

Ping statistics for 192.168.1.2:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 109ms, Maximum = 156ms, Average = 136ms

FROM 192.168.1.98

PC>tracert 192.168.0.2

Tracing route to 192.168.0.2 over a maximum of 30 hops:

 1   64 ms     94 ms     93 ms     192.168.1.97

 2   93 ms     98 ms     93 ms     192.168.3.2

 3   172 ms    156 ms    220 ms    192.168.0.2

Trace complete.

PC>tracert 172.17.197.2

Tracing route to 172.17.197.2 over a maximum of 30 hops:

 1   63 ms     49 ms     94 ms     192.168.1.97

 2   94 ms     93 ms     125 ms    192.168.3.2

 3   125 ms    156 ms    127 ms    172.17.197.2

Trace complete.

PC>ping 192.168.1.131

Pinging 192.168.1.131 with 32 bytes of data:

Reply from 192.168.1.131: bytes=32 time=157ms TTL=127

Reply from 192.168.1.131: bytes=32 time=143ms TTL=127

Reply from 192.168.1.131: bytes=32 time=172ms TTL=127

Reply from 192.168.1.131: bytes=32 time=220ms TTL=127

Ping statistics for 192.168.1.131:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 143ms, Maximum = 220ms, Average = 173ms

PC>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Reply from 192.168.1.2: bytes=32 time=63ms TTL=127

Reply from 192.168.1.2: bytes=32 time=143ms TTL=127

Reply from 192.168.1.2: bytes=32 time=138ms TTL=127

Reply from 192.168.1.2: bytes=32 time=174ms TTL=127

Ping statistics for 192.168.1.2:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 63ms, Maximum = 174ms, Average = 129ms

FROM 192.168.1.66

PC>tracert 172.17.197.2

Tracing route to 172.17.197.2 over a maximum of 30 hops:

 1   46 ms     94 ms     47 ms     192.168.1.65

 2   144 ms    156 ms    203 ms    192.168.3.2

 3   203 ms    143 ms    204 ms    172.17.197.2

Trace complete.

PC>ping 192.168.1.34

Pinging 192.168.1.34 with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 192.168.1.34:

   Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

FROM 192.168.1.130

PC>tracert 192.168.0.3

Tracing route to 192.168.0.3 over a maximum of 30 hops:

 1   94 ms     78 ms     64 ms     192.168.1.129

 2   110 ms    110 ms    125 ms    192.168.3.2

 3   143 ms    158 ms    94 ms     192.168.0.3

Trace complete.

PC>tracert 172.17.197.2

Tracing route to 172.17.197.2 over a maximum of 30 hops:

 1   49 ms     80 ms     65 ms     192.168.1.129

 2   111 ms    67 ms     94 ms     192.168.3.2

 3   141 ms    141 ms    78 ms     172.17.197.2

Trace complete.

PC>ping 192.168.1.162

Pinging 192.168.1.162 with 32 bytes of data:

Reply from 192.168.1.162: bytes=32 time=143ms TTL=127

Reply from 192.168.1.162: bytes=32 time=174ms TTL=127

Reply from 192.168.1.162: bytes=32 time=156ms TTL=127

Reply from 192.168.1.162: bytes=32 time=188ms TTL=127

Ping statistics for 192.168.1.162:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 143ms, Maximum = 188ms, Average = 165ms

PC>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Reply from 192.168.1.2: bytes=32 time=78ms TTL=127

Reply from 192.168.1.2: bytes=32 time=125ms TTL=127

Reply from 192.168.1.2: bytes=32 time=137ms TTL=127

Reply from 192.168.1.2: bytes=32 time=141ms TTL=127

Ping statistics for 192.168.1.2:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 78ms, Maximum = 141ms, Average = 120ms

FROM 192.168.1.162

PC>tracert 192.168.0.3

Tracing route to 192.168.0.3 over a maximum of 30 hops:

 1   64 ms     109 ms    63 ms     192.168.1.161

 2   125 ms    97 ms     62 ms     192.168.3.2

 3   109 ms    157 ms    188 ms    192.168.0.3

Trace complete.

PC>tracert 172.17.197.2

Tracing route to 172.17.197.2 over a maximum of 30 hops:

 1   79 ms     78 ms     94 ms     192.168.1.161

 2   78 ms     111 ms    110 ms    192.168.3.2

 3   125 ms    109 ms    78 ms     172.17.197.2

Trace complete.

PC>

PC>ping 192.168.1.98

Pinging 192.168.1.98 with 32 bytes of data:

Reply from 192.168.1.98: bytes=32 time=140ms TTL=127

Reply from 192.168.1.98: bytes=32 time=156ms TTL=127

Reply from 192.168.1.98: bytes=32 time=129ms TTL=127

Reply from 192.168.1.98: bytes=32 time=105ms TTL=127

Ping statistics for 192.168.1.98:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 105ms, Maximum = 156ms, Average = 132ms

PC>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Reply from 192.168.1.2: bytes=32 time=143ms TTL=127

Reply from 192.168.1.2: bytes=32 time=94ms TTL=127

Reply from 192.168.1.2: bytes=32 time=141ms TTL=127

Reply from 192.168.1.2: bytes=32 time=140ms TTL=127

Ping statistics for 192.168.1.2:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 94ms, Maximum = 143ms, Average = 129ms

Далее приведем листинги файлов конфигураций сетевого оборудования.

Листинг 2.7 – Файл конфигурации «внутреннего» маршрутизатора

!

version 12.4

no service timestamps log datetime msec

no service timestamps debug datetime msec

no service password-encryption

!

hostname Router

!

ip dhcp pool P1

network 192.168.1.32 255.255.255.224

default-router 192.168.1.33

dns-server 192.168.1.195

ip dhcp pool P2

network 192.168.1.96 255.255.255.224

default-router 192.168.1.97

dns-server 192.168.1.195

ip dhcp pool P3

network 192.168.1.64 255.255.255.224

default-router 192.168.1.65

dns-server 192.168.1.195

ip dhcp pool P4

network 192.168.1.128 255.255.255.224

default-router 192.168.1.129

dns-server 192.168.1.195

ip dhcp pool P5

network 192.168.1.160 255.255.255.224

default-router 192.168.1.161

dns-server 192.168.1.195

!

!

interface FastEthernet0/0

ip address 192.168.1.254 255.255.255.224

duplex auto

speed auto

!

interface FastEthernet0/0.1

encapsulation dot1Q 3

ip address 192.168.1.33 255.255.255.224

!

interface FastEthernet0/0.2

encapsulation dot1Q 5

ip address 192.168.1.97 255.255.255.224

!

interface FastEthernet0/0.3

encapsulation dot1Q 6

ip address 192.168.1.129 255.255.255.224

!

interface FastEthernet0/0.4

encapsulation dot1Q 7

ip address 192.168.1.161 255.255.255.224

!

interface FastEthernet0/0.5

encapsulation dot1Q 8

ip address 192.168.1.193 255.255.255.224

!

interface FastEthernet0/1

ip address 192.168.3.1 255.255.255.252

duplex auto

speed auto

!

interface FastEthernet1/0

no ip address

duplex auto

speed auto

!

interface Vlan1

no ip address

shutdown

!

router rip

network 192.168.1.0

network 192.168.3.0

!

ip classless

!

!

line con 0

line vty 0 4

 login

!

!

!

end

Листинг 2.8 – Файл конфигурации «внешнего» маршрутизатора

!

version 12.4

no service timestamps log datetime msec

no service timestamps debug datetime msec

no service password-encryption

!

hostname Router

!

!

interface FastEthernet0/0

ip address 192.168.3.2 255.255.255.252

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 172.17.197.1 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet1/0

ip address 192.168.0.1 255.255.255.224

duplex auto

speed auto

!

interface Vlan1

no ip address

shutdown

!

router rip

network 172.17.0.0

network 192.168.0.0

network 192.168.3.0

!

ip classless

!

!

line con 0

line vty 0 4

 login

!

!

!

end

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

Листинг 2.9 –Текст конфигурационного файла named.conf:

options {

directory  "/var/lib/chroot/var/named";

recursion yes;

forward first;

forwarders {

     

 };

};

//домен "."

zone "." IN {

type hint;

file "named.ca";

};

include "/etc/named.rfc1912.zones";

zone "general" IN {

   type master;

   file "masters/db.general";

   //ограничение ответа на запросы для данной зоны

 allow- query{

192.168.1.0/27;

192.168.1.32/27;

192.168.1.64/27;

192.168.1.96/27;

192.168.1.128/27;

192.168.1.160/27;

   };

};

zone "byh" IN {

   type master;

   file "masters/db.byh";

   //ограничение полной перекачки данной зоны

 allow-query{

 192.168.1.64/27;

   };

};

zone "dmz" IN {

type master;

file "masters/db.dmz";

allow-query  {

192.168.1.0/27;

192.168.1.32/27;

192.168.1.64/27;

192.168.1.96/27;

192.168.1.128/27;

192.168.1.160/27;

};

};

//обратная зона

zone "0.168.192.in-addr.arpa"{

   type master;

   file "masters/db.1.168.192";

   allow-query{

192.168.1.32/27;

192.168.1.64/27;

192.168.1.96/27;

192.168.1.128/27;

192.168.1.160/27;

   };

};

zone "1.168.192.in-addr.arpa"{

   type master;

   file "masters/db.1.168.192";

   allow-query{

192.168.1.64/24;

   };

};

zone "2.168.192.in-addr.arpa"{

type master;

file "masters/db.2.168.192.in-addr.arpa";

};

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

Листинг 2.10 –Текст файла db.general:

$TTL 28800  ;TTL по умолчанию

$ORIGIN . ;суффикс

;основной сервер имен для данной зоны

general IN   SOA ns.webmaker dnsmaster.general. (

                            2011112701; серийный номер файла

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

    7200      ; время, через которое  ;вторичные сервера должны совершать повторную попытку

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

    86400)    ; Time to Live

;авторитетные сервера

 IN NS ns.webmaker. ;первичный сервер

;адреса авторитетных серверов

ns.general IN A 192.168.1.1

;адреса хостов зоны

$ORIGIN general.//суффикс

fs   IN A 192.168.1.2

dns   IN A 192.168.1.3

db   IN A 192.168.1.4

voip   IN A 192.168.1.5

Листинг 2.11 –Текст файла db. byh:

$TTL 28800  ;TTL по умолчанию

$ORIGIN . ;суффикс

;основной сервер имен для данной зоны

admin_byh IN   SOA ns.admin_byh dnsmaster.admin_byh. (

                            20011112701; серийный номер файла

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

    7200      ; время, через которое  ;вторичные сервера должны совершать повторную попытку

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

    86400)    ; Time to Live

;авторитетные сервера

 IN NS ns.admin_byh. ;первичный сервер

;адреса авторитетных серверов

ns.byh IN A 192.168.1.65

;адреса хостов зоны

$ORIGIN admin_byh.//суффикс

telephone IN  A 192.168.1.68

printer_byh IN  A 192.168.1.69

fs   IN A 192.168.1.2

dns   IN A 192.168.1.3

db   IN A 192.168.1.4

voip   IN A 192.168.1.5

Листинг 2.12 –Текст файла db.dmz:

$TTL 28800  ;TTL по умолчанию

$ORIGIN . ;суффикс

;основной сервер имен для данной зоны

dmz IN   SOA ns.admin_byh dnsmaster.dmz. (

                            2011112701; серийный номер файла

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

    7200      ; время, через которое  ;вторичные сервера должны совершать повторную попытку

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

    86400)    ; Time to Live

;авторитетные сервера

 IN NS ns.dmz. ;первичный сервер

;адреса авторитетных серверов

ns.dmz IN A 192.168.0.1

;адреса хостов зоны

$ORIGIN dmz.//суффикс

web   IN  A 192.168.0.2

mail  IN  A 192.168.0.3

Листинг 2.13 –Текст файла db.2.168.192.in-addr.arpa:

$TTL 28800

$ORIGIN .

2.168.192.in-addr.arpa IN SOA ns.general. dnsmaster. general. (

 2011092601

  86400

  14400

  3600000

  345600 )

IN NS ns.general.

$ORIGIN 2.168.192.IN-ADDR.ARPA.

2 IN PTR fs.general.

3 IN PTR dns.general.

4 IN PTR db.general.

5 IN PTR voip.general.

Листинг 2.14 –Текст файла db.1.168.192.in-addr.arpa:

$TTL 28800

$ORIGIN .

1.168.192.in-addr.arpa IN SOA ns.admin_byh. dnsmaster.admin_byh. (

 2011092601

  86400

  14400

  3600000

  345600 )

IN NS ns.admin_byh.

$ORIGIN 1.168.192.IN-ADDR.ARPA.

68 IN PTR telephone.admin_byh.

69 IN PTR printer_byh.admin_byh.

$ORIGIN 2.168.192.IN-ADDR.ARPA.

2 IN PTR fs.general.

3 IN PTR dns.general.

4 IN PTR db.general.

5 IN PTR voip.general.

Листинг 2.15 –Текст файла db.0.168.192.in-addr.arpa:

$TTL 28800

$ORIGIN .

.0.168.192.in-addr.arpa IN SOA ns.dmz. dnsmaster.dmz. (

 2011092601

  86400

  14400

  3600000

  345600 )

IN NS ns.dmz.

$ORIGIN 0.168.192.IN-ADDR.ARPA.

2 IN PTR web.dmz.

3 IN PTR mail.dmz.


  1.  Реализация системы 
    1.  Результат реализации базы данных

Таблица «user»  предназначена для хранения информации о пользователе системы. Она содержит поля, описанные в таблице 3.1.

Таблица 3.1 – Описание полей таблицы «user»

Название колонки

Тип даних

Описание

Ограничение

id

int

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

not null

fio

varchar(20)

ФИО пользователя

not null

login

varchar(15)

логин пользователя

not null

passwd

varchar(10)

пароль пользователя

not null

address

varchar(15)

адрес пользователя

not null

phone

int

рабочий телефон

not null

Таблица «Library»  предназначена для хранения информации о библиотеки.  Она содержит поля, описанные в таблице 3.2.

Таблица 3.2 – Описание полей таблицы «Library»

Название колонки

Тип даних

Описание

Ограничение

id

int

уникальный идентификатор, первичный ключ

not null

name

varchar(15)

название

not null

discription

varchar(20)

описание библиотеки

not null

owner

varchar(25)

пользователь – владелец библиотеки

not null

creationdate

date

дата создания библиотеки

not null

id_users

int

внешний ключ для связи с таблицей «user»

not null

Таблица «role»  предназначена для хранения типов ролей пользователей системы.  Данная таблица содержит поля, описанные в таблице 3.3.

Таблица 3.3 – Описание полей таблицы «role»

Название колонки

Тип даних

Описание

Ограничение

id

int

уникальный идентификатор, первичный ключ

not null

role

varchar(12)

роль пользователя

not null

id_users

int

внешний ключ для связи с таблицей «user»

not null

Таблица «folder»  предназначена для хранения необходимой информации о каталоге. Данная таблица содержит поля, описанные в таблице 3.4.

Таблица 3.4 – Описание полей таблицы «folder»

Название колонки

Тип даних

Описание

Ограничение

id

int

уникальный идентификатор, первичный ключ

not null

name

varchar(20)

название каталога

not null

discription

varchar(20)

описание каталога

not null

owner

varchar(25)

пользователь – владелец каталога

not null

creationdate

date

дата создания каталога

not null

id_users

int

внешний ключ для связи с таблицей «user»

not null

Таблица «document»  предназначена для хранения информации о документе. Данная таблица содержит поля, описанные в таблице 3.5.

Таблица 3.5 – Описание полей таблицы «document»

Название колонки

Тип даних

Описание

Ограничение

id

int

уникальный идентификатор, первичный ключ

not null

discription

varchar(20)

описание документа

not null

owner

varchar(25)

пользователь – владелец документа

not null

creationdate

date

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

not null

id_users

int

внешний ключ для связи с таблицей «user»

not null

id_template

int

внешний ключ для связи с таблицей «template»

not null

Таблица «template»  предназначена для хранения информации о шаблоне. Данная таблица содержит поля, описанные в таблице 3.6.

Таблица 3.6 – Описание полей таблицы «template»

Название колонки

Тип даних

Описание

Ограничение

id

int

уникальный идентификатор, первичный ключ

not null

name

varchar(255)

название шаблона

not null

description

varchar(20)

описание шаблона

not null

creator

varchar(25)

пользователь – создатель шаблона

not null

creationdate

date

дата создания шаблона

not null

id_users

int

внешний ключ для связи с таблицей «user»

not null

Таблица «version»  предназначена для хранения информации об версиях документа. Данная таблица содержит поля, описанные в таблице 3.7.

Таблица 3.7 – Описание полей таблицы «version»

Название колонки

Тип даних

Описание

Ограничение

id

int

первичный ключ уникальный идентификатор

not null

version

int

версия документа

not null

id_document

int

внешний ключ для связи с таблицей «document»

not null

Таблица «documenttype»  предназначена для хранения типов хранимых файлов.  Дання таблица содержит поля, описанные в таблице 3.8.

Таблица 3.8 – Описание полей таблицы «documenttype»

Название колонки

Тип даних

Описание

Ограничение

id

int

уникальный идентификатор, первичный ключ

not null

doctype

varchar(15)

тип хранимого документа

not null

id_template

int

внешний ключ для связи с таблицей «template»

not null

id_document

int

внешний ключ для связи с таблицей «document»

not null

  1.  Диаграмма пакетов

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

Таблица 3.9 – Описание назначений пакетов «document»

Название пакета

Описание

document.config

Данный пакет содержит классы для работы с LDAP сервером и  класс сообщений для LogFactory

document.domain

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

document.service

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

document.service.Impl

Данный пакет содержит классы, которые реализую интерфейсы пакета document.service

document.web.beans

Данный пакет содержит классы, которые используются на web-страницах(JSF-технология)

test.document

Данный пакет содержит классы, для проведения тестов системы с использованием jUnit 4

На рисунке 3.1 представлена диаграмма пакетов ИКС управления документооборотом предприятия «Черниговгазмонтаж».

Рисунок 3.1 – Диаграмма пакетов системы

  1.  Протоколы классов

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

Таблица 3.10 – Протоколы классов пакета document.config

Название класса

Название метода или поля

Описание

MailSender

sendMail(User user)

Метод, для отправления письма определённому пользователю

MailThread

smtpServer

Поле для указания сервера почты

MailThread

to

Поле для указания получателя

MailThread

from

Поле для указания отправителя

MailThread

subject

Поле для указания темы письма

MailThread

login

Поле для указания логина от почты

MailThread

passwd

Поле для указания пароля от почты

MailThread

user

Поле текущего пользователя

MailThread

run()

Метод для отправки письма в потоке

MailThread

getSmtpServer()

Метод для получения поля smtpServer

MailThread

setPasswd(String passwd)

Метод для установки поля passwd

ServiceLDAP

ServiceLDAP()

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

ServiceLDAP

addUser(fields)

Метод, который добавляет пользователя в БД LDAP

ServiceLDAP

assignUser(fields)

Метод, который добавляет пользователя в группу с ролями

ServiceLDAP

getInitialContext

(fields)

Метод для подключения к LDAP

ServiceLDAP

deleteUser(String username)

Метод, который удаляет пользователя из БД LDAP

ServiceLDAP

removeUser(String username, String groupName)

Метод, который удаляет пользователя из группы с ролями

В таблице 3.11 представлены протоколы классов пакета document.domain

Таблица 3.11 – Протоколы классов пакета document.domain

Название класса

Название метода или поля

Описание

DomainObject

id

Поле уникального идентификатора

DomainObject

defLocale

Поле локализации

DomainObject

DomainObject()

Конструктор класса

DomainObject

DomainObject(Long id)

Конструктор класса с указанием id

DomainObject

copyFieldsValuesFrom

(DomainObject obj)

Метод для копирования полей другого объекта

DomainObject

hashCode()

Метод формирования hesh-кода объекта

DomainObject

equals(Object obj)

Метод для сравнения с объектом

DomainObject

toString()

Метод для преобразования объекта в тип String

Document

id_document

Поле уникального идентификатора документа

Document

name

Поле названия документа

Document

Document ()

Конструктор класса без параметров

Document

Document (fields)

Конструктор класса с полями для инициализации

Document

creationdata

Поле даты создания документа

Document

owner

Поле создателя документа

Document

description

Поле  описания документа

Document

Document ()

Конструктор класса без параметров

Document

Document (fields)

Конструктор класса с полями для инициализации

Document

userClient

Поле с указанием клиента

DocumentServices

DocumentServices()

Конструктор класса без параметров

DocumentServices

DocumentServices

(fields)

Конструктор класса с полями для инициализации

Template

id_template

Поле уникального идентификатора шаблона

Template

name

Поле с название шаблона

Template

description

Описание шаблона

Template

сreator

Пользователь – создатель шаблона

Template

creationdata

Поле даты создания шаблона

Template

Template ()

Конструктор класса без параметров

Template

Template (fields)

Конструктор класса с полями для инициализации

Documenttype

id_doctype

Поле уникального идентификатора

Documenttype

name

Поле с названием документа

Documenttype

doctype

Поле с типом документа

Documenttype

user

Поле с указанием пользователя

Documenttype

Documenttype ()

Конструктор класса без параметров

Documenttype

Documenttype (fields)

Конструктор класса с полями для инициализации

Library

id_library

Поле уникального идентификатора библиотеки

Library

name

Поле с названием библиотеки

Library

creationdata

Поле даты создания библиотеки

Library

owner

Поле создателя библиотеки

Library

description

Поле  описания библиотеки

Library

Library ()

Конструктор класса без параметров

Library

Library (fields)

Конструктор класса с полями для инициализации

Folders

id_folders

Поле уникального идентификатора каталога

Folders

name

Поле с название каталога

Folders

creationdata

Поле даты создания каталога

Folders

owner

Поле создателя каталога

Folders

description

Поле  описания каталога

Folders

Folders

Конструктор класса без параметров

Folders

Folders(fields)

Конструктор класса с полями для инициализации

Role

id_role

Поле уникального идентификатора роли

Role

rolename

Поле с названием роли

Role

user

Поле с указанием пользователя

Role

Role()

Конструктор класса без параметров

Role

Role (fields)

Конструктор класса с полями для инициализации

Version

id_version

Поле уникального идентификатора версии документа

Version

name

Поле с именем версии

Version

Version ()

Конструктор класса без параметров

Version

Version (fields)

Конструктор класса с полями для инициализации

User

id_user

Поле уникального идентификатора пользователя

User

login

Поле с логином

User

passwd

Поле с паролем

User

info

Поле с профилем

User

role

Поле с ролью пользователя

User

User()

Конструктор класса без параметров

User

User(fields)

Конструктор класса с полями для инициализации

В таблице 3.12 представлены протоколы классов пакета document.service

Таблица 3.12 – Протоколы классов пакета document.service

Название класса

Название метода или поля

Описание

IUserService

findUser (String fio)

Описание метода поиска пользователя по его логину

IUserService

listUsers ()

Описание метода получения списка всех пользователей

IUserService

registerUser (Integer id_user)

Описание метода регистрации пользователя в системе

IUserService

removeUser (Integer id_user)

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

ILibraryService

newLibrary (Integer id_library, String name)

Описание метода создания библиотеки

ILibraryService

removeLibrary (Integer id_library)

Описание метода удаления библиотеки

ILibraryService

listFolders (Integer id_library)

Описание метода получения списка каталогов

ILibraryService

addFolder (Integer id_library, String name)

Описание метода для добавления каталога

ILibraryService

removeFolder (Integer id_library, String name)

Описание метода для удаления каталога

ILibraryService

addUser (Integer id_library, Integer id_user)

Описание метода добавления пользователя в список пользователей библиотеки

ILibraryService

removeUser (Integer id_library, Integer id_user)

Описание метода для удаления пользователя из списка пользователей библиотеки

ILibraryService

listUsers(Integer id_library, Integer id_user)

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

ILibraryService

getLibraryAttribute (Integer id_library)

Описание метода для получения атрибута библиотеки

ILibraryService

setLibraryAttribute(Integer id_library)

Описание метода установления атрибутов библиотеки

IFolderService

newFolder(Integer id_user, String name)

Описание метода установления атрибутов библиотеки

IFolderService

removeFolder(Integer id_folder)

Описание метода установления атрибутов библиотеки

IFolderService

getFolderAttribute (Integer id_folder)

Описание метода установления атрибутов библиотеки

IDocumentService

findDocuments(Integer id_document)

Описание метода поиска документа

IDocumentService

newDocuments (Integer id_user, String name)

Описание метода создания документа

IDocumentService

retrieveLastDocumentsVersion (Integer id_document)

Описание метода для получения последней версии документа

IDocumentService

retrieveDocumentsVersion(Integer id_document)

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

IDocumentService

getDocumentsTemplateId (Integer id_document)

Описание метода получения шаблона документа

IDocumentService

listDocumentsVersions (Integer id_document)

Описание метода для получения списка версий

IDocumentService

createNewVersion (Integer id_document)

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

IGenericService

delEntity(id)

Описание метода удаления объекта по id

IGenericService

delEntity(entity)

Описание метода удаления объекта c БД

IGenericService

delAllEntities()

Описание метода удаления коллекции объектов

IGenericService

getEntityById()

Описание метода получения объекта по id

IGenericService

getAllEntites()

Описание метода получения всех объектов

IGenericService

getAllEntitiesCount()

Описание метода получения количества объектов

IGenericService

getEntitiesByIds()

Описание метода получения объектов по нескольким id

IGenericService

save(entity)

Описание метода сохранения объекта в БД

В таблице 3.13 представлены протоколы классов пакета document.service.Impl

Таблица 3.13 – Протоколы классов пакета document.service.Impl

Название класса

Название метода или поля

Описание

UserService

findUser (String fio)

Метод поиска пользователя по его логину

UserService

listUsers ()

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

UserService

registerUser (Integer id_user)

Метод регистрации пользователя в системе

UserService

removeUser (Integer id_user)

Метод удаления пользователя из системы

LibraryService

newLibrary (Integer id_library, String name)

Метод создания библиотеки

LibraryService

removeLibrary (Integer id_library)

Метод удаления библиотеки

LibraryService

listFolders (Integer id_library)

Метод получения списка каталогов

LibraryService

addFolder (Integer id_library, String name)

Метод для добавления каталога

LibraryService

removeFolder (Integer id_library, String name)

Метод для удаления каталога

LibraryService

addUser (Integer id_library, Integer id_user)

Метод добавления пользователя в список пользователей библиотеки

LibraryService

removeUser (Integer id_library, Integer id_user)

Метод для удаления пользователя из списка пользователей библиотеки

LibraryService

listUsers(Integer id_library, Integer id_user)

Метод для получения всех пользователей библиотеки

LibraryService

getLibraryAttribute (Integer id_library)

Метод для получения атрибута библиотеки

LibraryService

setLibraryAttribute(Integer id_library)

Метод установления атрибутов библиотеки

FolderService

newFolder(Integer id_folder, String name)

Метод создания нового каталога

FolderService

removeFolder(Integer id_folder)

Метод удаления каталога

FolderService

getFolderAttribute (Integer id_folder)

Метод получения атрибутов каталога

DocumentService

findDocuments(Integer id_document)

Метод поиска документа

DocumentService

newDocuments (Integer id_document, String name)

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

DocumentService

retrieveLastDocumentsVersion (Integer id_document)

Метод для получения последней версии документа

DocumentService

retrieveDocumentsVersion(Integer id_document)

Метод для получения указанной версии документа

DocumentService

getDocumentsTemplateId (Integer id_document)

Метод получения шаблона документа

DocumentService

listDocumentsVersions (Integer id_document)

Метод для получения списка версий

DocumentService

createNewVersion (Integer id_document)

Метод для создания новой версии документа

GenericService

delEntity(id_document)

Метод удаления объекта по id

GenericService

delEntity(entity)

Метод удаления объекта c БД

GenericService

delAllEntities()

Метод удаления коллекции объектов

GenericService

getEntityById()

Метод получения объекта по id

GenericService

getAllEntites()

Метод получения всех объектов

GenericService

getAllEntitiesCount()

Метод получения количества объектов

GenericService

getEntitiesByIds()

Метод получения объектов по нескольким id

GenericService

save(entity)

Метод сохранения объекта в БД

В таблице 3.14 представлены протоколы классов пакета document.web.bean

Таблица 3.14 – Протоколы классов пакета document.web.bean

Название класса

Название метода или поля

Описание

UserBean

login

Поле с логином

UserBean

passwd

Поле с паролем

UserBean

info

Поле с профилем

UserBean

role

Поле с ролью пользователя

UserBean

dofindUser ()

Метод поиска пользователя по его логину

UserBean

dolistUsers ()

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

UserBean

doregisterUser ()

Метод регистрации пользователя в системе

UserBean

doremoveUser ()

Метод удаления пользователя из системы

LibraryBean

name

Поле с текстом комментария

LibraryBean

creationdata

Поле даты создания библиотеки

LibraryBean

owner

Поле создателя библиотеки

LibraryBean

description

Поле  описания библиотеки

LibraryBean

donewLibrary ()

Метод создания библиотеки

LibraryBean

doremoveLibrary ()

Метод удаления библиотеки

LibraryBean

dolistFolders ()

Метод получения списка каталогов

LibraryBean

doaddFolder ()

Метод для добавления каталога

LibraryBean

doremoveFolder ()

Метод для удаления каталога

LibraryBean

doaddUser ()

Метод добавления пользователя в список пользователей библиотеки

LibraryBean

doremoveUser ()

Метод для удаления пользователя из списка пользователей библиотеки

LibraryBean

dolistUsers()

Метод для получения всех пользователей библиотеки

LibraryBean

dogetLibraryAttribute ()

Метод для получения атрибута библиотеки

LibraryBean

dosetLibraryAttribute()

Метод установления атрибутов библиотеки

FolderBean

name

Поле с название каталога

FolderBean

creationdata

Поле даты создания каталога

FolderBean

owner

Поле создателя каталога

FolderBean

description

Поле  описания каталога

FolderBean

donewFolder()

Метод создания нового каталога

FolderBean

doremoveFolder()

Метод удаления каталога

FolderBean

dogetFolderAttribute ()

Метод получения атрибутов каталога

DocumentBean

name

Поле названия документа

DocumentBean

creationdata

Поле даты создания документа

DocumentBean

owner

Поле создателя документа

DocumentBean

description

Поле  описания документа

DocumentBean

dofindDocuments()

Метод поиска документа

DocumentBean

donewDocuments ()

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

DocumentBean

doretrieveLastDocumentsVersion ()

Метод для получения последней версии документа

DocumentBean

doretrieveDocumentsVersion()

Метод для получения указанной версии документа

DocumentBean

dogetDocumentsTemplateId ()

Метод получения шаблона документа

DocumentBean

dolistDocumentsVersions ()

Метод для получения списка версий

DocumentBean

docreateNewVersion ()

Метод для создания новой версии документа

  1.  Диаграмма развертывания ИКС

На рисунке 3.5 представлена диаграмма развертывания ИКС.  

Для сборки проекта использовалась система автоматизированной сборки Ant. Для сборки проекта необходимо выполнить  команду ant build.xml install в каталоге проекта.

Рисунок 3.5 – Диаграмма развертывания ИКС

  1.  Реализация интерфейса пользователя

В процессе разработки пользовательского интерфейса (бумажного, компьютерного) были выделены отдельные страницы веб-интерфейса, такие как: главная страница с модулем логирования и модулем регистрации; страницы для добавления документа, просмотра библиотеки. В зависимости от роли пользователя, ему разрешаются те или иные операции. Было спроектировано множество страниц просмотра, добавления и редактирования, удаления документации, страницы профиля, и регистрации.   

Ниже приведен окончательный вариант пользовательского интерфейса.

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

 

Рисунок 3.6 – Гостевая страница предприятия «Черниговгазмонтаж»

Для выполнения входа необходимо ввести логин и пароль и нажать кнопку «Войти». Если пользователь не зарегистрирован, он должен нажать кнопку «Регистрация». Окно ввода логина и пароля имеет следующий вид (Рисунок 3.7).

Рисунок 3.7 – Окно входа/регистрации системы

 Окно регистрации системы предлагает выполнить регистрацию или же войти в систему. Внешний вид этого модуля представляется на рисунке 3.8.

Рисунок 3.8 – Окно регистрации

Для перехода на страницу для просмотра документов необходимо ввести логин и пароль, нажать кнопку «Войти» и тогда откроется страница пользователя(Рисунок 3.9).

Рисунок 3.9 – Страница просмотра содержимого библиотеки

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

Рисунок 3.10 – Открытия документа

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

Рисунок 3.11 – Сохранения документа

Тестирование пользовательского интерфейса отеля производилось на студентах ФЭИТ.  Были поставлены задачи по трём основным сценариям работы:

  •  регистрация;
  •  просмотр сведений о документе;
  •  добавление нового документа.

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

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

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

В результате тестирования все недостатки были убраны.

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


  1.  Охрана труда 
    1.  Общие положения к организации работы с визуальными дисплеями и терминалами персональных компьютеров (ВДТ ПК)

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

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

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

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

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

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

  •  гигиенической оценки их безопасности для здоровья человека;
  •  согласования нормативной и технической документации на эти виды данной продукции с органами Госсанэпиднадзора Украины;
  •  получения гигиенического сертификата в соответствии с установленными требованиями.

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

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

Государственный санитарно-эпидемиологический надзор за новыми (модернизированными) ВДТ и ПЭВМ осуществляется на этапах их разработки, постановки на производство, в процессе производства, закупки по импорту и применения в соответствии с «Методическими указаниями по организации и проведению государственного санитарно-эпидемиологического надзора за новой продукцией и технологией ее производства», утвержденными Госкомсанэпиднадзора Украины.

Проектная документация на строительство и реконструкцию помещений для эксплуатации ВДТ и ПЭВМ должна быть согласована с органами и учреждениями Госсанэпидслужбы Украины.

  1.  Требования к производственным и лабораторным помещениям для эксплуатации ВДТ ПК

Помещения с ВДТ и ПЭВМ должны иметь естественное и искусственное освещение.

Естественное освещение должно осуществляться через светопроемы, ориентированные преимущественно на север и северо-восток и обеспечивать коэффициент естественной освещенности (КЕО) не ниже 1.2% в зонах с устойчивым снежным покровом и не ниже 1.5% на остальной территории.

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

Для внутренней отделки интерьера помещений с ВДТ и ПЭВМ должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка – 0.7 - 0.8; для стен – 0.5 - 0.6; для пола – 0.3 - 0.5.

Полимерные материалы, используемые для внутренней отделки интерьера помещений с ВДТ и ПЭВМ, должны быть разрешены для применения органами и учреждениями Государственного санитарно-эпидемиологического надзора.

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

  1.  Гигиенические требования к параметрам производственной среды в помещениях с ВДТ ПК

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

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

Запрещается проводить ремонт ВДТ и ПЭВМ непосредственно в рабочих помещениях.

  1.  Микроклимат

Под метеорологическими условиями производственной среды согласно ГОСТ 12.1.005–76 понимают сочетания температуры, относительной влажности и скорости движения воздуха [14]. Перечисленные параметры оказывают огромное влияние на функциональную деятельность человека, его самочувствие и здоровье и на надежность работы средств вычислительной техники. Эти микроклиматические факторы влияют как каждый в отдельности, так и в различных сочетаниях. В производственных условиях характерно суммарное действие микроклиматических факторов.

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

Скорость движения воздуха v–вектор усредненной скорости перемещения воздушных потоков (струй) под действием различных побуждающих сил. Скорость движения воздуха измеряется в м/с.

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

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

Максимальная влажность Е – упругость водяных паров, максимально возможная при температуре tc, или плотность водяных паров, способных насытить единицу объема воздуха при данных условиях. Относительная влажность воздуха R — процентное отношение абсолютной влажности к максимальной: R=(е/Е)100.

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

Наибольшее количество теплоты выделяют ЭВМ и вспомогательное оборудование. Так, в машинном зале ЭВМ средняя величина тепловыделений на 1 м2 пола составляет 310 Вт/м2; в помещении подготовки данных – 125 Вт/м2. Тепловыделения от приборов освещения также велики. Удельная величина тепловыделений составляет 35 – 60 Вт/м2. При этом, чем больше уровень освещенности в помещении ВЦ, тем выше удельные величины тепловыделений. Количество теплоты от обслуживающего персонала ВЦ незначительно. Оно зависит от числа работающих в помещении, микроклиматических условий и интенсивности работы, выполняемой человеком.

  1.  Освещение

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

Освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300 – 500 лк. Допускается установка светильников местного освещения для подсветки документов. Местное освещение не должно создавать бликов на поверхности экрана и увеличивать освещенность экрана более 300 лк.

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

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

  1.  Неионизирующие электромагнитные излучения

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

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

Существуют такие диапазоны частот: Уф – ультрафиолетовый диапазон; ИК – инфракрасный диапазон; ВЧ – диапазон высоких частот; ОВЧ – диапазон очень высоких частот; ОНЧ – диапазон очень низких частот; СЧ – диапазон средних частот; НЧ – диапазон низких частот; СНЧ – диапазон сверхнизких частот.

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

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

  1.  Пожарная безопасность

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

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

Пожарные извещатели размещают непосредственно на охраняемых объектах – в помещениях ВЦ. Различают ручные и автоматические извещатели. Ручные устанавливают на открытых, хорошо просматриваемых местах с удобными подходами на высоте 1,5 м от уровня пола. Они приводятся в действие человеком, обнаружившим пожар. Для этого необходимо нажать кнопку либо повернуть ручку извещателя. Автоматические извещатели преобразуют контролируемый признак пожара в электрический сигнал, который передается по линии связи на приемную станцию, или прерывают протекание по линии связи (шлейфе) контрольного электрического тока. В зависимости от контролируемого признака эти извещатели делятся на тепловые, дымовые, световые, комбинированные.

  1.  Санитарные требования к организации и оборудованию рабочих мест с ВДТ ПК

Рабочие места с ВДТ и ПЭВМ по отношению к световым проемам должны располагаться так, чтобы естественный свет падал сбоку, преимущественно слева.

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

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

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

В помещениях с ВДТ и ПЭВМ ежедневно должна проводиться влажная уборка.

Высота рабочей поверхности стола для взрослых пользователей должна регулироваться в пределах 680 - 800 мм; при отсутствии такой возможности высота рабочей поверхности стола должна составлять 725 мм.

Модульными размерами рабочей поверхности стола для ВДТ и ПЭВМ, на основании которых должны рассчитываться конструктивные размеры, следует считать: ширину 800, 1000, 1200 и 1400 мм, глубину 800 и 1000 мм при нерегулируемой его высоте, равной 725 мм.

Рабочий стол должен иметь пространство для ног высотой не менее 600 мм, шириной – не менее 500 мм, глубиной на уровне колен – не менее 450 мм и на уровне вытянутых ног – не менее 650 мм.

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

Конструкция его должна обеспечивать:

  •  ширину и глубину поверхности сиденья не менее 400 мм;
  •  поверхность сиденья с закругленным передним краем;
  •  регулировку высоты поверхности сиденья в пределах 400 - 550 мм и углам наклона вперед до 15 град. и назад до 5 град.;
  •  высоту опорной поверхности спинки 300 ± 20 мм, ширину – не менее 380 мм и радиус кривизны горизонтальной плоскости – 400 мм;
  •  угол наклона спинки в вертикальной плоскости в пределах ±30 градусов;
  •  регулировку расстояния спинки от переднего края сиденья в пределах 260 - 400 мм;
  •  стационарные или съемные подлокотники длиной не менее 250 мм и шириной – 50 - 70 мм;
  •  регулировку подлокотников по высоте над сиденьем в пределах 230 ± 30 мм и внутреннего расстояния между подлокотниками в пределах 350 - 500 мм.

Рабочее место должно быть оборудовано подставкой для ног, имеющей ширину не менее 300 мм, глубину не менее 400 мм, регулировку по высоте в пределах до 150 мм и по углу наклона опорной поверхности подставки до 20 градусов.

  1.  Требования к режимам работы и отдыха при работе с ВДТ ПК

Режимы труда и отдыха при работе с ПЭВМ и ВДТ должны организовываться в зависимости от вида и категории трудовой деятельности.

Виды трудовой деятельности разделяются на 3 группы: группа А – работа по считыванию информации с экрана ВДТ или ПЭВМ с предварительным запросом; группа Б – работа по вводу информации; группа В – творческая работа в режиме диалога с ЭВМ. При выполнении в течение рабочей смены работ, относящихся к разным видам трудовой деятельности, за основную работу с ПЭВМ и ВДТ следует принимать такую, которая занимает не менее 50% времени в течение рабочей смены или рабочего дня.

Для видов трудовой деятельности устанавливается 3 категории тяжести и напряженности работы с ВДТ и ПЭВМ, которые определяются: для группы А – по суммарному числу считываемых знаков за рабочую смену, но не более 60000 знаков за смену; для группы Б – по суммарному числу считываемых или вводимых знаков за рабочую смену, но не более 40000 знаков за смену; для группы В – по суммарному времени непосредственной работы с ВДТ и ПЭВМ за рабочую смену, но не более 6 часов за смену.

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

Для инженеров, обслуживающих учебный процесс в кабинетах (аудиториях) с ВДТ и ПЭВМ, продолжительность работы не должна превышать 6 часов в день.

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

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

Продолжительность непрерывной работы с ВДТ без регламентированного перерыва не должна превышать 2 часов.

При работе с ВДТ и ПЭВМ в ночную смену (с 22 до 6 часов), независимо от категории и вида трудовой деятельности, продолжительность регламентированных перерывов должна увеличиваться на 60 минут.

При 8-ми часовой рабочей смене и работе на ВДТ и ПЭВМ регламентированные перерывы следует устанавливать:

  •  для I категории работ через 2 часа от начала рабочей смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый;
  •  для II категории работ через 2 часа от начала рабочей смены и через 1,5 – 2,0 часа после обеденного перерыва продолжительностью 15 минут каждый или продолжительностью 10 минут через каждый час работы;
  •  для III категории работ через 1,5 – 2,0 часа от начала рабочей смены и через 1,5 – 2 часа после обеденного перерыва продолжительностью 20 минут каждый или продолжительностью 15 минут через каждый час работы.

При 12-ти часовой рабочей смене регламентированные перерывы должны устанавливаться в первые 8 часов работы аналогично перерывам при 8-ми часовой рабочей смене, а в течение последних 4 часов работы, независимо от категории и вида работ, каждый час продолжительностью 15 минут.

  1.  Расчет инженерной задачи

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

Во взрывоопасном помещении разлит бензин А-76. Определить время, за которое произойдет испарение бензина и образование взрывоопасной концентрации пара бензина в воздухе.

Основные выходные данные:     

  •  количество бензина, который пролился Q = 2,5 дм3;
  •  температура в помещении t = 20o C;  
  •  радиус лужи разлитого бензина r = 430 см;
  •  объем помещения  V = 170 м3 .

Атмосферное давление в помещении  0,1 МПа (760 мм. рт.ст).

Интенсивность испарения бензина определяем по формуле :

                                             (4.1)                  

где    r – радиус жидкости, которая испаряется;

DТ – коэффициент диффузии паров бензина, см2/с;

М – молекулярная масса бензина (96);

Vt–  объем грамм-молекулы паров бензина при t  20o C, л;

Рнас – давление насыщения пара бензина, Па (0,014 МПа  в нашем случае);

Ратм – атмосферное давление, Па.

Коэффициент диффузии паров бензина при некоторой температуре определяем по формуле:

,                                                       (4.2)

где  D0 – коэффициент диффузии паров бензина при температуре 0оС и давлении 0,1МПа, см2 /с.

 (см2/с)

(см2/с)

Объем грамм-молекулы паров бензина при температуре 20оС                определяем по формуле:

,                                                   (4.3)

где   V0 – объем грамм-молекулы паров бензина при температуре 0оС и давлении 0,1МПа.

 (см3)

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

 (г/с)

Время испарения 2.5 литров бензина составляет:

,

где 0,73 – плотность бензина.

Нижний порог взрывчатости паров бензина по объему коб = 0,76%, что соответствует следующей весомой концентрации при температуре 20оС:

                              

Испарение 2,5 литров бензина или 1971г, могут вызвать взрывоопасную концентрацию в объеме:

Взрывоопасная концентрация в объеме 170м3 образуется через:


Выводы

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

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

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

Так же в процессе выполнения работы была разработана ЛВС, которая разделена на 7 сегментов и состоит из 50 компьютеров. Разработанная ЛВС обеспечивает поддержку IP-телефонии и общий доступ к интернету, как для сотрудников, так и для клиентов по беспроводной сети

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

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


Перечень использованных источников

  1.  Фаулер М., Скотт К. UML. Основы. – Пер. с англ. – СПб.: Символ- Плюс, 2002.
  2.  Гамма Э., Холм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб: Питер, 2006. – 366 с.
  3.  Фаулер, Мартин - Архитектура корпоративных программных приложений.: Пер. с англ. — М.: Издательский дом "Вильяме", 2006. — 544 с.
  4.  Topley, K. Java Web Services in Nutshell. O'Reilly Press, 2003.
  5.  Нейгел, Кристиан, Ивьен, Билл, Глинн, Джей, Скиннер, Морган, Уотсон, Карли С# 2005 и платформа .NET 3.0 для профессионалов. – пер. с англ. М. ООО «И.Д.Вильямс», 2008.
  6.  Russell Miles. Java-Server-Pages Cookbook. O'Reilly – 2004.
  7.  Hibernate. Goddard Space Flight Center, Greenbelt, Maryland, USA, 2007.
  8.  Izmerenie – официальный сайт фирмы производителя
  9.  Фрунзе А.В.  Микроконтроллеры. Это же просто, 2002-227 с.
  10.  Зубчук В.И. и др. Справочник по цифровой схемотехнике.- К.:Техника, 1990.-448 с.
  11.  Восток скай – официальный сайт фирмы производителя
  12.  О.О. Навакатикян, С.М. Стрюков, В.В. Кальниш Охрана труда 

пользователей компьютерных видеодисплейных терминалов. –К.,  1997. – 400 с.

  1.  К.Н. Ткачук, Р.В. Сабарно, А .Г. Степанов, Д.Ф. Иванчук Справочник по охране труда на промышленном предприятии.  – К.: Техника, 1991. - 285 с.


 

А также другие работы, которые могут Вас заинтересовать

32845. Особенности социализации личности. Проблема девиантного поведения и его причины 16.74 KB
  Особенности социализации личности. Социализация личностиэто процесс усвоения индивидом социального опыта общества к которому он принадлежит. Социализация рассматривается как процесс условие проявление и результат социального формирования личности. Как процесс она означает социальное становление и развитие личности в зависимости от характера взаимодействия человека со средой обитания адаптации к ней с учетом индивидуальных особенностей.
32846. Проблема жизни, смерти и бессмертия в духовном опыте человечества. Проблема смысла жизни 15.34 KB
  Проблема жизни смерти и бессмертия в духовном опыте человечества. Проблема смысла жизни. Поэтому проблема жизни и смерти занимает важнейшее место в общественном сознании прежде всего в философии и религии. Для ранней античной философии характерен космоцентричный подход к пониманию проблемы жизни и смерти.
32847. Общество как материальная система 15.36 KB
  Общество – это обособившаяся от природы часть материального мира высокоорганизованная материальная система подчиняющаяся всеобщим законам и в то же время имеющаяся специфические особенности функционирования и развития. Как и любое материальное образование общество обладает целым рядом неотъемлемых свойств: объективность системность и структурность движение пространство время отражение самоорганизация. Общество возникает и существует объективно т. Общество представляет собой открытую развивающуюся систему.
32848. Материально-производственная сфера общественное жизни.Диалектика производительных сил и производственных отношений 12.99 KB
  Материальное производство характеризуется определенным способом производства который представляет собой единство двух сторон: производительных сил и производственных отношений. Производственные отношения включают в себя отношения собственности на средства производства а также отношения по поводу распределения и обмена продукта материального производства. В этом проявляется диалектика экономических потребностей производства и потребления.; способ производства и соответствующие ему отношения собственности определяют появление и развитие...
32849. Социальная сфера общественной жизни. Социальная структура общества. Виды социальных общностей 13.65 KB
  Социальная структура общества. Сфера общества – это социальное пространство которое фиксирует границы того или иного вида общественной деятельности. Социальная сфера – это исторически сложившаяся относительно устойчивая система связей между различными элементами общества: отдельными индивидами социальными группами и социальными общностями. В социальной сфере реализуются интересы классов и слоев общества социальных общностей и групп отношения общества и личности здесь создаются и совершенствуются условия труда быта и досуга.
32850. Политическая сфера общественной жизни. Структура и соц функции. Государство,как основной политический институт 12.55 KB
  Общество как система состоит из нескольких подсистем или сфер основными из которых являются экономическая социальная политическая духовная и экологическая. Политическая сфера – область общественной жизни включающая в себя политические отношения данного общества. и международные; политическая деятельность; политическое сознание политическая идеология и политическая психология.
32851. Экологическая сфера. Роль мед работников 11.81 KB
  Общество как система состоит из нескольких подсистем или сфер основными из которых являются экономическая социальная политическая духовная и экологическая. Экологическая сфера общества сформировалась во 2й половине ХХ в. Экологическая сфера – подсистема общества формирующаяся на основе специализированной деятельности по охране воспроизводству улучшению и приумножению природных факторов человеческого бытия. Экологическая деятельность.
32852. Духовная сфера общ6ества. Основные формы и уровни. Общественная психология и идеология,их диалектическая взаимосвязь 14.08 KB
  Специфика идеологии проявляется в том что она возникает на основе существующих в обществе экономических отношений и отражает действительность через призму этих отношений. В классовом обществе экономические отношения выступают в форме классовых интересов поэтому специфику идеологии можно конкретнее представить как отражение действительности через призму интересов определенных классов как систему идей и взглядов классов. В классовом обществе нет и не может быть надклассовой или внеклассовой идеологии. Общественно историческая практика...
32853. Религия, как форма общественного сознания 16.61 KB
  1Мораль 2Религия 3Искусство4Наука 5Философия 6Политическое сознание 7Право 8Экологическое сознание Религия – представления о мире основанные на вере в сверхъестественное и отражающие мир в иллюзорной форме. Религия как ФОС проявляется в религиозной психологии основанной на эмоциях и религиозной идеологии – учении о Боге и его отношении к миру. Религия существует много веков повидимому также долго как существует человечество.