Разработка программного обеспечения для оперативного доступа к содержимому реестров


Приднестровский государственный университет им. Т.Г. Шевченко. Инженерно-технический институт. Инженерно-технический факультет
Кафедра программного обеспечения вычислительной техники и автоматизированных систем
ЗАДАНИЕ НА ВЫПУСКНУЮ КВАЛИФИКАЦИОННУЮ РАБОТУ БАКАЛАВРА Студенту Петровичу
Тема ВКР: «Разработка программного обеспечения для оперативного доступа к содержимому реестров» утверждена приказом по университету № 881-ОД от «09» июня 2015 г.
Срок сдачи расчетно-пояснительной записки на кафедру «25» июня 2015 г.
 Исходные данные к работе: пример структуры реестра, конфигурация серверного программно-аппаратного обеспечения.

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

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

Дата выдачи задания «11» мая 2015 г

Научный руководитель, доцент, к.т.н.   _____________/Башкатов А.М./

Задание принял к исполнению                         _____________/ П./

АННОТАЦИЯ

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

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

ABSTRACT

Web application in given graduated work for instant read only access to documents from State registries was developed.

The purpose of the work was to create single point of access to different databases with support a variety of devices, capable to run developed web application. Both full text search for documents and predefined data sets available. Browser built-in print functionality is used.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ. 5

1 ИССЛЕДОВАНИЕ И АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ.. 6

1.1 Описание поставленной задачи, ее обоснование. 6

1.2 Обоснование актуальности исследуемой задачи. 7

1.3 Современное состояние исследуемой задачи. 10

1.4 Обзор методов решения подобных задач. 12

1.5 Системные требования, требования к входным и выходным данным. 15

2 ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА.. 17

2.1 Выбор методов и средств для реализации, его обоснование. 17

2.2 Описание применяемых алгоритмов. 21

2.3 Структура, архитектура программного продукта. 24

2.4 Описание логической структуры программного продукта. 26

2.5 Функциональная схема, функциональное назначение
программного продукта. 27

3 РЕАЛИЗАЦИЯ И ТЕСТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА.. 29

3.1 Описание реализации. 29

3.2 Описание пользовательского интерфейса. 33

3.3 Методы и средства защиты программного продукта. 36

3.4 Тестирование и оценка надежности программного продукта. 37

3.5 Расчет себестоимости. 38

3.6 Охрана труда. 44

ЗАКЛЮЧЕНИЕ. 50

ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ,  ЕДИНИЦ
И ТЕРМИНОВ.. 51

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ.. 52

ПРИЛОЖЕНИЕ. 54

ВВЕДЕНИЕ

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

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

Широко распространенным открытым стандартом является язык гипертекстовой разметки (от англ. HyperText Markup Language – HTML). Совместно с рядом вспомогательных технологий, данный стандарт позволяет создавать приложения, которые доступны на настольном компьютере, планшетном компьютере, мобильном телефоне, и на многих других устройствах.

Многие современные системы автоматизации документооборота и совместной работы уже имеют встроенные компоненты, поддерживающие данный стандарт (Docsvision, OnlyOffice, Е1 Евфрат).

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

1 ИССЛЕДОВАНИЕ И АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Описание поставленной задачи, ее обоснование

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

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

В первую очередь должна быть предусмотрена защита от несанкционированного доступа. Доступ к документам реестров необходим предоставлять после аутентификации, при помощи индивидуальных пар логин-пароль. Необходимо использовать стандартные учетные записи IBM Domino для разделения доступа [9]. В руководстве пользователя необходимо рассмотреть конфигурацию системы для работы по защищенным протоколам.

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

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

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

При разработке программного обеспечения следует ориентироваться на следующие конфигурации аппаратного обеспечения:

Конфигурация сервера баз данных:

  • четырех-ядерный процессор Intel Xeon;
  • 8 Гб оперативной памяти;
  • 1 Тб жесткий диск;
  • Операционная система Windows Server 2008 или более новая.

Типовая конфигурация рабочей станции:

  • двухъядерный процессор Intel Core i3;
  • 4 Гб оперативной памяти;
  • 500 Гб жесткий диск;
  • Операционная система Windows 7 или более новая.

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

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

1.2 Обоснование актуальности исследуемой задачи

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

По приблизительным данным, полученным от заказчика, за последние несколько лет количество документов превысило 10 000. Примерный рост объема документооборота в реестрах представлен на рисунке 1.1. При этом, часто важно обеспечить оперативный доступ к документам в ущерб доступных операций над документами.

Рисунок 1.1 – Рост количества документов в реестрах

Основным способом доступа к документам реестра является использование стандартного клиента IBM Notes. Это приложение (рисунок 1.2) предоставляет широкий набор возможных действий с документами и базами данных.

Not Supported

Рисунок 1.2 – Интерфейс клиента IBM Notes

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

Существующий веб-интерфейс одной из баз данных реестра представлен на рисунке 1.3 (веб-интерфейс открыт в встроенном веб-браузере IBM Notes, список документов скрыт под прямоугольником).

Not Supported

Рисунок 1.3 – Существующий интерфейс одной из баз данных реестра

Этот интерфейс реализован при помощи встроенного конструктора веб-страниц IBM Domino Designer, имеет запутанную навигацию (список ссылок на панели слева) и различные интерфейсные ошибки и ограничения (ограничения обусловлены реализацией конструктора в ПО, часть функций работает только в встроенном веб-браузере IBM Notes). Одной из ошибок является дублирование левой панели каждый раз при клике на кнопку «Выход».

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

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

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

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

Единая точка входа для различных серверов позволит оперативно переключаться между разными базами данных. Добавление промежуточного сервера позволит в будущем (если появится необходимость) добавить алгоритм автоматической балансировки нагрузки между репликами IBM Domino [15].

1.3 Современное состояние исследуемой задачи

В состав пакета программ платформы IBM Domino [6] входят:

  • сервер IBM Domino;
  • IBM Domino Administrator;
  • IBM Domino Console;
  • IBM Domino Designer;
  • клиент IBM Notes.

Сервер IBM Domino реализует функции хранения и изменения баз данных. Различают секционированные (англ. partitioned) и не секционированные сервера. Секционирование позволяет запускать на одном физическом сервере, несколько экземпляров IBM Domino на разных сетевых портах. Это применяется, когда необходимо иметь несколько различных конфигураций.

Управление серверами осуществляется при помощи IBM Domino Console либо через графический интерфейс IBM Domino Administrator.

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

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

Not Supported

Рисунок 1.4 – Диалог управления доступом к базе данных в IBM Domino Administator

Для проектирования и изменения структуры данных и форм применяется программное обеспечение IBM Domino Designer.

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

Программное обеспечение IBM Domino Designer используется в качестве интегрированной среды разработки для всех пользовательских подпрограмм для баз данных. IBM Domino.

В данном программном пакете можно разрабатывать агенты, реагирующие на различные события в базе данных, фреймы и веб-страницы XPages. Технология XPages является развитием уже существующего механизма реализации веб-страниц на фреймах и при помощи специальных синтаксических конструкций на языке разметки XML (англ. eXtensible Markup Language). Документы в базе данных представлены как подключаемые ресурсы.

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

Not Supported

Рисунок 1.5 – Интерфейс IBM Domino Designer

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

1.4 Обзор методов решения подобных задач

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

Технология XPages [14] является эволюционным развитием идеи конструктора, и использует прогрессивный (на момент выхода первых версий, примерно в середине 2000-х годов) формат разметки, основанный на расширяемом языке разметки (англ. eXtensible Markup Language – XML).

Приложения, разработанные на XPages являются кроссплатформенными и используют такие стандарты и библиотеки как JavaScript, Java, Dojo Toolkit.

Возможности веб-приложений, написанных с применением технологии XPages, могут быть расширены при помощи стандартного набора прикладных интерфейсов Java Server Faces и языка программирования Java.

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

Not Supported

Рисунок 1.6 – Интегрированная среда разработки XPages

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

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

Для языков программирования C и Java, платформа IBM Domino поддерживает локальное подключение через клиента IBM Notes, и удаленное подключение с использованием общей архитектуры брокеров (англ. Common Object Request Broker Architecture – CORBA).

Удаленное подключение выполняется в несколько этапов (рисунок 1.7). При первом подключении, с сервера по протоколу HTTP запрашивается строка с данными для подключения (в документации определена как IOR).

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

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

Not Supported

Рисунок 1.7 – Удаленное подключение с использованием архитектуры брокеров

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

Начиная с IBM Domino 8.5.3 был добавлен прикладной интерфейс Domino Data Services [11]. Это интерфейс доступа к объектам баз данных серверов IBM Domino по сети, с применением принципов передачи состояния представления (англ. Representational State Transfer – REST).

Domino Data Services предоставляет следующие возможности:

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

Для получения данных подходит любой язык программирования с возможностью отправки запросов по протоколу передачи гипертекста HTTP. Данные закодированы в формат JSON (от англ. JavaScript Object Notification).

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

1.5 Системные требования, требования к входным и выходным данным

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

При необходимости соединения различных географически удаленных сетей (или отдельных пользователей) по общедоступным каналам связи необходимо настроить логическое соединение между этими точками с шифрованием всех передаваемых данных [19].

Пример возможной организации сети организации представлен на рисунке 1.8. Компьютеры в сети соединены при помощи коммутатора. Доменный сервер, сервер баз данных IBM Domino и веб-сервер (реализуемый в рамках данной работы) расположены на одном физическом сервере.

 

Not Supported

Рисунок 1.8 – Обобщенная сетевая конфигурация

На сервере баз данных должен быть настроен сервер IBM Domino версии 9.0 или более современный.

Входными данными являются файлы баз данных IBM Notes (*.nsf) и шаблоны данных IBM Notes (*.nst). Работа с базами данных осуществляется при помощи прикладных интерфейсов сервера IBM Domino.

Структура баз данных заранее не определена, и может изменятся с течением времени. Подмножество поддерживаемых возможностей платформы ограничено. Для корректной работы разработанного ПО, неподдерживаемые возможности должны быть исключены из представлений, к которым включен доступ через Domino Data Services [11].

Веб-сервер поддерживает 32 и 64-разрядные операционные системы семейства Windows. Поддержка Linux и MacOS X требует незначительных доработок и тестирования (исполняемые файлы для данных платформ в рамках ВКР не предоставляются).

Для работы с веб-приложением рекомендуется использование одного из основных (Internet Explorer начиная с версии 10, Google Chrome и Mozilla Firefox) веб-браузеров последней или предпоследней версии. Работа в устаревших браузерах не гарантируется.

Предполагается полноценная работа веб-приложения на следующих операционных системах: Windows (начиная с версии 7), Linux, Android (начиная с версии 4.1), iOS (начиная с версии 6) при наличии установленного веб-браузера.

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

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

2 ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА

2.1 Выбор методов и средств для реализации, его обоснование

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

 

Рисунок 2.1 – Трехзвенная архитектура предлагаемого программного продукта

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

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

Для реализации веб-сервера был выбран компилируемый статически типизированный язык программирования высокого уровня Go [1,9]. Этот язык выделяется среди остальных своей планарной объектно-ориентированной моделью, скоростью компиляции, и количеством пакетов, включенных в стандартную библиотеку языка.

Кроме классического компилятора есть компилятор на базе пакета GCC (англ GNU Compiler Collection – набор компиляторов GNU). Поддерживается взаимодействие с кодом на C (используется встроенная подпрограмма cgo) и C++ (при помощи программного пакета SWAG).

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

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

 

Not Supported

Рисунок 2.2 – Использование канала для синхронизации

Горутина (англ. goroutine) является легковесным аналогом потоков. Такой подход позволяет выполнять одновременно тысячи горутин, используя небольшое число системных потоков (англ. threads).

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

Веб-сервер является связующим звеном между различными серверами IBM Domino и веб-приложением в браузере пользователя. Для эффективной работы был реализован асинхронный конкурентный доступ к ресурсам баз данных работающий с прикладным интерфейсом Domino Data Services [11].

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

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

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

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

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

 

Not Supported

Рисунок 2.3 – Пример изменения дерева компонентов [3]

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

С целью унификации внешнего вида и ускорения разработки, в качестве спецификации внешнего вида была выбрана спецификация материального дизайна (англ. Material Design) представленная компанией Google [8].

Материальный дизайн представляет собой нечто среднее между плоским и объемным дизайном. Все элементы (листы бумаги, от англ. Paper) располагаются в двумерной проекции трехмерной плоскости. Причем оси X, Y находятся в плоскости проекции, а ось Z – перпендикулярно, и служит для создания ощущения перспективы. В отличие от классических трехмерных интерфейсов, толщина листов всегда равна единице (рисунок 2.4).

 

Not Supported

Рисунок 2.4 – Проекция координат в материальном дизайне [8]

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

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

2.2 Описание применяемых алгоритмов

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

 

Not Supported

Рисунок 2.5 – Алгоритм выбора отдаваемого ресурса

 

Браузер отправляет на сервер запрос с указанием требуемого ресурса. Веб-сервер анализирует запрошенный URL [16] и принимает решение о выдаче статического содержимого, начальной разметки веб-приложения или результата запроса к обработчику сетевого интерфейса.

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

 

 

Рисунок 2.6 – Заполнение основного блока интерфейса новыми данными

 

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

На рисунке 2.7 отображена блок-схема алгоритма авторизации в систему.

 

Not Supported

Рисунок 2.7 – Аутентификация на сервере IBM Domino

 

Прикладной интерфейс Domino Data Services не предоставляет название представления при запросе его схемы данных. Поэтому применяется алгоритм с временным хранением списка представлений (рисунок 2.8).

 

Not Supported

Рисунок 2.8 – Использование временного кэша представлений

 

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

 

Not Supported

Рисунок 2.9 – Алгоритм промежуточного кэширования файлов

 

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

2.3 Структура, архитектура программного продукта

Программный продукт будет состоять из двух частей: веб-сервера и веб-приложения. Веб-сервер осуществляет взаимодействие с различными серверами IBM Domino и взаимодействует с веб-приложением по сети.

При проектировании веб-сервера были выделены следующие программные модули (таблица 2.1):

 

Таблица 2.1 – Описание структуры веб-сервера


Все модули образуют древовидный граф зависимостей, без циклов. Корнем дерева является главный модуль (рисунок 2.10).

Not Supported

Рисунок 2.10 – Граф зависимостей между модулями

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

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

Исходный код приложения основан на архитектуре Flux. Архитектура подразумевает однонаправленный поток данных, основанный на событиях и подписчиках, но, в отличие от архитектуры PubSub (рисунок 2.11), четко определены роли каждого объекта.

 

Not Supported

Рисунок 2.11 – Классическая модель писатель-подпиcчик (PubSub)

 

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

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

2.4 Описание логической структуры программного продукта

Базы данных IBM Domino являются документ-ориентированными. Кроме документов в базе данных хранятся служебные объекты (формы, представления, формы) и ресурсы (рисунок 2.12).

 

Not Supported

Рисунок 2.12 – Логическая структура базы данных IBM Domino

 

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

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

Условие (формула) для выборки подмножества из множества всех документов задается в свойствах представления, при редактировании базы данных в программном обеспечении IBM Domino Designer.

Между документами возможны два вида связей: ответ на документ и ответ на ответ. Не все прикладные интерфейсы IBM Domino позволяют извлекать информацию о связях между документами.

Всего в документации IBM Domino [13] определено 16 основных типов полей. Данные типы перечислены в таблице 2.2.

Таблица 2.2 – Типы полей IBM Domino

Название модуля

Назначение

Главный модуль

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

Управление конфигурацией

Чтение конфигурационных файлов.

Хранение текущей конфигурации.

Транспортный модуль

Взаимодействие с серверами IBM Domino.

Оптимизация представления данных.

Модуль сетевого взаимодействия

Обеспечение прикладного интерфейса для веб-приложения.

Отладочный модуль

Ведение расширенного лога приложения

 

Для текстовых полей сервер выполняет построение полнотекстового индекса для поиска (англ. Full Text IndexFTI). Этот индекс используется при полнотекстовом поиске по базе данных.

2.5 Функциональная схема, функциональное назначение
программного продукта

Функциональным назначением продукта является предоставление оперативного доступа к документам из государственных реестров, расположенных на серверах под управлением IBM Domino 9.0.

Функциональная схема представлена на рисунке 2.13.

 

Not Supported

Рисунок 2.13 – Функциональная схема программного продукта

 

Программный продукт должен выполнять следующие функции:

аутентификация по логину и паролю IBM Domino;

отображение доступных баз данных на авторизированных серверах;

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

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

полнотекстовый поиск документов;

печать документа и списка документов.

3 РЕАЛИЗАЦИЯ И ТЕСТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА

3.1 Описание реализации

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

Ниже представлен код инициализации HTTP-сервера.

 

func runHttp(hostname string, port int) {

   m := http.DefaultServeMux

   m.HandleFunc(«/», func(w http.ResponseWriter, req *http.Request) {

      http.ServeContent(w, req, assetName, fi.ModTime(), bytes.NewReader(data)) })

   rest.ServeApi(m)

   addr := fmt.Sprintf(«%s:%d», hostname, port)

   s := &http.Server{

      Addr: addr,

      ReadTimeout: 60 * time.Second,

      WriteTimeout: 120 * time.Second,

      MaxHeaderBytes: 1 << 20, }

   log.Printf(«running server at http://%s…n», addr)

   log.Fatal(s.ListenAndServe()) }

Листинг 3.1 – Инициализация веб-сервера

 

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

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

 

m.HandleFunc(«/rest/state», restState)

m.HandleFunc(«/rest/login», restLogin)

m.HandleFunc(«/rest/logout», restLogout)

m.HandleFunc(«/rest/databases», authorized(restDatabases))

Листинг 3.2 – Установка обработчиков прикладного интерфейса

 

Установка обработчиков выполняется при помощи метода HandleFunc(path, func). Для обработчиков, которые недоступны пользователям, не прошедшим аутентификацию написаны два вспомогательных метода authorized и authorizedSingleRemote. Метод authorizedSingleRemote в отличие от authorized, не только получает список активных сессий, но и определяет в рамках какой сессии должен работать обработчик.

Для представления сессий были описаны три пользовательские структуры: Sessions, ApplicationSession и DominoSession. Они представляют список активных сессий, сессию приложения и сессию сервера IBM Domino соответственно. В рамках сессии приложения выполняется настройка программного обеспечения под структуру конкретной базы данных IBM Domino. Получение сессии приложения возможно только при одной и более активных сессий Domino. Такое ограничение установлено в связи с тем, что приложение не является самодостаточным и работа без подключения к IBM Domino невозможна.

Оба вида сессий расширяют тип Session, для которого реализованы методы проверки на срок действия, установки и удаления cookies.

 

func (s *Session) isExpired() bool {

   return s.expires.Before(time.Now()) }

func (s *Session) setCookie(w http.ResponseWriter) {

   http.SetCookie(w, cookie(s.cookieName, s.id, s.expires)) }

func (s *Session) deleteCookie(w http.ResponseWriter) {

   http.SetCookie(w, cookie(s.cookieName, «», ZeroTime)) }

Листинг 3.3 – Методы структуры Session

 

Метод isExpired используется для проверки того, что сессия еще является активной. Методы setCookie и deleteCookie применяются для установки и удаления Cookies в браузере. Удаление осуществляется путем присвоения срока действия в прошедшем времени (на листинге 3.3 устанавливается 1 секунда эры Unix, Определяется как количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года).

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

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

 

func startSessions(w http.ResponseWriter, req *http.Request) *Sessions {

ss := Sessions{}

for _, cook := range req.Cookies() {

if cook.Name == ApplicationSessionCookieName {

if id, err := url.QueryUnescape(cook.Value); err == nil {

    if s, ok := appSessionStore[id]; ok && !s.isExpired() {

       ss.app = s }

} else if strings.HasPrefix(cook.Name, SessionCookiePrefix) {

    /* … */} }

if ss.app == nil {

ss.app = &ApplicationSession{} }

now := time.Now()

expire := now.Add(SessionMinActivityTime)

if tt := ss.app.expires.Sub(now); tt > 0 && tt < SessionMinActivityTime {

      ss.app.expires = expire

      ss.app.setCookie(w)

      debug.Println(«Application session prolonged») }

   for _, ds := range ss.domino {

      /* … */}

   return &ss }

Листинг 3.4 – Зарузка сессий для текущего запроса и продление сессий

 

Если отсутствует сессия приложения, то инициализируется пустая сессия (вызов isExpired вернет истину). Это позволяет вместо двух проверок использовать только одну, так как проверка на nil становится ненужной.

В пакете domino реализован транспортный уровень для взаимодействия с IBM Domino. Для этого в данном пакете определена структура Client представляющая совокупность удаленной точки и данных для аутентификации. Над структурой Client определены методы для работы с транспортным уровнем.

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

Для подключения к IBM Domino по протоколу HTTPS используется системное хранилище сертификатов. Для обработки ошибок соединения, устанавливается максимальное время ожидания.

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

 

func load(req request) (ch chan resource) {

   url := req.url()

   httpReq, _ := http.NewRequest(«GET», url, nil)

   httpReq.Header.Set(«Accept», «application/json»)

   if req.client.Credentials.Cookies != «» {

      httpReq.Header.Set(«Cookie», req.client.Credentials.Cookies) } else {

      httpReq.SetBasicAuth(req.client.Credentials.Username, req.client.Credentials.Password) }   

   go func() {

      defer func() { <-requestLimit }()

      httpClient := http.Client{Timeout: DominoTimeout}

      resp, err := httpClient.Do(httpReq)

      ch <- resource{

         cookies: strings.Join(cookies, «;»),

         cursor: cursor,

         data: data, } }()

   return }

Листинг 3.5 – Использование клиента для протокола HTTP

 

Данные от сервера IBM Domino приходят в формате JSON. Поэтому в пакете описаны структуры, помеченные специальными тегами для автоматического декодирования из JSON строки.

 

type DominoDocument struct { Href string `json:»@href»`
Unid string `json:»@unid»`
NoteId string `json:»@noteid»`
Created iso8601_datetime `json:»@created»`
Modified iso8601_datetime `json:»@modified»`
Authors []DominoUser `json:»@authors»`
Form string `json:»@form»`
Items jsonext.CatchAll `jsonext:»catchall»` }

var list []DominoDocument
if err := jsonext.Unmarshal(res.data, &list); err != nil {
log.Printf(«%sn%sn», err, res.data[:1000])
ch <- DocumentList{Err: err}
return }

Листинг 3.6 – Пример помеченной структуры и декодирования данных

 

Поля структуры помечены тегом json, с указанием названия поля ответа. Тэг jsonextcatchall« определяет поле структуры, в которое будут записаны не опознанные поля ответа. У документа эти поля будут представлять его данные.

3.2 Описание пользовательского интерфейса

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

Стили описываются при помощи языка Less. Файлы стилей преобразуются в каскадные таблицы стилей CSS на этапе сборки веб-приложения, и объединяются в один файл с именем main.css.

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

 

a { color: @light-black;

text-decoration: none;

outline: none;

&:focus { background: @grey-200; }

&:hover{

color: @white;

background: @min-black;

}

&:active {

color: @white;

background: @light-black; } }

Листинг 3.7 – Пример описания стилей на языке Less

 

Язык Less в отличие от CSS поддерживает вложенные правила, переменные и функции. Вложенные правила удобны для описания различных состояний элемента (в примере, «&:hover» скомпилируется в «a:hover»), а переменные (в примере они начинаются с символа @) применяются для хранения каких-либо значений, общих для нескольких правил.

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

 

<!DOCTYPE html>

<html>

<head lang=»ru»>

<meta charset=»UTF-8″>

<meta name=»viewport» content=»width=device-width, initial-scale=1″>

<title>Инициализация приложения…</title>

<link rel=»stylesheet» href=»/main.css»/>

</head>

<body>

<script defer src=»/vendor.js»></script>

<script defer src=»/app.js»></script>

</body>

</html>

Листинг 3.8 – Разметка одностраничного приложения

 

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

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

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

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

Какое дерево компонентов необходимо отобразить решает роутер. В приложении используется библиотека ReactRouter.

 

var routes = (

<Route handler={Application}>

<NotFoundRoute handler={NotFoundPage}/>

<DefaultRoute handler={IndexPage}/>

<Route name=»database» path=»/r/:remote/:database»>

<DefaultRoute handler={ViewListPage}/>

<Route name=»view» path=»v/:view» handler={ViewPage} />

</Route> </Route>);

Листинг 3.9 – Конфигурация маршрутизатора веб-приложения

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

 

return (
<DocumentTitle title=»Учетная запись IBM Domino»>

<Canvas>

<ApplicationBar title=»Учетная запись IBM Domino»/>

<RouteHandler {…this.props}/>

</Canvas>

</DocumentTitle>

)

Листинг 3.10 – Отображение дочерних обработчиков

 

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

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

Пример реализации обработчиков:

 

getInitialState() {

return {

data: undefined,

page: undefined

}; },

componentDidMount() {

this.getRows(this.props); },

componentWillReceiveProps(nextProps) {

var page = nextProps.query.page || 1;

if (page != this.state.page) {

this.getRows(nextProps); } }

Листинг 3.11 – Пример обработки некоторых событий жизненного цикла компонента

 

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

3.3 Методы и средства защиты программного продукта

Для доступа к приложению необходима аутентификация на каком-либо сервере данных при помощи логина и пароля. Эта связка используется сервером IBM Domino для авторизации доступа к ресурсам баз данных. Управление учетными записями пользователей и управление доступом осуществляется через программное обеспечение IBM Domino Administrator.

Для обеспечения безопасности передачи данных по каналам «веб-сервер – IBM Domino» и «веб-сервер – браузер пользователя» приложение реализует поддержку защищенного протокола HTTPS [18]. Для этого необходимо включить для выбранной точки безопасный режим в конфигурационном файле и указать путь к файлу сертификата.

Запуск веб-сервера по протоколу HTTPS реализуется при помощи кода:

 

if config.Current.Web.Secure {
   s.ListenAndServeTls(config.Current.Web.Cert, config.Current.Web.PrivateKey) }

Листинг 3.12 – Запуск сервера по протоколу HTTPS

 

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

Чтобы предотвратить похищение cookies, они передаются только при запросах к серверу и не доступны из JavaScript. Это реализуется установкой флага HttpOnly при отправке cookies браузеру пользователя.

 

return &http.Cookie{

   Name: name,

   Value: value,

   Secure: config.Current.Web.Secure,

   HttpOnly: true,

   Expires: expires,

   MaxAge: int(expires.Sub(time.Now()).Seconds()),

   Path:»/rest», }

Листинг 3.13 – Задание свойств при установке cookies

В общем случае, для установки Cookie необходимо указать имя и значение. Тем не менее, во избежание проблем, рекомендуется всегда устанавливать следующие свойства: Secure (если истина, Cookies передаются только по протоколам с шифрованием), HttpOnly (Cookies недоступны для JavaScript, увеличивает стойкость к атакам на их похищение), Path (путь установки, если не указан, принимается равным текущему адресу) и один из параметров Expires или MaxAge (в данном примере установлены оба, для поддержки старых браузеров).

3.4 Тестирование и оценка надежности программного продукта

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

Автоматизированное тестирование реализовано с использованием стандартных средств языка программирования Go [1]. Общая структура отдельного теста представлена ниже.

 

package rest

import «testing»

func TestEmptySessionExpired(t *testing.T) {

   s := Session{}

   if !s.isExpired() {

      t.Fail() } }

Листинг 3.14 – Пример атвоматизированного тестирвания обьекта сессии

 

Тестовые методы находятся в одном пакете с тестируемым исходным кодом, в файлах с именем, заканчивающимся на «*_test.go». Название каждого метода начинается со слова Test. Стандартная библиотека содержит пакет testing, который позволяет проводить модульное и интеграционное тестирование.

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

Запуск тестов производится командой «go test [название пакета]». Пример вывода показан на рисунке 3.1.

 

Not Supported

Рисунок 3.1 – Результат запуска команды go test в различных пакетах

 

На рисунке видно, что в пакетах rest и domino все тесты были завершены успешно, а в пакете webclient автоматизированные тесты отсутствуют.

Автоматизированные тесты утилитных методов пакета domino позволили найти несколько ошибок в распознавателе HTTP-заголовка Content-Range, используя метод тестирования граничных значений, получение которых от тестового сервера IBM Domino было бы затруднительно.

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

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

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

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

3.5 Расчет себестоимости

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

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

В структуре капитальных вложений, связанных с автоматизацией управления, выделяют капитальные вложения на разработку проекта автоматизации (предпроизводственные затраты) и капитальные вложения на реализацию ВКР (затраты на внедрение):

К = Кп + Кр,                                             (3.1)

где Кп – капитальные вложения на проектирование;

Кр – капитальные вложения на реализацию ВКР.

Расчет капитальных вложений на проектирование. Капитальные вложения на проектирование ПС определяются путем составления смет расходов и определяются по формуле:

Кпм+ Кпр + Кмаш + Кс + Кн,                       (3.2)

где Кмстоимость материалов;

Кпр заработная плата основная и дополнительная с отчислениями в соцстрах инженерно-технического персонала, занятого разработкой ВКР;

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

Кс оплата услуг сторонним организациям, если проектирование производится с привлечением сторонних организаций;

Кн накладные расходы отдела проектирования.

Все расчеты будут производиться в условных единицах (у.е.), что соответствует стоимости одного доллара США в Приднестровском Республиканском Банке на момент разработки ПС.

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

Смета затрат на расходные материалы представлена в таблице 3.1.

Таблица 3.1 – Смета затрат на расходные материалы

Материал Единицаизмерения Цена заединицу (у.е.) Количество Сумма (у.е.)
CD-RW диск Шт. 0,50 1 0,50
Бумага Пач. 5 1 5
Ручка Шт. 0,30 2 0,60
Тонер картридж Шт. 15 1 15
Папка Шт. 0,2 1 0,2
ИТОГО 21,30
Транспортно-заготовительные расходы (5 %) 1,115
ВСЕГО 22,415

Затраты на оплату труда. Затраты на основную заработную плату проектировщика (Кпр) рассчитывается на основе данных о квалификационном составе разработчиков, их должностных окладах и общей занятости по теме. Дополнительная заработная плата начисляется в размере 10% от суммы основной заработной платы, а отчисления на социальные страхования – в размере 39% от фонда заработной платы.

Смета затрат на оплату труда представлена в таблице 3.2.

Таблица 3.2 – Смета затрат на оплату труда

Должность работника Должностной оклад (у.е.) Дневная ставка Занятостьпо теме Сумма основной з/п (у.е.)
Программист 150 5.9 70 483
Руководитель
программного продукта
180 6.5 45 314,5
ИТОГО 797,5 у.е.

Итого Кпр = 797,5 у.е

Затраты на отладку программы. Затраты, связанные с использованием машинного времени на отладку программы (Кмаш) учитываются для следующих этапов проектирования: разработка рабочего проекта; внедрение — проведение опытной эксплуатации задач и сдача их в промышленную эксплуатацию.

Затраты на отладку программы определяются по формуле:

,                              (3.3)

где  – стоимость одного часа машинного времени;

– время отладки программы (ч);

– количество программистов.

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

Смч = 0,4 у.е., tотл = 72 часов,

Sпр = 1 программист Кмаш = 0,4·72·1 =28,8 у.е.

В связи с тем, что сторонние организации не привлекались к работе, то Кс = 0.

Накладные расходы на разработку ВКР берутся в размере 45% от основной заработной платы разработчиков:

Кн = Кпр·0,45.                                           (3.4)

Так как затраты на основную заработную плату проектировщика (Кпр) равны 797,5 у.е., то накладные расходы составят: Кн = 797,5*0,45 = 358,9 у.е.

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

Таблица 3.3 – Общая смета затрат на проектирование

Статьи Затраты
Сумма (у.е.) Удельный вес статьи в общей стоимости (%)
Материалы и покупные полуфабрикаты 22,415 1,43
Основная заработная плата 797,50 50,88
Дополнительная заработная плата 79,75 5,08
Отчисления на единый социальный налог 280 17,86
Затраты на отладку программы 28,8 1,83
Накладные расходы 358,9 22,89
ИТОГО: 1567,40 100

Итого общая величина капитальных вложений на реализацию ВКР составляет 1567,40 у.е.

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

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

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

Сэз = Смч ·Тэ,                                             (3.4)

где Смч – стоимость одного часа работы технических средств;

Тэ – время эксплуатации задачи в течение года.

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

Сэз  = 0,1·1056 = 105,6 у.е.

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

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

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

Расчет экономии за счет снижения трудоемкости решения задачи. Экономия за счет снижения трудоемкости решения определенного класса задач, рассчитывается по формуле:

Этр = (А · В · Тр· Зчас Кр· Тоб · Смч) · Ue,                           (3.5)

где  А – коэффициент, учитывающий дополнительную заработную плату;

В – коэффициент, учитывающий отчисления на соцстрах;

Тр – трудоемкость решения задачи вручную (ч);

Зчас – среднечасовая тарифная ставка работника (у.е.);

Кр – коэффициент использования технических средств;

Тоб – трудоемкость при автоматизированной обработке (ч);

Смч – стоимость одного машинного часа работы (у.е.);

Ue – периодичность решения задачи (раз/год).

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

А = 1,1; В = 1,27; Тр = 2 ч; Зчас = 0,974 у.е. (при основной заработной плате 150 у.е., 8-мичасовом рабочем дне, 22 рабочих дня в месяц);

Кр = 1,17; Тоб = 0,2 ч; Смч = 0,05 у.е.;  Ue = 850 раз в год.

Этр = (1,1·1,27·2·0,974 – 1,13·0,2·0,05) ·850 = 2303,25 у.е.

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

Эстр – Ен·Кп – Сэз,                                                   (3.6)

где   Этр – годовая экономия от применения внедренной задачи;

Ен – нормативный коэффициент экономической эффективности капитальных вложений (Ен = 0,15);

Кп – единовременные затраты, связанные с внедрением задачи;

Подставляя в формулу (3.6) реальные данные, определяем величину годового экономического эффекта при Кп = 1567,40 у.е:

Эс = 2303,25 – 0,15·1567,40-105,6 = 1962,54 у.е.

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

Ерс = Эсп.                                                                  (3.7)

Подставляя в формулу фактические данные, определяем величину экономической эффективности: Ерс = 1962,54 / 1567,4= 1,25.

Так как Ерс > Ен, то внедрение экономически эффективно. Определяем срок окупаемости внедренной задачи:

Те = Кпс = 1567,4/ 1962,54 = 0,8 года.

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

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

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

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

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

Площадь рабочего места не должна быть меньше 6 м², высота потолка должна быть не менее 4 м, а объем – не менее 20 м3 на одно рабочее место. Высота рабочего стола оператора должна быть подобрана индивидуально под работника или иметь регулируемую высоту в пределах 680 – 780 мм. Рекомендуемые габариты поверхности стола 1600х1000 мм2.

Рекомендуется наличие подставки для ног, под углом 15° к поверхности стола. Длина подставки от 400 мм, и ширина – 350 мм. Расстояние от края стола до клавиатуры не более 300 мм. Расстояние до монитора 40-80 см. Монитор необходимо расположить на такой высоте, которая обеспечит работу оператора без наклона головы вперед или назад [4].

Кресло должно иметь подъемно-поворотный механизм. Высота сиденья должна настраиваться в пределах 400 – 500 мм. Глубина и ширина должна соответствовать телосложению оператора. Опорная спинка должна быть не менее 300 мм высотой, и 380 мм шириной. Рекомендуются кресла с настраиваемым углом наклона спинки.

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

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

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

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

Сопротивление группового заземлителя рассчитывается, если:

  • мощность установки менее 5 кВА;
  • вертикальный заземлитель – это прут 35 мм в диаметре и длиной 3,5 м выполненный из стали;
  • горизонтальный заземлитель – стальная полоса шириной 35 мм, и толщиной 8 мм;
  • удельное сопротивление грунта (глина) 70 Ом*м.

Сопротивление одиночного вертикального заземлителя рассчитывается по формуле:

,                                                   (3.8)

,

где   — удельное сопротивление грунта (Ом*м);

l — длина вертикального заземлителя (м);

d — диаметр вертикального заземлителя (м);

t — глубина заложения.

,                                             (3.9)

.

Расстояние между заземлителями (м):

,                                               (3.10)

.

Ориентировочное количество вертикальных заземлителей (шт):

,                                                   (3.11)

где Rзаз – нормируемая величина сопротивления заземления (Rзаз=4Ом);

Количество горизонтальных заземлителей определяется по формуле:

,                                              (3.12)

где  – коэффициент использования вертикальных заземлителей (так как ориентировочное n=4 и la=3.5, поэтому 0,8).

Длина горизонтального заземлителя (м):

,                                           (3.13)

.

Сопротивление горизонтального заземлителя рассчитывается по формуле:

,                                        (3.14)

где b1 – ширина полосы (м)

.

Сопротивление группового заземлителя:

,                                        (3.15)

где  – коэффициент использования горизонтальных заземлителей ()

,

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

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

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

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

Здание оборудовано пожарным водопроводом высокого давления с пожарными кранами.

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

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

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

—         неисправность электропроводки, розеток и выключателей;

—         использование неисправных электроприборов;

—         использование в помещении электронагревательных приборов с открытыми нагревательными элементами;

—         возгорание здания вследствие внешних воздействий;

—         несоблюдение мер пожарной безопасности.

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

Площадь рабочего места не должна быть меньше 6 м², высота потолка должна быть не менее 4 м, а объем – не менее 20 м3 на одно рабочее место. Высота рабочего стола оператора должна быть подобрана индивидуально под работника или иметь регулируемую высоту в пределах 680 – 780 мм. Рекомендуемые габариты поверхности стола 1600х1000 мм2.

Рекомендуется наличие подставки для ног, под углом 15° к поверхности стола. Длина подставки от 400 мм, и ширина – 350 мм. Расстояние от края стола до клавиатуры не более 300 мм. Расстояние до монитора 40-80 см. Монитор необходимо расположить на такой высоте, которая обеспечит работу оператора без наклона головы вперед или назад [4].

Кресло должно иметь подъемно-поворотный механизм. Высота сиденья должна настраиваться в пределах 400 – 500 мм. Глубина и ширина должна соответствовать телосложению оператора. Опорная спинка должна быть не менее 300 мм высотой, и 380 мм шириной. Рекомендуются кресла с настраиваемым углом наклона спинки.

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

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

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

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

Сопротивление группового заземлителя рассчитывается, если:

  • мощность установки менее 5 кВА;
  • вертикальный заземлитель – это прут 35 мм в диаметре и длиной 3,5 м выполненный из стали;
  • горизонтальный заземлитель – стальная полоса шириной 35 мм, и толщиной 8 мм;
  • удельное сопротивление грунта (глина) 70 Ом*м.

Сопротивление одиночного вертикального заземлителя рассчитывается по формуле:

,                                                   (3.8)

,

где   — удельное сопротивление грунта (Ом*м);

l — длина вертикального заземлителя (м);

d — диаметр вертикального заземлителя (м);

t — глубина заложения.

,                                             (3.9)

.

Расстояние между заземлителями (м):

,                                               (3.10)

.

Ориентировочное количество вертикальных заземлителей (шт):

,                                                   (3.11)

где Rзаз – нормируемая величина сопротивления заземления (Rзаз=4Ом);

Количество горизонтальных заземлителей определяется по формуле:

,                                              (3.12)

где  – коэффициент использования вертикальных заземлителей (так как ориентировочное n=4 и la=3.5, поэтому 0,8).

Длина горизонтального заземлителя (м):

,                                           (3.13)

.

Сопротивление горизонтального заземлителя рассчитывается по формуле:

,                                        (3.14)

где b1 – ширина полосы (м)

.

Сопротивление группового заземлителя:

,                                        (3.15)

где  – коэффициент использования горизонтальных заземлителей ()

,

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

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

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

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

Здание оборудовано пожарным водопроводом высокого давления с пожарными кранами.

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

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

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

—         неисправность электропроводки, розеток и выключателей;

—         использование неисправных электроприборов;

—         использование в помещении электронагревательных приборов с открытыми нагревательными элементами;

—         возгорание здания вследствие внешних воздействий;

—         несоблюдение мер пожарной безопасности.

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ, ЕДИНИЦ И ТЕРМИНОВ

ВКР – выпускная квалификационная работа.

ОС – операционная система.

ПК – персональный компьютер.

ПО – программное обеспечение.

ПС – программные средства.

ЭВМ – электронная вычислительная машина.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
  1. Doxsey, Caleb. An Introduction to Programming in Go. – Издательство: «CreateSpace Independent Publishing Platform», 2012. – 166 с.
  2. Флэнаган, Дэвид. JavaScript. Подробное руководство. –
    Издательство: «Символ– Плюс», 2012. – 700 с.
  3. СанПин 2.2.2/2.4.1340-03. Гигиенические требования к персональным электронно-вычислительным машинам и организации работы, 2007.
  4. СНиП ПМР 31-20-02. Электротехнические устройства, 2002.
  5. СНиП 21-01-03. Пожарная безопасность зданий и сооружений, 2003.
  6. Christopher Chedeau. React’s diff algorithm [Электронный ресурс]. – 2013. – Режим доступа: http://calendar.perfplanet.com/2013/diff/

Facebook. Документация библиотеки ReactJS [Электронный ресурс]. – 2015. – Режим доступа: http://facebook.github.io/react/

  1. Google Inc. Material Design [Электронный ресурс]. – 2015. –
    Режим доступа: http://google.com/design/
  2. Google Inc. The Go Programming Language Specification
    [Электронный ресурс]. – 2015 – Режим доступа: http://golang.org/ref/spec
  3. IBM Corporation. IBM Domino [Электронный ресурс]. – 2015 –
    Режим доступа: http://www-03.ibm.com/software/products/en/ibmdomino

IBM Corporation. Domino Data Services [Электронный ресурс]. – 2011. –
Режим доступа: http://www-10.lotus.com/ldd/ddwiki.nsf/xpAPIViewer.xsp?look
upName=IBM+Domino+Access+Services+9.0.1.

  1. IBM Corporation. The ABC’s of using the ACL [Электронный ресурс]. – – Режим доступа: http://www.ibm.com/developerworks/lotus/library/ls-Using_the_ACL/
  2. IBM Corporation. Domino Field Types [Электронный ресурс]. – 2015 – Режим доступа: http://www-01.ibm.com/support/knowledgecenter/SSVRGU5.3/
    com.ibm.designer.domino.main.doc/H_ABOUT_ASSIGNING_DATA_
    TYPES_FOR_FIELDS.html
  3. IBM Corporation. Introduction to the JavaScript and XPages reference [Электронный ресурс]. – 2015 – Режим доступа: http://www-01.ibm.com/support/
    knowledgecenter/SSVRGU_9.0.1/com.ibm.designer.domino.api.doc/
    html?cp=SSVRGU_9.0.1%2F3
  4. IBM Corporation. Scheduling server-to-server replication [Электронный ресурс]. – 2008. – Режим доступа: http://www-01.ibm.com/support/
    knowledgecenter/SSKTMJ_8.0.1/com.ibm.help.domino.admin.doc/DOC/
    html.
  5. URL [Электронный ресурс]. – 2015 –
    Режим доступа: https://ru.wikipedia.org/wiki/URL
  6. JSON [Электронный ресурс]. – 2015 – Режим доступа: http://json.org/
  7. HTTPS [Электронный ресурс]. – 2015 –
    Режим доступа: https://ru.wikipedia.org/wiki/HTTPS
  8. Туннелирование в компьютерных сетях [Электронный ресурс]. – 2015 – Режим доступа: https://ru.wikipedia.org/wiki/Туннелирование_
    (компьютерные_сети)

ПРИЛОЖЕНИЕ А

Статьи

Затраты

Сумма (у.е.)

Удельный вес статьи в общей стоимости (%)

Материалы и покупные полуфабрикаты

22,415

1,43

Основная заработная плата

797,50

50,88

Дополнительная заработная плата

79,75

5,08

Отчисления на единый социальный налог

280

17,86

Затраты на отладку программы

28,8

1,83

Накладные расходы

358,9

22,89

ИТОГО:

1567,40

100

СОДЕРЖАНИЕ

1 РУКОВОДСТВО ПО ЭКСПЛУАТАЦИИ PAGEREF _Toc422433680 h 56

1.1 Установка и настройка веб-сервера PAGEREF _Toc422433681 h 56

1.2 Настройка сервера IBM Domino PAGEREF _Toc422433682 h 57

1.3 Диагностика и устранение неполадок PAGEREF _Toc422433683 h 60

2 РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ PAGEREF _Toc422433684 h 61

1 РУКОВОДСТВО ПО ЭКСПЛУАТАЦИИ
1.1 Установка и настройка веб-сервера

Установка веб-сервера осуществляется путем копирования исполняемого файла в место установки. Настройка производится путем редактирования файла webclient.rc в папке с исполняемым файлом.

Пример конфигурационного файла:

 

web:
addr: 192.168.137.1:5000
https: true cert: selfsigned.crt privateKey: id_rsadomino: design: ./domino

remotes: vbox-local:
name: Виртуальная машина addr: 192.168.56.101:5000
https: false offline:
name: Недоступный сервер
addr: 192.168.56.102:433
https: true

Листинг А.1 – Пример конфигурационного файла

 

Секция web описывает настройки веб-сервера. Если параметр https установлен в значение true, то необходимо в параметре cert указать путь к файлу сертификата, а в privateKey – путь к файлу с закрытым ключом.

В секции domino перечислены все доступные сервера IBM Domino. Указывать пути к сертификатам, для этих серверов не требуется. Параметр design указывает путь к конфигурационным файлам баз данных.

По указанному пути должны находится папки, с именами, соответствующими названиям файлов баз данных (включая расширение). Для каждого представления, которое необходимо отобразить в интерфейсе, необходимо создать файл в подпапке views с названием <viewid>.rc. Где <viewid> это универсальный идентификатор. Данный идентификатор можно найти, открыв представление в IBM Domino Designer (рисунок А.1)

Not Supported

Рисунок А.1 – Место отображения универсального идентификатора представления

 

В подпапке forms хранятся настройки отображения документов. Внешний вид настраивается отдельно для каждой формы, в файле <form>.rc, где <form> это название формы IBM Domino.

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

1.2 Настройка сервера IBM Domino

Для возможности подключения к серверу IBM Domino необходимо включить Domino Data Serices и дать доступ к нужным базам данных. Проще всего это сделать через программное обеспечение IBM Domino Administrator. После подключения к серверу, на вкладке Configuration необходимо выбрать конфигурационный документ и нажать кнопку Edit Server (рисунок А.2).

 

Not Supported

Рисунок А.2 – Редактирование настроек сервера

 

После чего, в открывшейся форме необходимо перейти на вкладку Ports, где выбрать дочернюю вкладку Internet Protocols (рисунок А.3).

 

Not Supported

Рисунок А.3 – Настройка HTTP протокола IBM Domino

 

На открытой вкладке будут две группы настроек. Группа настроек SSL settings отвечает за настройку сертификата для HTTPS протокола. Группа настроек Web содержит общие параметры HTTP подключения (рисунок А.4).

 

Not Supported

Рисунок А.4 – Настройка протоколов HTTP(S) в IBM Domino

 

Для выбранного протокола необходимо установить опцию «Name & password» в значение Yes. После этого необходимо включить Data в группе Domino Access Services на вкладке Internet. (Internet Protocols —> Domino Web Engine -> Domino Access Servicesпоявился в 8,5 версии сервака Домино)

Включение Data Services выполняется отдельно для каждой базы данных. Для этого необходимо в диалоге свойств базы данных установить Allow Domino Data Service в значение Views and documents (рисунок А.5).

 

Рисунок А.5 – Включение Data Services для базы данных

 

После этого необходимо включить Data Services для необходимых представлений внутри базы данных. Сделать это можно в свойствах представления, отметив галочкой Allow Domino Data Service operations (рисунок А.6, сначала необходимо открыть базу данных в IBM Domino Designer).

 

Not Supported

Рисунк А.6 – Включение Data Services для представления

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

 

> webclient —debug

Листинг А.2 – Запуск веб-сервера в режиме ведения расширенного лога событий

 

После этих действий необходимо открыть файл notes.ini в текстовом редакторе (этот файл находится в папке с базами данных). Необходимо убедиться, что в параметре Server Tasks перечислен сервис http.

После всех этих операций необходимо перезапустить IBM Domino. Это можно сделать из интерфейса IBM Domino Administrator. Чтобы убедиться, что все настроено верно, необходимо открыть в браузере http://адрес-сервера:порт (если вы настраивали защищенный протокол, то используйте https вместо http).

1.3 Диагностика и устранение неполадок

В первую очередь при диагностике неполадок необходимо включить расширенный лог событий (листинг А.2) и определить причину неполадки.

Дополнительно можно прочитать раздел устранения неполадок в документации Dominohttp://www-10.lotus.com/ldd/ddwiki.nsf/xpAPIViewer.xsp?lookupName=IBM+Domino+Access+Services+9.0.1#action=OpenDocument
&
res_title=Troubleshooting_Domino_Data_Service_das901&content=apicontent.

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

Убедится в работе сервера IBM Domino, можно открыв в адресной строке браузера адрес <адрес удаленного сервера>:<http порт>/api/data.

2 РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

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

Если приложение правильно настроено и запущено, после открытия адреса в браузере откроется форма входа. В эту форму (рисунок А.7) необходимо вводить данные от учетной записи IBM Domino.

 

Not Supported

Рисунок А.7 – Форма входа в приложение

 

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

После успешной аутентификации, будет отображен веб-интерфейс приложения. Данный интерфейс состоит из двух логических блоков: панели приложения и области данных. В панели приложения отображается название текущей страницы, кнопка навигации на уровень вверх, и кнопка отображения списки активных сессий (рисунок А.8).

Not Supported

Рисунок А.8 – Внешний вид панели веб-приложения с отображенным списком сессий

 

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

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

Список баз данных и представлений представлены в линейной форме, с разбиением на группы (рисунок А.9).

 

Not Supported

Рисунок А.9 – Внешний вид двух соседних групп в списках

На страницах списков поддерживается поиск и вывод на печать. Для печати содержимого веб-страницы необходимо вызвать стандартный диалог печати используемого веб-браузера (рисунок А.10).

 

Not Supported

Рисунок А.10 – Диалог печати списка доступных представлений

 

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

 

Not Supported

Рисунок А.11 – Табличное представление документов

 

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

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

Если выполнить щелчок левой кнопкой мыши по строке документа, откроется страница документа (рисунок А.12).

 

Not Supported

Рисунок А.12 – Пример внешнего вида документа

 

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

В конце документа идет список полей документа в табличном виде.

Скачать: 

Загрузка...