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

Хлыбов В.М., Полетайкин А.Н.

Кубанский государственный университет

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

Аннотация

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

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

Keywords: automation systems, legal proceedings, complex data models, code generation

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассматриваемая информационная система должна решить следующие основные задачи:

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

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

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

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

  • модель данных;
  • схема для хранения модели в базе данных;
  • сервисы для работы объектами модели (создание, чтение, обновление, удаление);
  • прочие утилитарные компоненты.

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

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

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

Автоматическая кодогенерация – это автоматическое создание одним исполняемым кодом (программой) другого исполняемого кода. Явные признаки автоматической кодогенерации, а также реинжиниринга имеются в инструментарии части CASE-технологий и целых систем проектирования и программирования (методологий, моделей, нотаций и самих CASE-средств.

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

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

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

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

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

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

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

Литература

  1. Статья 15. Особенности закупок, осуществляемых бюджетным, автономным учреждениями, государственным, муниципальным унитарными предприятиями и иными юридическими лицами [Электронный ресурс]. – Режим доступа: https://clck.ru/GQGJx
  2. Автоматическая кодогерация и ренинженеринг программного обеспечения при создании автоматизированных и автоматических систем, Иванов Ф.Ф. – УДК 004.78:004.4’2