V Международная студенческая научная конференция Студенческий научный форум - 2013

Введение

В настоящее время во многих компаниях недостаточно регламентированы бизнес-процессы, что может привести к снижению эффективности работы компании из-за того, что разные люди понимают по-разному то, как должен выглядеть тот или иной документ, и то, в какой последовательности должны выполняться процессы. Одним из инструментов установления правил о том, как должен протекать процесс в деятельности компании, является регламентация. Очень часто многие регламентные документы (регламенты процессов, положения о подразделениях, должностные инструкции), принятые в компании, не работают. Причина этого – неэффективность системы регламентации деятельности компании. С другой стороны излишняя регламентация процессов ведёт к снижению эффективности работы компании, отставанию выполнения процессов. Хочется отметить, что если неправильно регламентировать процессы, то это может привести к потерям временных и информационных ресурсов или неправильной трактовке информации компании. Именно поэтому, необходимо создать качественную систему регламентации документооборота.

В компаниях присутствует большое количество регламентной документации. Важно создать её согласно стандартам и нормам, и обеспечивать ее актуализацию. Существует множество инструментов для облегчения разработки шаблонов, которые определяли бы и структуру документов, и требования к их содержанию и обработке. В частности, язык запросов SQL или конфигурационные XML-файлы, но у них есть недостатки, связанные с тем, что для их использования требуются специальные знания и умение запрограммировать необходимые конструкции и объекты. Процессы относятся к множеству различных предметных областей, а специалисты, работающие в них, могут «говорить на разных языках», используя свою профессиональную терминологию, поэтому средства моделирования должны удовлетворять следующим требованиям [3, 6]:

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

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

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

4. отсутствие привязки к конкретному средству моделирования бизнес-процессов, технологии реализации регламентации – «отчуждаемость» языков;

5. возможность осуществления декомпозиции функций;

6. необходимость отображения организационных элементов;

7. возможность добавления новых элементов;

8. возможность добавления новых атрибутов различных элементов языка.

Предлагается решение задачи создания DSL предназначенного для разработки упрощённых процессов описания регламентов с использованием DSM-платформы. Инструментарий моделирования должен позволять выполнять описание достаточно сложных децентрализованных процессов, но при этом быть простым и понятным для пользователей, не являющихся экспертами в процессном подходе [7]. В качестве такого инструментария будет использоваться MetaEdit+.

Целью работы является исследование возможностей MetaEdit+ для создания визуального предметно-ориентированного языка для описания процесса документооборота в соответствии с существующими регламентами.

Для достижения поставленной цели были определены следующие задачи:

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

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

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

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

Исследование регламентной документации

Первой задачей является построение метамодели языка. Результатом выполненного исследования является метамодель спроектированного DSL (см. рис. 1).

Основываясь на результатах выполненного анализа и ГОСТ Р 6.30-2003 от 01.07.2003 «Требованиях к оформлению документов» [4], можно выделить следующие основные объекты:

1.  

   1. документ;

   2. стандарт документа (по ОКУД);

   3. титульный лист;

   4. реквизит (реквизитный состав, например, управленческой документации определяется в соответствии с ОКУД для каждого типа документов);

   5. текст документа;

   6. отступ (отступы, которые задаются исходя из выбранного стандарта документа (см. рис 2));

   7. должностное лицо (представитель адресата);

   8. адресат (если требуется для рассматриваемого типа документа; адресат которому следует выслать документ, может являться как организацией, так и должностным лицом (см. рис. 3));

   9. организация (сведения об организации как о юридическом лице).

Кроме того, потребовалось создать абстрактный класс «Физическое лицо», так как документ может подписывать не только «Должностное лицо», но и «Физическое лицо». Кроме того, он необходим, так как могут быть выделены общие для данных двух классов свойства, например ФИО.

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

1. документ;

2. реквизиты;

3. стандарт, в соответствии с которым формируется документ;

4. адресат;

5. зона (далее отступы);

6. организация;

7. должностное лицо.

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

Рис. 2. Стандарт документа определяет размер отступов

Рис. 3. Разновидности адресата

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

При дальнейшем создании модели могут быть заданы конкретные примеры каждого из объектов и конструкций. Например, в качестве документа можно взять ГОСТ Р 6.30-2003 от 01.07.2003 «Требованиях к оформлению документов», в качестве основных реквизиты – название организации, печать, расшифровка подписи и остальные необходимые реквизиты, указанные в ГОСТе.

Теперь перейдем непосредственно к описанию атрибутов объектов:

1. для представления документа был создан объект «Документ», обладающий следующими свойствами:

   1. «Дата документа»: string – дата составления документа;

   2. «Место составления»: string – местоположение составления документа;

   3. «Вид»: string – разновидность документа (пример: постановление, приказ и т.п.);

   4. «Название документа»: string – наименование документа;

2. для представления содержания документа был создан объект «Текста док-а»;

3. для описания составляющих документа был создан объект «Реквизит» (например: код формы документа, подпись, код организации);

4. для предоставления краткого содержания документа (название и т.п.) был создан объект «Титульный лист»;

5. для описания разновидности использующегося бланка в документе создан объект «Стандарт документа», который обладает свойством «Формат бланка»: string – формат листа (например: А4, А5);

6. для задания зон документа используется объект «Отступ», описывающий расстояние от текста документа до границ страницы и обладающий свойствами:

   1. «Левый»: number – левый отступ;

   2. «Правый»: number – правый отступ;

   3. «Нижний»: number – нижний отступ;

   4. «Верхний»: number – верхний отступ;

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

   1. «Должность»: string – место, занимаемое человеком в организации;

   2. «Оклад»: number – доход, получаемый должностным лицом;

   3. «Расшифровка подписи»: string – фамилия, имя, отчество полностью;

   4. «ФИО»: string – данное свойство наследуется от абстрактного класса «Физическое лицо»;

8. для описания людей используется объект «Физическое лицо» (очевидно, что как у должностного, так и у физического лица будет как минимум одно общее свойство: ФИО; чтобы не дублировать свойства в каждом объекте создаётся абстрактный объект «Физическое лицо»), который обладает свойством «ФИО»: string – фамилия, имя, отчество;

9. документ всегда предназначается для кого-то, поэтому можно выделить объект «Адресат», обладающий свойством «Адрес»: string – страна, город, улица, дом;

10. адресат может быть представлен как уже описанным ранее должностным лицом, так и организацией, для этого создаётся объект «Организация», обладающий свойством «Наименование»: string – название организации.

При создании в метамодели абстрактного объекта «Физическое лицо», полю «Occurence» присваивается значение «0». В модели причастность объекта к абстрактному классу обозначается {0} на том же уровне, что и наименование объекта (см. рис. 4).

Рис. 4. Абстрактный объект

Конкретный объект наследует свойства абстрактного класса. Конкретным объектом в данной метамодели является «Должностное лицо».

Рассмотрим описание существующих в метамодели связей.

Так как существует абстрактный класс, то будет связь «Наследование» (см. рис. 5). Данная связь предназначена для того, чтобы конкретный объект – «Должностное лицо» – обладал свойством абстрактного класса, а именно ФИО.

Рис. 5. Связь наследование

Данная связь проводится от объекта «Должностное лицо» к абстрактному объекту «Физическое лицо». Благодаря этому отношению мы сможем создавать новые объекты на основе существующих.

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

1. «Документ» и «Текст док-а». Данная связь характеризует принадлежность текста документа конкретному документу;

2. «Документ» и «Реквизит». Данная связь характеризует принадлежность реквизитов конкретному документу;

3. «Документ» и «Титульный лист». Данная связь характеризует принадлежность титульного листа документу;

4. «Документ» и «Стандарт документа». Данная связь характеризует принадлежность стандарта документа конкретному документу;

5. «Стандарт документа» и «Отступ». Данная связь в зависимости от стандарта документа определяет отступы (зоны) в документе;

6. «Документ» и «Должностное лицо». Данная связь показывает, каким должностным лицом подписывается документ;

7. «Документ» и «Адресат». Данная связь показывает, какими адресатами обладает документ;

8. «Адресат» и «Должностное лицо». Данная связь показывает, что должностное лицо может являться адресатом;

9. «Адресат» и «Организация». Данная связь показывает, что организация может являться адресатом.

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

Заключение

Результатом работы является разработанный с помощью DSL-платформы MetaEdit+ предметно-ориентированный язык, который позволяет описывать структуру документа по заданному шаблону для разработки на его основе организационно-регламентной документации на предприятии, а также позволяет сделать проще процесс сверки документа на соответствие формату, заданному в регламенте. Пример созданного шаблона с использованием разработанного предметно-ориентированного языка приведён на рис. 6.

MetaEdit+ предусматривает широкий набор инструментов моделирования, включающий в себя различные редакторы, браузеры, многопользовательскую поддержку и многое другое. Также, система автоматически вносит необходимые изменения в модели при изменении метамодели [4]. Тем не менее, в ходе работы с данным инструментарием были выявлены следующие недостатки:

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

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

3. система не дает возможность задать другую ориентацию для фигур на модели.

Данный инструментарий лёгок в использовании, так как не требуется писать программного кода, но при желании доработать уже имеющийся инструментарий, разработчик оказывается бессилен что-то дополнить или поменять. Кроме того, неудобно работать с объектами модели из-за громоздкости, возникающей при описании связей [1, 4].

Рис. 6. Созданная модель шаблона документа

Библиографический список

1. Кандакова А.А., Лядова Л.Н., Сухов А.О. Разработка предметно-ориентированного языка моделирования административных регламентов // Математикапрограммных систем: межвуз. сб. науч. статей. Пермь, 2012. С 4-12.

2. Ланин В.В., Лядова Л.Н. Использование онтологического под-хода для разработки и поддержания жизненного цикла элек-тронных административных регламентов // Математика про-граммных систем: межвуз. сб. науч. статей. Пермь, 2010. С. 92-111.

3. Ланин В.В., Лядова Л.Н. Технология поддержки ведения элек-тронных административных регламентов на основе онтологи-ческих моделей // Материалы Всерос. конф. с междунар. уча-стием «Знания – Онтологии – Теории». Новосибирск, 2011. С. 38-46.

4. Сухов А.О. Сравнение систем разработки визуальных предметно-ориентированных языков // Математика программных систем: межвуз. сб. науч. ст. / Перм. гос. нац. исслед. ун-т. – Пермь, 2012. – С. 84111.

5. Сухов А.О. Интеграция систем имитационного моделирования и предметно-ориентированных языков описания бизнес-процессов // Математика программных систем: межвуз. сб. науч. ст. / Перм. гос. ун-т. – Пермь, 2009. – С. 84111.

6. Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов [Текст]: ГОСТ Р 6.30-2003. – М.: Изд-во стандартов, 2003.

7. Mazanek S. Visual Languages. MetaEdit+ [Электронныйресурс]. URL: http://visual-languages.blogspot.com/2007/11/metaedit.html (дата обращения: 11.12.2012).

Научный руководитель: преподаватель кафедры информационных технологий в бизнесе А.О. Сухов.

 

Код для цитирования: Скопировать