29 июля 2024

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

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

Введение

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

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

Основной целью автоматизации любого процесса является эффективность использования информационных инструментов, а также скорость решения задачи и обеспечение простоты и удобства работы пользователя. Это в полной мере относится и к задаче «Разработки программного продукта Standconvertor для стандартизации документов в электронном виде» [10-16].

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

Разработка UML-диаграмм для проектируемой системы

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

Обобщенный процесс работы программного продукта Standconvertor для стандартизации документов в электронном виде представлен на рис. 1.


Рис. 1. Диаграмма Use case верхнего уровня для программного продукта Standconvertor

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

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

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

  • согласно уже заданным параметрам и ГОСТам;
  • по параметрам, заданным пользователем.

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

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


Рис. 2. Модель расширенной диаграммы прецедентов

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

Основной успешный сценарий:

  1. пользователь входит в систему и попадает на главную страницу, где он может ознакомиться с функциональными особенностями работы системы и перейти непосредственно к обработке исходного документа;
  2. выбрав в боковом меню раздел «Редактирование», пользователь перемещается на страницу, содержащую поле для загрузки документа и необходимую инструкцию по загрузке документа;
  3. выбрав нужный документ, пользователь нажимает кнопку «Загрузить»;
  4. после загрузки система начинает проверку формата документа, отправленного пользователем;
  5. если формат совпадает с форматом, указанным в списке редактируемых документов, то система сообщает пользователю, что загрузка была завершена успешно и переключается на экран выбора параметров редактирования;
  6. пользователь выбирает необходимые параметры редактирования:
    ‒ если его интересует уже готовый набор параметров, то он щелкает на уже введенном ГОСТе;
    ‒ если пользователь хочет отредактировать только некоторые параметры, то он выбирает необходимые значения из указанного списка;
  7. после этого пользователь нажимает кнопку «Редактировать» и попадает на страницу подтверждения выбора, где ему предлагается подтвердить правильность перечня выбранных параметров;
  8. после подтверждения система приступает к обработке файла согласно заданным настройкам;
  9. когда файл полностью обработан, система оповещает пользователя о том, что обработка была совершена успешно и предлагает пользователю скачать готовый файл;
  10. пользователь нажимает на кнопку «Загрузить», после чего ему предлагается выбрать путь для сохранения нового файла;
  11. когда файл загружен по указанному пользователем пути, система выдает сообщение о том, что обработка прошла успешно и предлагает пользователю продолжить работу с новым файлом, либо завершить работу;
  12. процесс стандартизации электронного документа закончен.

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

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

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

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

Чтобы исключить появление ошибок и перегрузки диаграммы классов лишними компонентами, необходимо провести предварительное натурное проектирование на бумаге. Модель предметной области является одной из основополагающих при объектно-ориентированном подходе [12], т.к. именно на ней отображаются концептуальные классы, необходимые для построения системы. Основные цели, которые достигаются с помощью данной модели, - это описание бизнес-процессов для предметной области, бизнес-правил и действующих лиц. При рассмотрении предметной области можно выделить следующие классы, необходимые для функционирования системы (рис. 3): «Редактор» - абстрактный класс, который объединяет под собой остальные классы редактирования частей документа: «Текст», «Картинка», «Поле», «Таблица» и «Список».


Рис. 3. Диаграмма классов

В свою очередь при редактировании текста мы затрагиваем такие составляющие как «Цвет» и «Шрифт». Для комплексного редактирования нескольких параметров будут созданы интерфейсы «Параграф» и «Литература».

Описание атрибутов представленных классов предметной области отражено в таблице 1.

Название класса Описание
Edit «Редактор» – абстрактный класс, объединяющий все параметры редактирования
Text «Текст», который в свою очередь является родительским для классов «Цвет» и «Шрифт» и включает в себя обобщённый метод редактирования текста
Color «Цвет» содержит данные о названии цвета текста и его характеристиках в цветовой системе RGB
Font «Шрифт», содержащий данные о семействе используемого в тексте шрифта, его размере и типе (курсивный, жирный, подчеркнутый)
Image Класс, отвечающий за редактирование картинок с информацией о размере изображения, выравнивании и сопровождаемой подписи
List Класс, созданный для обработки списков
Field Информация об абзацных отступах в документе (отступ сверху, справа, слева, сверху с возможностью их редактирования, а также информация о выравнивании)
Table «Таблица» – отвечает за редактирование табличных данных
Paragraph Интерфейсный класс, позволяющий провести комплексное редактирование содержания абзаца, включающего в себя текст, картинки и абзацные отступы
Literature Интерфейсный класс, созданный для обработки списка литературы

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

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

Диаграмма взаимодействия для процесса стандартизации электронного документа представлена на рис. 4.


Рис. 4. Диаграмма процесса «Стандартизация электронного документа»

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

Фрагмент программного кода приложения Standсonvertor для стандартизации документов в электронном виде представлен ниже:

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:local="clr-namespace:Standсonvertor"
mc:Ignorable="d"
Title="hello_window" Height="450" Width="800" AllowsTransparency="True" WindowStyle="None" Icon="media/icon.png">





Вывод

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

Список использованных источников

  1. Гуда А.Н. Реализация надежного программного обеспечения задач технической диагностики информационно-управляющих систем / А.Н. Гуда, Т.С. Калинин, А.В. Чернов // Известия высших учебных едений. Северо-Кавказский регион. Технические науки. №4 (162). 2011. C. 26-31.Бутакова М.А. Теоретические аспекты визуальной разработки имитационных моделей проблемно-ориентированных информационных систем / М.А. Бутакова, А.Н. Гуда, А.В. Чернов // Программные продукты, системы и оритмы. №4, 2014. URL: http://swsys-web.ru/theoretical-aspects-of-visual-development-of-simulation-model.html
  2. Бурякова Н.А. Классификация частично формализованных и формальных моделей и методов верификации программного обеспечения / Н.А. Бурякова, А.В. Чернов // Инженерный вестник Дона. № 4 (14), 2010. С. -134.
  3. Городнова А.А. Документоведение: Краткий конспект лекций // Н. Новгород: НГЛУ им. Н.А. Добролюбова, 005. – 124 с.
  4. санова М. В. Современное делопроизводство: учебное пособие // М.: ИНФРА-М; Новосибирск: Сибирское, 2000.–288 с.
  5. нецова Т.В. Делопроизводство (документационное обеспечение управления). 2-е изд., испр. – М.:Бизнес-школа «Интел-Синтез», 2002. – 328 с.
  6. ова М. И. Advance of the website by means of seo optimization // Science. Research. Practice. Proceedings2018 II nd All Russia Academic and Research Conference of Graduate and Postgraduate Students: ды международной научно-практической конференции аспирантов и магистрантов. 2019. С. 31–34
  7. Жданов С.А. Информационные системы : учебник / С.А. Жданов, М.Л. Соболева, А.С. Алфимова // М.: Прометей, 2015. – 302 с.
  8. Г. Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди,Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. // М.: «И.Д. Вильямс», 2010. – 720 с.
  9. Бахтизин В.В. Методология функционального проектирования IDEF0: Учеб. пособие по курсу «Технология разработки программного обеспечения» для студ. спец. 40.01.01 «Программное обеспечение информационных нологий дневной формы обучения» / В.В. Бахтизин, Л.А. Глухова // М.: БГУИР, 2003. – 24 с.Боггс У. UML и Rational Rose 2002 / У. Боггс, М. Боггс // М.: Изд-во «ЛОРИ», 2015. – 528 с.
  10. Иванов Д. Ю. Унифицированный язык моделирования UML: Учеб. Пособие / Д. Ю. Иванов, Ф. А. Новиков // СПб.: -во Политехн. ун-та, 2011. – 229 с.ьшакова Е.И. Автоматическая обработка текстов на естественном языке и анализ данных : учеб. пособие /Е.И. Большакова, К.В. Воронцов, Н.Э. Ефремова, Э.С. Клышинский, Н.В. Лукашевич, А.С. Сапин // М.: Изд-во ВШЭ, 2017. – 269 с
  11. Мялова М.И. Анализ и систематизация программных библиотек для автоматизированной обработки электронных документов / М.И. Мялова, С.В. Чубейко // Сборник материалов Международной научно-практической ференции «Транспорт: наука, образование, производство». 2020
  12. Унгер Р. UX-дизайн. Практическое руководство по проектированию опыта взаимодействия / Р. Унгер, К. Чендлер // Пер. с англ. СПб.: Символ-Плюс, 2011. – 336 с.
  13. Леви, Д. UX-стратегия. Чего хотят пользователи и как им это дать? / Д. Леви – «Питер», 2017 – 304 с.

Возврат к списку