Ирина Эланс

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

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

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

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

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

УТВЕРЖДАЮ

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

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

В.В. Казимир

“____” ___________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Анализ предметной области

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1.7Hummingbird 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.1.8NetDocuments

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.1.9Inforouter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Критерии оценки	Система «Hummingbird DM»	Система «NetDocuments» »	Система «Inforouter»	Разрабаты-ваемая система
иерархическое представление хранения документов	+	+	+	+
использование библиотек и папок для хранения	+	+	+	+
сохранность и доступность данных	+	+	+	+
сжатие документов	–	+	+	+
индексирование	–	+	-	+
улучшенный поиск	–	+	+	+
управление правами пользователей	+	+	+	+
возможность общения клиентов	+	–	+	+
поддержка LDAP	–	+	-	+
интеграция с MS Office	+	+	-	+

Примечания:

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

1.1.11Вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.5.2Выводы

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

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

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

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

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

2.1.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, так как она является бесплатным кроссплатформенным языком программирования, для которого существует множество различных бесплатных реализаций различных фреймворков и технологий для веб-программирования.

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

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

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

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.

Фреймворк 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-компонент на различных клиентских устройствах.

Технология OpenSocial

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

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

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

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

Технология 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 JavaScript – JavaScript среда которая управляет гаджетом и предоставляет OpenSocial функциональность;
OpenSocial Gateway Server – свободно распространяемая реализация интерфейса сервера контейнера, включающая реализацию протокола OpenSocial REST, которая позволяет подключать собственные реализации.

2.1.3Выбор СУБД

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

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

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

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

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

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

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

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

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

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

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

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

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

Надежность:

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

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

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

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

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

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

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.

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.

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

На рисунке 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). В связи с тем что коммутирующие маршрутизаторы по сути являются обыкновенными маршрутизаторами, только "под завязку нашпигованными" аппаратными верно практически для любого маршрутизатора).

2.1.5Выводы

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

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

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

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

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

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

Для функционирования разрабатываемой системы необходим сервер, который будет обрабатывать 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 и требует доступ к специфическим сервисам и серверам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В качестве системы управления реляционными базами данных был выбран 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 – Схема БД КС управления документооборотом предприятия «Черниговгазмонтаж»

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

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

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

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

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

Данный класс содержит все необходимые сервисы системы. Диаграмма представлена на рисунке 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 – Диаграмма сервисов серверного приложения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.8.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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Произведем выбор необходимого нам оборудования, исходя из ряда параметров. В первую очередь будем обращать внимание на скорость, с которой необходимо будет обмениваться пакетами между интерфейсами, во-вторых, поддержка стандарта 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	8К	8К	8К
Скорость коммутации кадров, 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К	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 , стоимость которого равна 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-сервер.

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

Моделирование сети было произведено с помощью утилиты 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=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.

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

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

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 ; время, через которое ;вторичные сервера должны совершать повторную попытку

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 ; время, через которое ;вторичные сервера должны совершать повторную попытку

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.

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

3.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

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

В данном подразделе показан результат объедение классов в пакеты. В таблице 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 – Диаграмма пакетов системы

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

В данном подразделе содержится протоколы классов, сгруппированных по пакетам. В таблице 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 ()	Метод для создания новой версии документа

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

На рисунке 3.5 представлена диаграмма развертывания ИКС.

Для сборки проекта использовалась система автоматизированной сборки Ant. Для сборки проекта необходимо выполнить команду ant build.xml install в каталоге проекта.

Рисунок 3.5 – Диаграмма развертывания ИКС

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

В процессе разработки пользовательского интерфейса (бумажного, компьютерного) были выделены отдельные страницы веб-интерфейса, такие как: главная страница с модулем логирования и модулем регистрации; страницы для добавления документа, просмотра библиотеки. В зависимости от роли пользователя, ему разрешаются те или иные операции. Было спроектировано множество страниц просмотра, добавления и редактирования, удаления документации, страницы профиля, и регистрации.

Ниже приведен окончательный вариант пользовательского интерфейса.

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

Рисунок 3.6 – Гостевая страница предприятия «Черниговгазмонтаж»

Для выполнения входа необходимо ввести логин и пароль и нажать кнопку «Войти». Если пользователь не зарегистрирован, он должен нажать кнопку «Регистрация». Окно ввода логина и пароля имеет следующий вид (Рисунок 3.7).

Рисунок 3.7 – Окно входа/регистрации системы

Окно регистрации системы предлагает выполнить регистрацию или же войти в систему. Внешний вид этого модуля представляется на рисунке 3.8.

Рисунок 3.8 – Окно регистрации

Для перехода на страницу для просмотра документов необходимо ввести логин и пароль, нажать кнопку «Войти» и тогда откроется страница пользователя(Рисунок 3.9).

Рисунок 3.9 – Страница просмотра содержимого библиотеки

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

Рисунок 3.10 – Открытия документа

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

Рисунок 3.11 – Сохранения документа

Тестирование пользовательского интерфейса отеля производилось на студентах ФЭИТ. Были поставлены задачи по трём основным сценариям работы:

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

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

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

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

В результате тестирования все недостатки были убраны.

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

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

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

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

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

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

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

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

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

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

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

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

Государственный санитарно-эпидемиологический надзор за новыми (модернизированными) ВДТ и ПЭВМ осуществляется на этапах их разработки, постановки на производство, в процессе производства, закупки по импорту и применения в соответствии с «Методическими указаниями по организации и проведению государственного санитарно-эпидемиологического надзора за новой продукцией и технологией ее производства», утвержденными Госкомсанэпиднадзора Украины.

Проектная документация на строительство и реконструкцию помещений для эксплуатации ВДТ и ПЭВМ должна быть согласована с органами и учреждениями Госсанэпидслужбы Украины.

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

Помещения с ВДТ и ПЭВМ должны иметь естественное и искусственное освещение.

Естественное освещение должно осуществляться через светопроемы, ориентированные преимущественно на север и северо-восток и обеспечивать коэффициент естественной освещенности (КЕО) не ниже 1.2% в зонах с устойчивым снежным покровом и не ниже 1.5% на остальной территории.

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

Для внутренней отделки интерьера помещений с ВДТ и ПЭВМ должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка – 0.7 - 0.8; для стен – 0.5 - 0.6; для пола – 0.3 - 0.5.

Полимерные материалы, используемые для внутренней отделки интерьера помещений с ВДТ и ПЭВМ, должны быть разрешены для применения органами и учреждениями Государственного санитарно-эпидемиологического надзора.

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

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

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

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

Запрещается проводить ремонт ВДТ и ПЭВМ непосредственно в рабочих помещениях.

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

Под метеорологическими условиями производственной среды согласно ГОСТ 12.1.005–76 понимают сочетания температуры, относительной влажности и скорости движения воздуха [14]. Перечисленные параметры оказывают огромное влияние на функциональную деятельность человека, его самочувствие и здоровье и на надежность работы средств вычислительной техники. Эти микроклиматические факторы влияют как каждый в отдельности, так и в различных сочетаниях. В производственных условиях характерно суммарное действие микроклиматических факторов.

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

Скорость движения воздуха v–вектор усредненной скорости перемещения воздушных потоков (струй) под действием различных побуждающих сил. Скорость движения воздуха измеряется в м/с.

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

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

Максимальная влажность Е – упругость водяных паров, максимально возможная при температуре tc, или плотность водяных паров, способных насытить единицу объема воздуха при данных условиях. Относительная влажность воздуха R — процентное отношение абсолютной влажности к максимальной: R=(е/Е)100.

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

Наибольшее количество теплоты выделяют ЭВМ и вспомогательное оборудование. Так, в машинном зале ЭВМ средняя величина тепловыделений на 1 м² пола составляет 310 Вт/м²; в помещении подготовки данных – 125 Вт/м². Тепловыделения от приборов освещения также велики. Удельная величина тепловыделений составляет 35 – 60 Вт/м². При этом, чем больше уровень освещенности в помещении ВЦ, тем выше удельные величины тепловыделений. Количество теплоты от обслуживающего персонала ВЦ незначительно. Оно зависит от числа работающих в помещении, микроклиматических условий и интенсивности работы, выполняемой человеком.

4.5Освещение

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

Освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300 – 500 лк. Допускается установка светильников местного освещения для подсветки документов. Местное освещение не должно создавать бликов на поверхности экрана и увеличивать освещенность экрана более 300 лк.

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

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

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

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

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

Существуют такие диапазоны частот: Уф – ультрафиолетовый диапазон; ИК – инфракрасный диапазон; ВЧ – диапазон высоких частот; ОВЧ – диапазон очень высоких частот; ОНЧ – диапазон очень низких частот; СЧ – диапазон средних частот; НЧ – диапазон низких частот; СНЧ – диапазон сверхнизких частот.

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

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

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

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

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

Пожарные извещатели размещают непосредственно на охраняемых объектах – в помещениях ВЦ. Различают ручные и автоматические извещатели. Ручные устанавливают на открытых, хорошо просматриваемых местах с удобными подходами на высоте 1,5 м от уровня пола. Они приводятся в действие человеком, обнаружившим пожар. Для этого необходимо нажать кнопку либо повернуть ручку извещателя. Автоматические извещатели преобразуют контролируемый признак пожара в электрический сигнал, который передается по линии связи на приемную станцию, или прерывают протекание по линии связи (шлейфе) контрольного электрического тока. В зависимости от контролируемого признака эти извещатели делятся на тепловые, дымовые, световые, комбинированные.

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

Рабочие места с ВДТ и ПЭВМ по отношению к световым проемам должны располагаться так, чтобы естественный свет падал сбоку, преимущественно слева.

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

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

Экран видеомонитора должен находиться от глаз пользователя на оптимальном расстоянии 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 градусов.

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

Режимы труда и отдыха при работе с ПЭВМ и ВДТ должны организовываться в зависимости от вида и категории трудовой деятельности.

Виды трудовой деятельности разделяются на 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 минут.

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

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

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

Основные выходные данные:

количество бензина, который пролился Q = 2,5 дм³;
температура в помещении t = 20^o C;
радиус лужи разлитого бензина r = 430 см;
объем помещения V = 170 м³ .

Атмосферное давление в помещении 0,1 МПа (760 мм. рт.ст).

Интенсивность испарения бензина определяем по формуле :

(4.1)

где r – радиус жидкости, которая испаряется;

D_Т– коэффициент диффузии паров бензина, см²/с;

М – молекулярная масса бензина (96);

V_t– объем грамм-молекулы паров бензина при t 20^oC, л;

Р_нас – давление насыщения пара бензина, Па (0,014 МПа в нашем случае);

Р_атм – атмосферное давление, Па.

Коэффициент диффузии паров бензина при некоторой температуре определяем по формуле:

, (4.2)

где D₀ – коэффициент диффузии паров бензина при температуре 0^оС и давлении 0,1МПа, см² /с.

(см²/с)

Объем грамм-молекулы паров бензина при температуре 20^оС определяем по формуле:

, (4.3)

где V₀ – объем грамм-молекулы паров бензина при температуре 0^оС и давлении 0,1МПа.

(см³)

Подставив в формулу числовые значения, получим:

(г/с)

Время испарения 2.5 литров бензина составляет:

где 0,73 – плотность бензина.

Нижний порог взрывчатости паров бензина по объему к_об = 0,76%, что соответствует следующей весомой концентрации при температуре 20^оС:

Испарение 2,5 литров бензина или 1971г, могут вызвать взрывоопасную концентрацию в объеме:

Взрывоопасная концентрация в объеме 170м³ образуется через:

Выводы

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

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

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

Так же в процессе выполнения работы была разработана ЛВС, которая разделена на 7 сегментов и состоит из 50 компьютеров. Разработанная ЛВС обеспечивает поддержку IP-телефонии и общий доступ к интернету, как для сотрудников, так и для клиентов по беспроводной сети

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

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

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

Фаулер М., Скотт К. UML. Основы. – Пер. с англ. – СПб.: Символ- Плюс, 2002.

Гамма Э., Холм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб: Питер, 2006. – 366 с.
Фаулер, Мартин - Архитектура корпоративных программных приложений.: Пер. с англ. — М.: Издательский дом "Вильяме", 2006. — 544 с.
Topley, K. Java Web Services in Nutshell. O'Reilly Press, 2003.
Нейгел, Кристиан, Ивьен, Билл, Глинн, Джей, Скиннер, Морган, Уотсон, Карли С# 2005 и платформа .NET 3.0 для профессионалов. – пер. с англ. М. ООО «И.Д.Вильямс», 2008.
Russell Miles. Java-Server-Pages Cookbook. O'Reilly – 2004.
Hibernate. Goddard Space Flight Center, Greenbelt, Maryland, USA, 2007.
Izmerenie – официальный сайт фирмы производителя
Фрунзе А.В. Микроконтроллеры. Это же просто, 2002-227 с.
Зубчук В.И. и др. Справочник по цифровой схемотехнике.- К.:Техника, 1990.-448 с.
Восток скай – официальный сайт фирмы производителя
О.О. Навакатикян, С.М. Стрюков, В.В. Кальниш Охрана труда

пользователей компьютерных видеодисплейных терминалов. –К., 1997. – 400 с.

К.Н. Ткачук, Р.В. Сабарно, А .Г. Степанов, Д.Ф. Иванчук Справочник по охране труда на промышленном предприятии. – К.: Техника, 1991. - 285 с.

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

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

1.1.7Hummingbird DM

1.1.8NetDocuments

1.1.9Inforouter

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

1.1.11Вывод

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

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

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

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

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

1.5.2Выводы

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

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

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

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

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

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

Технология OpenSocial

Технология Apache Shindig

2.1.3Выбор СУБД

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

Microsoft SQL Server

MySQL

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

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

2.1.5Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.5Освещение

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

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

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

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

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

Выводы

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