Building mathematical model of an information system of electronic document management

Kruchinin Sergei Vladimirovich PhD in Politics senior scientific researcher, "VELBORN" Ltd.  394066, Russia, g. Voronezh, ul. Zadon'e, 9, of. 14 siblis@yandex.ru Other publications by this author

Статья посвящена всестороннему изучению мобильных сетей транспортных средств (сокращенно МСТС) ^[5], а именно аспекту построения объектно-ориентированной модели системы хранения, обработки и обмена электронными документами и приложениями между узлами МСТС. В работе по изучению и созданию МСТС мы уже затронули множество вопросов, таких как: проектирования САПР для настройки сетей МСТС ^{[6; 2]}, разработка серверного и телекоммуникационного оборудования для узлов МСТС ^{[7; 9]}, проектирования систем контроля и мониторинга узлов и связи МСТС ^[3;8], включая создание соответствующих протоколов ^[8], программного обеспечения ^{[6; 10]}. В частности были созданы математическая модель устройств МСТС ^[12]; язык нотации NTDL (network topology description language) для описания МСТС ^[1] и графическая библиотека для отображения документов, описанных на NTDL ^[1], протоколы тестирования устройств и связи в МСТС ^[3;8]. Отмеченные решения обладают и недостатками. В частности, усовершенствованию протокола ^[8] мы посвятим отдельную статью, а ^[10] реализована на языке C++ с использованием библиотеки QT, что позволяет выполнять ее кросскомпиляцию для ОС Linux и Windows и позволило решить локальные задачи в разработке САПР МСТС ^[6] и показать успешность данного подхода ^[2]. Тем не менее, у ^[10] есть и недостаток. Хотя она и реализует NTDL, основанный на XML, это решение не совместимо с технологиями Web, кроме того сама технология Web пока не поддерживается в сетях МСТС, так как не представлены достаточные механизмы. Этому мы и посвятим настоящую статью. В частности, реализация новой библиотеки, использующей в качестве прототипа ^[10], но работающей на технологиях XML/HTML5/CSS5/SVG позволило бы отображать NTDL совместно с другими веб-документами и использовать единообразные серверные решения и отображать схемы связи МСТС в окне браузера без использования стороннего клиента, что позволит строить взаимодействие интерфейса человек-машина в рамках веб-приложения. Также, помимо реализации схем в графическом виде, актуальной является передача и текстовой и справочной информации, а также реализация терминала по контролю подсетей и узлов МСТС также в формате веб-приложения.

С одной стороны, можно было бы использовать традиционную клиент-серверную веб-архитектуру, с применением операционной системой Linux, веб-сервера apache, СУБД mysql и интерпретируемого языка программирования PHP. В тоже время, как было показано в ^[5] клиент-серверная архитектура мобильных сетей транспортных средств (МСТС) отличается от традиционной, так как сервер оказывается распределенным, в результате образуется виртуальная многоранговая архитектура (ВМА), особенность которой заключается в том, что технически каждый узел МСТС является и сервером и клиентом ^[5], реализованном на платформе телекоммуникационного модуля сопряжения ^[7], а с точки зрения протоколов верхнего уровня TCP/IP, система выглядит так, словно пользователь обращается к одному серверу стандартными для веб средствами. Таким образом, архитектура остается прозрачным для пользователя и клиентского программного обеспечения, распределенный сервер же ^[5] реализуется как программное обеспечение телекоммуникационного модуля сопряжения ^[7], помимо этого выполняющего задачи маршрутизатора абонентского ^[9], а также выступающего в роли веб-сервера для обеспечения клиентов информацией о результатах анализа сети с помощью протокола ^[8]. Подобный подход позволяет обеспечивать визуализацию результатов управления сетью. В тоже время, возникает традиционный для организации веб-ресурса (а указанная система является веб-ресурсом, так как с логической точки зрения, несмотря на ВМА архитектуру, она является клиент-серверной веб-архитектурой) вопрос: каким образом организовывать управление интерфейсом веб-приложения. Само приложение может быть написано на языке PHP с использованием технологий MySQL, jQuery, CSS5 и HTML5, но требуется либо разработать его с нуля, либо выбрать существующий фреймворк, или одну из существующих систем управления содержимым (контентом) – content management system (CMS), на базе которой будет организована иерархия документов и программных компонентов

Первый этап выбора - обработка статистической информации ^[13;16] об использования CMS. Наиболее популярными в настоящее время оказываются Drupal^[4;16], Wordpress^[20;17;16], Joomla, ^[17;16], Bitrix^[16]. Анализу и сравнению четырех вышеуказанных CMS посвящена статья ^[16]. Методика и результаты, приведенные в ^[16] воспроизводимы и повторены автором. В тоже время мы можем не согласиться с выводами авторов в плане оценки популярности CMS. Из четырех выбранных для CMS систем 3 из 4 являются бесплатными, а Bitrix - лидером среди платных систем. Это меняет оценку выбора CMS, а в случае необходимости использования поддерживаемого коммерческого решения является скорее плюсом, нежели минусом. В тоже время, в ^[16] Bitrix проигрывает в количественных показателях, но выигрывает в качественных. И, действительно, среди неудобств CMS можно обозначить неочевидность управления контентом, создания новых страниц и разделов, редактирование в административном режиме, а не в режиме просмотра страниц. Последнего недостатка лишена CMS Bitrix. Как отмечено в ^[16], Bitrix обладает удобством работы с системой для пользователей и объемностью и удобностью API для разработчиков.

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

Существующие системы управления содержимым (content management systems - сокращенно CMS) разрабатываются на основе инженерного подхода без попытки создания достаточной математической основы. В тоже время необходимо восполнить этот недостаток и построить математическую модель CMS. Рассмотрим особенность организации содержимого (контента) веб-ресурса. Контент должен иметь иерархическую структуру, в виде разделов (которые могут быть папками), документов и приложений. Разделы, документы и приложения могут быть вложены в другие разделы. Отметим, что подобная организация схожа с древовидной файловой системой. В ряде случаев использование файловой системы позволяет не хранить данные о структуре в базе данных, а извлекать всю информацию только из файлов. Подобный подход описан в ^[11], использовался автором в разработке системы электронной библиотеки. Схожий подход также используется в специфической системе управления контентом nanoCMS^[19]. В вышеприведенном анализе не рассматривали последнюю из-за того, что она не предоставляет собственных механизмов редактирования, а также из-за несоразмерности с рассмотренными выше CMS. Тем не менее, nanoCMS может быть использована в качестве фреймворка для надстройки, что также подтверждено нашим практическим опытом.

В разработке модели CMS мы воспользуемся объектно-ориентированным подходом^[22]. Объектно-ориентированный подход хорошо описывается с помощью моделей графов и теорий множеств, что показано в ^[15]. Сложностью в реализации и в тоже время базовым принципом является возможность использования разного дизайна для разделов, при этом использование дизайна раздела страницами этого раздела позволяет рассматривать дизайн раздела как класс, а порождаемый дизайн страницы - как его экземпляр объекта. Также возможно организовать перекрытие дизайна, потому как вложенный раздел может иметь (наследовать) дизайн родительского раздела (класса), а может использовать собственный. В большей степени такая концепция имеет право быть названой прототипным подходом^[22], так как каждый класс является не абстрактным наследуемым элементом, а также сущностью в рамках иерархической организации документов. Существует также подход, известный как объектно-ориентированный пользовательский интерфейс - Graphic User Interface (GUI) ^[18]

Итак, мы выделяем следующие элементы модели:

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

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

Дизайн может содержать следующие элементы :

• вложенный раздел - отображается как в виде графического элемента (меню, ссылка) так и является ссылкой для перехода и управления на новый раздел;
• вложенный документ (приложение) - отображается как в виде графического элемента (меню, ссылка) так и является ссылкой для перехода и управления в документ (приложение раздела);
• текстовый блок – содержит статью или текстовое описание;
• изображение - изображение с подписью;
• графическая схема для NTDL (альтернативная реализация на HTML5+CSS5 в противовес ^[10];
• ссылка на внешний документ (в том числе, в качестве которого выступает изображение с подписью – в этом случае должна генерироваться миниатюра);
• линк (не порождающая ссылка) - ссылка на уже порожденный документ.

Очевидно наличие двух смыслов у вложенных разделов/документов. Создавая элемент страницы, создается одновременно и новый элемент в иерархии. Для документа-изображения порождается его миниатюра. Нечто похожее присуще подходу, изложенному в ^[11]. Помимо этого подобный подход позволяет организовать ссылочную целостность, в т.ч. без хранения дополнительной метаинформации ^[14].

Графовая модель документной иерархии будет обладать простотой по сравнению с графовой моделью для объектно-ориентированного программирования. Для объектно-ориентированной программы при построении ее графовой модели в качестве узлов используются методы, а дуги - вызов методов (P-путь; procedure-path) либо вызов метода порождает вызов других методов, связанных сообщениями (ММ-путь Method/Message path) ^{[15; с. 73]}. Для отображения иерархии документов в данном случае такой подход не подойдет. В общем случае иерархия документов в большей степени схожа с бинарным деревом, которым же может быть изображена файловая система. Добавление символических ссылок превращает бинарное дерево уже в граф с циклами, но эти дуги будут вторичны.

Таким образом, мы рассмотрели требования к системе управления контента и проанализировали существующие системы управления содержимым (content management systems - сокращенно CMS). На основе анализа мы предприняли попытку по построению объектно-ориентированной модели, в том числе приводимой к графовому представлению в виде бинарного дерева и графа с циклами. Немаловажную роль в этом играет исходная постановка задачи обеспечить эргономику в создании оптимального дизайна системы человек-пользователей. Именно это обусловило использование объектно-ориентированного описания структуры документов. Полученные результаты позволят перейти к следующим задачам нашего исследования: настроить на основе полученной модели CMS, разработать документооборот в условиях МСТС, реализовать приложение в телекоммуникационном модуле сопряжения и реализовать библиотеку графического ядра для отображения NTDL на технологии HTML5/CSS5 для использования совместно с CMS.