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

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

IDEF

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

· IDEF0: Function modeling;

· IDEF1: Information modeling;

· IDEF1X: Data modeling;

· IDEF2: Simulation model design;

· IDEF3: Process description capture;

· IDEF4: Object-oriented design;

· IDEF5: Ontology description capture;

· IDEF6: Design rationale capture;

· IDEF7: Information system auditing;

· IDEF8: User interface modeling;

· IDEF9: Business constraint discovery;

· IDEF10: Implementation architecture modeling;

· IDEF11: Information artifact modeling;

· IDEF12: Organization modeling;

· IDEF13: Three schema mapping design;

· IDEF14: Network design.

Тем не менее была завершена разработка только 4 из данных стандартов [10], а именно IDEF0, IDEF1X, IDEF2, IDEF3 и IDEF4. Разработка остальных стандартов не была завершена или же вовсе ограничилась только фиксацией первоначального определения их задач.

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

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

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

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

Обоснование выбора нотации

В результате проведенного анализа для документирования разрабатываемой архитектуры информационной системы была выбрана нотация UML. Основной причиной данному решению явилась наибольшая популярность данного языка моделирования по отношению к семейству языков IDEF [11]. Помимо этого, UML предоставляет большее количество различных средств описания структуры сложных программных решений, необходимых в данном проекте, а именно:

· Позволяет описывать заложенные в информационной системе процессы с точки зрения жизненного цикла объектов (диаграмма последовательности);

· Содержит инструменты для описания взаимодействия пользователей и системы (диаграмма вариантов использования);

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



Глава 3. Разработка проекта информационной системы

3.1 Диаграмма развёртывания

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

Стоит отметить, что архитектура описываемого решения рассчитана на модель распространения «on-premise», которая подразумевает развёртывание информационной системы в ландшафте ИТ-инфраструктуры организации, собирающейся её использовать, то есть не рассчитана на предоставление к ней доступа по требованию независимых друг от друга компаний, как это принято в модели SaaS (Software as a Service).

Рисунок 2, Диаграмма развёртывания проектируемой информационной системы

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

Domain Name System (DNS) Server. Данный элемент является общепринятым при рассмотрении общей архитектуры приложения, поскольку служит для обеспечения доступа пользователей к различным ресурсам. Тем не менее, в данной работе его настройка рассматриваться не будет, поскольку данный элемент не является обязательным при развёртывании проектируемой системы, так как взаимодействие с ней может осуществляться с использованием HTTP-запросов по прямым IP-адресам. Более того, настройка данного ресурса будет сильно зависеть от специфики работы компаний, а также установленных в их рамках политик безопасности и средств управления ИТ-инфраструктурой.

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

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

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

Кластер серверов баз данных «ключ-значение». Данный элемент обобщает один или несколько серверов баз данных класса «ключ-значение», которые могут быть использованы для хранения оперативной информации, необходимой для функционирования системы. Стоит отметить, что данный элемент также не является обязательным: данные, которые содержат базы данных «ключ-значения» так же могут быть размещены в соответствующих таблицах используемой реляционной базы данных, содержаться в пользовательской сессии, пересылаться в cookie или храниться в файловой системе - в зависимости от предназначения. К таким данным могут относиться ключи доступа, оперативные сведенья о работе пользователей (например, открытые в данный момент страницы) и другие. Преимуществом баз данных «ключ-значение» по отношению к реляционным базам данных является скорость, с которой они обрабатывают запросы и возвращают данные, что достигается при помощи хранения информации в оперативной памяти, а также возможность автоматического удаления данных по истечению какого-либо времени путём использования встроенных средств СУБД.

Кластер серверов очередей и кластер worker-серверов. Менеджеры очередей позволяют не только управлять нагрузкой на сервера приложений, распределяя её между worker-серверами, делая возможным использование дополнительных вычислительных ресурсов в рамках обработки пользовательских запросов, но также позволяют решать задачу асинхронных вычислений, когда информация, необходимая пользователю уже готова для возвращения, однако процессы, необходимые для функционирования системы ещё не были завершены, в следствие чего пользователь обязан ждать дольше, чем требует его задача. Некоторые технологии разработки, как, например, .NET имеют встроенные средства для решения данной задачи, однако такие языки разработки, как PHP или Python их не содержат, что приводит к необходимости использования сторонних решений.

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

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

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

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

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

· Операционная система: Linux

· Язык разработки: PHP

· Фреймворк разработки: Laravel

· СУБД: PostgreSQL

· Веб-сервер: Apache

· Key-Value база данных: Redis

· Сервер PUSH-уведомлений: Thruway

· Менеджер очередей: Gearman

· Система контроля процессов: Supervisor

· Балансировщик нагрузки: Haproxy

3.2 Функциональные модули системы

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

Рисунок 3, Структура функциональных модулей проектируемой информационной системы

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

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

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

В связи с возможностью достаточно чёткого разграничения между функциональными модулями системы, при проектировании системы будут использованы микросервисы. Микросервисы - это вариант сервис-ориентированной архитектуры (Service-Oriented Architecture - SOA), которая представляет приложение в виде набора слабо связанных между собой сервисов [13]. Преимуществом разбиения приложения на различные небольшие сервисы является то, что оно улучшает модульность и облегчает понимание, разработку и тестирование приложения. Оно также позволяет распараллеливать разработку, позволяя небольшим автономным командам самостоятельно проектировать, имплементировать, развертывать и масштабировать доверенные им сервисы.

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



3.3 Ролевая модель системы

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

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

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

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

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

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

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

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

3.4 Модуль управления объектами

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

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



Структура данных

Рисунок 4, Структура данных модуля управления объектами системы

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

Описание классов

Стоит отметить, что данные классы не содержат в себе интерфейсов для взаимодействия с другими программными модулями, поскольку это нарушало бы принцип работы архитектуры микросервисов. Данные интерфейсы должны быть представлены в виде отдельного сервиса (репозитория), к которому в последствии будут обраться другие программные модули для взаимодействия. Список публичных функций данного сервиса и, в случае необходимости, описания их работы будут приведены после описания объектов, которые в нём используются. Основное же назначение данных объектов - произведение CRUD (Create, Read, Update, Delete) операций.

Object. Объекты данного класса содержат в себе определение отдельно взятого объекта, используемого системой (например, Рабочая группа, Пользователь, Компания и другие). Они могут быть использованы для получения информации об объекте, а также содержать в себе агрегационные функции, не относящиеся каким-либо отдельно взятым элементам объекта, а к их совокупности. Такими функциями могут быть получение списка полей для отображения на форме, удаление объекта, создание с ним связи и другие. В нём содержатся такие атрибуты, как:

· ID. Идентификационный номер объекта;

· Name. Системное имя объекта, используется при формировании имени таблицы, хранящей данные об экземплярах данного класса (например, Group);

· DisplayName. Отображаемое имя объекта (например, Рабочая группа);

· hasAudit. Ведётся ли аудит внесения изменений в данный объект;

· hasObjectLog. Требуется ли отображать на форме данного объекта журнал работ;

· System. Является ли объект системным, то есть необходимым для корректного функционирования системы, или был создан пользователями. В случае, если объект не является системным, администратору системы даётся доступ к редактированию всех атрибутов данного объекта;

· Deletable. Допускается ли удаление данного объекта;

· DisplayNameAttribute. Ссылка на атрибут объекта, который содержит отображаемое имя (например, ID атрибута Name в объекте пользователя).

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

· ID. Идентификационный номер атрибута;

· Name. Системное название атрибута. Обязано совпадать с именем столбца в таблице соответствующего объекта (например, Name);

· DisplayName. Отображаемое имя атрибута (например, Имя);

· isPicklist. Является ли данный атрибут фиксированным списком;

· ObjectID. Ссылка на объект, содержащий данный атрибут;

· LinkedObjectID. Ссылка на объект, на который ссылается данный объект;

· DisplayOnForm. Отображается ли данный атрибут на форме;

· Editable. Редактируется ли данный атрибут;

· AttributeTypeID. Ссылка на объект AttributeType, содержащий информацию о типе отображения атрибута;

· System. Данный атрибут объекта отвечает за то, возможно ли изменение параметров данного экземпляра атрибута пользователями системы. Он служит для того, чтобы такие атрибуты, как ID, дата создания и изменения не удалялись и не изменялись пользователями системы.

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

· ID. Идентификационный номер типа отображения;

· Name. Системное имя типа отображения. Может быть использовано в процессе разработки программного кода;

· DisplayName. Отображаемое имя типа отображения. Используется при выводе возможных вариантов отображения при редактировании объектов.

AttributePicklistValue. Объекты данного класса содержат информацию о возможных для выбора элементах фиксированных списков.

· ID. Идентификационный номер записи;

· AttributeID. Ссылка на атрибут, являющийся фиксированным списком, который содержит данный вариант выбора;

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

· DisplayName. Отображаемое имя данного варианта выбора.

ObjectMap. Экземпляры данного класса содержат информацию о связях типа «Many-to-Many» между различными объектами. Вынесение их в таблицу базы данных позволяет при помощи настроек системы определять данные связи, что позволяет устанавливать взаимоотношения между объектами без прибегания к изменению программного кода.

· ID. Идентификационный номер типа отображения;

· SourceObjectID. ID объекта, являющегося источников данной связи;

· TargetObjectID. ID объекта, являющегося целью данной связи;

· SourceDisplayName. Название связи, отображающееся в исходном объекте;

· TargetDisplayName. Название связи, отображающееся в целевом объекте.

Relationship. Объекты данного класса являются экземплярами соответствующих связей, указанных в ObjectMap.

· ID. Идентификатор экземпляра связи;

· ObjectMapID. Ссылка на тип связи, экземпляром которой является данная запись;

· SourceInstanceID. ID объекта-источника данной связи;

· TargetInstanceID. ID объекта-цели данной связи.

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

· ID. Идентификатор определения условного атрибута.

· ObjectID. Ссылка на объект, которому принадлежит данное определение условного атрибута.

· DisplayName. Отображаемое имя условного атрибута.

· isPicklist. Является ли условный атрибут фиксированным списков.

· LinkedObjectID. Ссылка на объект, на который ссылается данный условий атрибут.

· AttributeTypeID. Ссылка на тип отображения данного атрибута.

· Filter. Данное поле содержит строку со вставками, содержащими идентификаторы CustomAttributeCondition, что позволяет сохранять взаимосвязь между условиями отображения. Примером такой строки может являться (({ID1} AND {ID}) OR {ID3}), где ID1, ID2, ID3 - идентификаторы CustomAttributeCondition.

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

· ID. Идентификатор условия наличия условного атрибута;

· ObjectAttributeID. Ссылка на атрибут объекта, значение которого будет исследоваться;

· ComparisonOperator. Оператор сравнения значений. Может являться как простым математическим оператором, так и оператором работы с множествами, такими как «intersect», «IN» и другие;

· ComparisonValue. В данном поле содержится значение, с которым будет сравниваться значения поля, на который указывает ObjectAttributeID. Помимо строковых значений данное поле может содержать вызовы заранее предопределённых функций, таких как:

o Мои группы;

o Объекты, связанные через определённую связь, указанную в ObjectMap с возможностью указания ID данной связи в вызове;

o Мои роли.

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

· ID. Идентификатор значения условного атрибута;

· CustomAttributeID. Ссылка на определение условного атрибута, с помощью которого можно определить класс дополняемого объекта;

· Value. Значение условного атрибута;

· InstanceID. Идентификатор экземпляра объекта, дополняемого данным значением.

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

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

Модуль управления объектами должен содержать следующие функции:

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

· Редактирование объекта. На основании передающихся в данную функцию параметров, в текущие таблицы описания объектов должны вноситься соответствующие корректировки;

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

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

· Сохранение данных об экземпляре объектов. На основании переданных в данную функцию параметров, она должна обновлять связанные с данным объектом записи в базе данных;

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

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

· Добавление записей в журнал работ данного объекта и их удаление;

· Прикрепление вложений к данному объекту и их удаление;

· Получение вложений, прикреплённых к данному объекту;

· Получение журнала работ по данному объекту.

Список форм к разработке

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

· Форма создания и редактирования объектов. Она должна позволять в автоматическом или полуавтоматическом режиме создавать все перечисленные выше объекты и заполнять их данными.

· Форма универсального объекта. Данная форма должна состоять из отдельных атрибутов, вёрстка которых формируется на основании параметров их отображения, содержащихся в таблице атрибутов (Приложение, Рисунок 10).

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

· Модуль НСИ:

o Получение роли пользователя;

3.5 Модуль настройки системы

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

Структура данных

Рисунок 5, Структура данных модуля настройки системы

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

· ID. Идентификационный номер пункта меню;

· Address. URN перехода данного пункта меню;

· DisplayName. Отображаемое имя данного пункта меню;

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

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

· Icon. Данное поле содержит в себе строку, являющуюся набором CSS-классов (Font Awesome, Glyphicons или другие), которая может быть вставлена в соответствующий HTML-тег для отображения в нём иконки данного пункта меню;

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

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

· ID. Идентификатор условия видимости пункта меню;

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

o Мои группы;

o Объекты, связанные через определённую связь, указанную в ObjectMap с возможностью указания ID данной связи в вызове;

o Мои роли;

· ComparisonOperator. Данное поле содержит оператор сравнения ComparisonUserValue и ComparisonValue.

· ComparisonValue. Данное поле содержит определённое пользователем значение, которое будет сравниваться с ComparisonUserValue. Примером такого значения может быть список ID каких-либо групп, пользователей или просто литералы.

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

· ID. Идентификатор преставления;

· MenuID. Идентификатор меню, в котором выводится данное представление;

· ObjectID. Идентификатор объекта, экземпляры которого отображаются в данном представлении;

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

· Filter. По аналогии с ранее описанными полями, содержащими условия фильтрации объектов, в данном поле также содержится строка, содержащая ссылки на объекты ItemFilter;

· ViewPermissionsFilter. По аналогии с ранее описанными полями, содержащими условия фильтрации объектов, в данном поле также содержится строка, содержащая ссылки на объекты ViewFilter;

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

ViewItem. Данный объект содержит информацию о том, какие именно значения должны выводится в столбцах представления, отображаемого в графическом интерфейсе информационной системы. Тип и вид отображения должны определяться исходя из типа отображения элемента, являющимся конечным в данном пути. Так, в случае, есть AttributePath указывает на фиксированный список, в представлении должен выводиться выбранный в нём элемент; связанный объект - его отображаемое имя (например, атрибут Name из объекта пользователя); дата должна приводиться к часовому поясу текущего пользователя. Полный список преобразований должен быть сформирован при получении полных требований к информационной системе;

· ID. Идентификатор поля представления;

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

· ViewID. Идентификатор представления, в котором содержится данный элемент;

· FormatID. Идентификатор функции форматирования данного элемента;

· Order. Порядковый номер данного элемента представления, который служит для упорядочивания элементов;

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

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

· ID. Идентификатор преобразования;

· DisplayName. Отображаемое имя преобразования, которое может быть использовано при настройке представлений;

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

ItemFilter. Данный объект содержит логику фильтрации записей для выведения в представлении, что является одним из наиболее востребованных функциональных требований к информационным системам. Работа данного механизма фильтрации не отличается от описанных ранее, за исключением того, что поле ComparisonAttributePath в данном случае является путём, который опирается на запись в представлении, при помощи которого можно получить доступ к значению, содержащегося в связанном объекте, а ComparisonValue является заранее предопределённым значением, вводящимся пользователем или же также является вызовом функции из списка доступных.

ViewFilter. Данный объект содержит логику фильтрации доступных пользователю представлений, что может служить для ограничения доступа к представлениям, содержащим записи, которые должны быть недоступны пользователю. В данном случае поле ComparisonUserValue будет содержать вызов функции, возвращающей информацию о текущем пользователе, а ComparisonValue - предопределённым значением. Таким образом, можно будет реализовать фильтрацию, при которой представление «Все заявки» будет доступно только пользователям с ролью «Администратор».

Механизмы к реализации

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

Requester.Company.Name

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

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

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

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

Модуль настройки системы должен содержать следующие функции:

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

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

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

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

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

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

Список форм к разработке

· Форма редактирования меню;

· Форма редактирования представления.

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

· Модуль управления объектами:

o Получение информации об объекте;

· Модуль НСИ:

o Получение роли пользователя;

3.6 Модуль НСИ

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

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



Структура данных

Рисунок 6, Структура данных модуля НСИ

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

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

· ID. Идентификационный номер пользователя;

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

· PhoneNumber. Контактный телефон пользователя. В случае, если данная необходимость присутствует, объект «User» может быть дополнен такими атрибутами, как MobilePhone или WorkPhone;

· Password. Пароль, по которому пользователь входит в систему. Данное моле может не заполняться в случае, если пользователь авторизуется посредством интеграции с Active Directory или другим методом, не требующим непосредственного введения пароля;

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

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

· ID. Идентификационный номер местоположения;

· Address. Адрес местоположения для отображения пользователям системы;

· Latitude. Широта, совпадающая с данным местоположением. Может использоваться для более точного указания местоположения, а также для отображения на карте без использования API сторонних сервисов;

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

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

· ID. Идентификатор структурного подразделения;

· Name. Название структурного подразделения;

· ParentSubdivisionID. Идентификатор родительского структурного подразделения. Данный параметр служит для сохранения взаимосвязи между структурными подразделениями.

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

· ID. Идентификационный номер компании;

· Name. Название компании;

· LocationID. Идентификатор местоположения, на котором располагается офис данной компания.

· ContactUserID. Идентификатор пользователя, который является контактным лицом в данной компании;

· HeadSubdivisionID. Идентификатор головного структурного подразделения.

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

· ID. Идентификатор рабочей группы;

· Name. Название рабочей группы;

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

· Type. Тип группы. Как следует из описания ролевой модели, всего в системе присутствует 5 статических ролей, определяемых типов группы, в которую входит пользователь:

o Пользователи;

o Операторы;

o Исполнители;

o Администраторы.

· CompanyID. Идентификатор компании, к которой относится данная рабочая группа.

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

· ID. Идентификатор производителя;

· Name. Название производителя.

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

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

· ID. Идентификатор категории оборудования;

· Name. Название категории оборудования;

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

Model. Данный объект и соответствующая ему таблица в базе данных содержит информацию о моделях оборудования, заведённых в информационной системе.

· ID. Идентификатор модели оборудования;

· VendorID. Идентификатор производителя оборудования данной модели;

· ConfigurationItemCategoryID. Идентификатор категории оборудования, к которой относится данная модель.

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

· ID. Идентификатор конфигурационной единицы;

· InventoryNumber. Инвентарный номер единицы;

· SerialNumber. Серийный номер единицы;

· LocationID. Идентификатор местоположения, на котором находится данная конфигурационная единица;

· ModelID. Идентификатор модели данной конфигурационной единицы;

· OwningCompanyID. Идентификатор компании, владеющей данной конфигурационной единицей.

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

· ID. Идентификатор графика работ;

· Name. Отображаемое название графика работ для упрощения ориентации в списках.

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

· ID. Идентификатор элемента рабочего графика;

· WorkDayStart. Время начала рабочего дня;

· WorkDayEnd. Время окончания рабочего дня;

· DayOfWeek. Номер соответствующего дня недели;

· BreakStart. Время начала перерыва;

· BreakEnd. Время окончания перерыва.

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

· ID. Идентификатор календаря;

· Name. Название календаря, использующееся для упрощения ориентации в списках выбор календаря;

· Year. Год, к которому относится данный календарь.

CalendarItem. Так же, как и график работ, объект календаря разбит на составные части, показывающие изменения в рабочих графиках.

· ID. Идентификатор элемента календаря;

· Date. Дата, которую описывает данный элемент календаря;

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

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

· ID. Идентификатор услуги;

· Name. Название услуги.

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

Модуль настройки системы должен содержать следующие функции:

· Получение всех дочерних структурных подразделений данного;

· Получение всех родительских структурных подразделений данного;

· Получение сотрудников, входящих в данную группу;

· Получение сотрудников, входящих в данное структурное подразделение;

· Получение сотрудников, работающих в данной компании;

· Получение групп, где данный сотрудник является менеджером;