Материалы всероссийской научно-технической конференции Автоматизир
..pdfРис. 1. Диаграмма вариантов использования до внедрения
автоматизированной системы
Рис. 2. Диаграмма вариантов использования после внедрения автоматизированной системы
К недостаткам процесса формирования индивидуального пла на преподавателя на текущий момент времени можно отнести следующее:
1)поскольку заполнение индивидуального плана осуществляется
вбумажном виде, то достаточно сложно осуществлять какие-либо исправления в данном документе;
2)необходимо вручную производить расчет различных итоговых значений часов (например, итоговых планируемых значений часов по каждому виду работы преподавателя);
3)необходимо вручную производить проверку полученных ито говых значений часов на соответствие нормативам (например, на сколько планируемое суммарное значение часов по всем видам работ соответствует норме часов, отводимых на одну ставку).
Сцелью устранения указанных выше недостатков было принято решение о создании автоматизированной системы формирования индивидуального плана, которая позволила бы сделать процесс фор мирования этого плана более эффективным.
На рис. 2 приведена диаграмма вариантов использования языка UML, отображающая процесс формирования индивидуального плана работы преподавателя после внедрения автоматизированной системы.
Как видно на рис. 2, программа автоматически подсчитывает не обходимые итоговые значения часов и производит проверку значений часов на соответствие нормативам. Создаваемая автоматизированная система позволит хранить информацию в структурированном виде с помощью базы данных, поэтому данную информацию в дальней шем возможно будет использовать для анализа и для составления других видов отчетов.
В ближайшее время планируется реализация программного и ин формационного обеспечения данной автоматизированной системы.
Библиографический список
1.Файзрахманов Р.А., Архипов А.В. Проектирование автомати зированных информационных систем на основе объектноориентированного подхода: учеб, пособие. - Пермь: Изд-во Перм. гос. техн. ун-та, 2011. - 222 с.
2.Орлов С.А., Цилькер Б.Я. Технологии разработки программ ного обеспечения: учебник для вузов. - 4-е изд. - СПб.: Питер, 2012.-608 с.
3.Леоненков А.В. Самоучитель UML. - 2-е изд., перераб. и доп. - СПб.: БХВ-Петербург, 2006. - 432 с.
РАЗРАБОТКА АНАЛИТИЧЕСКИХ МОДЕЛЕЙ БИЗНЕСПРОЦЕССОВ: ЭТАП НОРМАЛИЗАЦИИ
Студент гр. БИ-11-1 Р.А. Нестеров
Научный руководитель - канд. физ.-мат. наук, доцент ЯН. Лядова Национальный исследовательский университет «Высшая школа экономики», Пермский филиал
В настоящее время существует множество различных нотаций, которые могут применяться для разработки графических моделей бизнес-процессов, как-то: IDEF0 - для отображения логических от ношений между операциями бизнес-процессов; DFD, предназначен ная для графического отображения потоков данных в рассматривае мом процессе и его операциях; еЕРС, ключевым звеном в которой являются события, и т.д. Однако построение аналитических или чис ленных моделей для графических моделей больших размерностей с целью их дальнейшего исследования может вызвать значительные затруднения и занять значительный объем времени. Помимо масшта ба модели другой возможной причиной затруднений перехода к ана литическому представлению графических моделей бизнес-процессов может выступать недостаток необходимых данных для анализа.
При наличии аналитического представления модели бизнеспроцесса (например, в виде системы дифференциальных уравнений) получать показатели для проведения многоаспектного исследования моделей бизнес-процессов будет проще, поскольку аналитическое представление подразумевает представление модели в строго форма лизованном виде, который можно эффективно и автоматизированным образом обработать с применением различных математических паке тов, а именно: MatLab, Maple, MathCAD и т.д. Но если имеется мас штабная модель бизнес-процессов, представленная в какой-либо нота ции, то намного усложняется собственно переход к соответствующей аналитической модели, поэтому существует проблема получения фор мализованного аналитического представления моделей бизнеспроцессов, которые будут применимы для дальнейшего исследования.
На сегодняшний день существуют частные решения задачи по лучения аналитического представления для графических моделей
бизнес-процессов, разработанных с помощью некоторых нотаций,
аименно (ниже перечислены наиболее распространенные):
1)аналитическая модель телекоммуникационной сети [1,2, 3];
2)представление бизнес-процесса в виде одноцветной сети Петри [4];
3)представление бизнес-процесса в виде раскрашенной сети Петри [5];
4)применение средств и инструментов имитационного модели рования [6].
После анализа данных методологий было установлено, что вы деляются два основных этапа при получении и разработке аналитиче ского представления для визуальной модели бизнес-процесса:
1)нормализация исходной модели бизнес-процесса;
2)собственно переход к аналитической модели бизнеспроцесса, пригодной для обработки средствами и инструментами математических программных пакетов.
На этапе нормализации, по сути, выполняется проверка исход ной модели на соответствие определенному набору требований, и при наличии несоответствий данным требованиями применяется механизм нормализации
В соответствии с данными этапами была разработана схема ор ганизации потока управления (бизнес-архитектура) механизма полу чения аналитической модели для исходной графической модели биз нес-процесса, представленная на рис. 1.
Рис. 1. Организация потока управления (Вариант №1)
Из данной архитектуры видно, что нормализация исходной мо дели выполняется напрямую на основе исходной графической мо дели, но для этого необходимо решить задачу манипуляции графи ческими элементами модели бизнес-процесса в соответствии с тре бованиями. Одним из возможных решений данной проблемы может являться нормализация не исходного графического представления, а промежуточного представления модели, т.е. задача нормализации исходной модели бизнес-процесса будет решена уже после получе ния промежуточного представления модели, в таком случае общая модель архитектуры примет следующий вид, представленный на рис. 2.
1 |
1 |
Разработать |
|
|
|
|
Импорт |
|
|
' — > |
графическою моде*, |
-v |
|
|
|
|
|||
/> |
промежуточного |
|
0 |
||||||
|
бизнес-процесса |
|
|
||||||
|
|
|
представлетыя в пакет |
О |
|||||
|
0 |
|
|
|
|
|
|||
|
Графическая |
|
|
|
|
|
- - 1 |
|
|
|
|
|
|
|
|
|
Аналпичеоса |
Результат |
|
;... модель |
|
|
|
|
|
||||
|
|
|
|
|
я модель Ы1 |
анализа БЛ |
|||
1 |
> |
Получить |
|
|
Ц |
f |
Нормалвомтъ |
|
|
промежуток»** |
• • |
|
|
| • • л |
промежуточную |
|
|
||
• • •> представление моде* |
|
| |
|
[ |
модель |
|
|
||
|
|
Промежуточное |
|
Нормализова |
|
||||
|
|
|
"О |
|
|||||
|
|
представление |
|
иная модель |
|
модели
Рис. 2. Организация потока управления (Вариант №2)
В рамках второго варианта модели общей архитектуры необхо димо решить задачу нормализации исходной модели бизнес-процесса несколько в ином ключе - обработать промежуточное представление графической модели, полученное ранее, но в то же время при таком механизме нормализации снижается участие человека в данном про цессе, тем самым снижаются возможные временные затраты, связан ные с нормализацией исходной модели.
В соответствии с данной архитектурой программная система, реализующая генерацию аналитического представления для исход ной визуальной модели бизнес-процесса, будет включать следующие компоненты:
1)компонент получения промежуточного представления моде ли в XML-формате;
2)компонент нормализации промежуточного представления
всоответствии с определенными требованиями;
3)компонент ввода дополнительных данных (показателей и ха рактеристик) модели бизнес-процесса;
4)компонент загрузки и обработки итогового промежуточного представления модели в математическом программном пакете.
Далее в данной работе будет подробнее рассмотрен компонент нормализации промежуточного XML-представления визуальной мо дели бизнес-процесса. Выше было отмечено, что нормализация явля ется проверкой на соответствие требования, а поскольку входным документом для компонента нормализации является XML, то ее можно выполнить следующими путями:
1)применение XSD-схемы [7];
2)программная проверка средствами языка программирова
ния С#.
С помощью XSD-схем выполняется проверка правильности структуры XML-представления модели, а также указание обязатель ных атрибутов и соответствие типов, а с помощью программной про верки выполняется более сложная валидация, как-то:
1)единственность стартового элемента исходной модели биз нес-процесса;
2)корректность наличия и отсутствия взаимных связей между
элементами модели.
Найденные в ходе работы алгоритма нормализации модели бизнес-процесса неточности будут выведены в журнал (лог) рабо ты компонента нормализации с помощью специальной библиотеки log4net [8], который на данный момент представляется в ТХТ-до- кументе.
В таблице представлены основные структуры данных, которые были использованы при разработке компонента нормализации моде лей бизнес-процессов, а листинг 1 содержит фрагмент примера файла журнала (лога) работы данного компонента.
Структуры данных
Наименование струк-
туры/типа данных |
Программная реализация C# |
|
|
||
Основной объект для |
ILog log = LogManager. |
|
ведения лога работы |
GetLogger(typeof(XMLValidation |
|
приложения |
)); |
|
Объектная модель |
XmlDocument doc = new |
|
XML-документа |
XmlDocumentO; |
|
Узел XML-документа |
XmlNode root = |
|
doc.DocumentElement |
||
|
||
Упорядоченная кол |
XmlNodeList labelsList = |
|
лекция узлов XML-до |
||
root.SelectNodes("//"); |
||
кумента |
||
|
||
|
XmlReaderSettings r; |
|
Настройки для чтения |
r.ValidationType = |
|
XML-документа |
ValidationType. Schema; |
|
с применением XSD |
readerSettings.Schemas.Add(null, |
|
|
schemaFile); |
Применение
Ведение журнала валидации XML-пред- ставления модели
Программная валида ция XML-пред- ставления модели
Валидация XML-пред- ставления модели по XSD-схеме
Листинг 1. Фрагмент журнала работы компонента нормализации 2015-04-19 14:50:39,634 [10] INFO
XMLValidation.XMLValidation - = Выполняется проверка связно сти процессов модели ===
2015-04-19 14:50:39,636 [10] DEBUG
XMLValidation.XMLValidation - Файл модели FinOutput.xml успешно загружен
2015-04-19 14:50:39,636 [10] DEBUG
XMLValidation.XMLValidation - Информация о процессах и соедини тельных элементах загружена
2015-04-19 14:50:39,638 [10] INFO
XMLValidation.XMLValidation - === Проверка связности процессов модели завершена =
2015-04-19 14:50:39,639 [10] INFO
XMLValidation.XMLValidation - = |
Выполняется проверка одно |
значности стартового процесса модели |
— |
2015-04-19 14:50:39,640 [10] DEBUG |
XMLValidation.XMLValidation - Файл модели FinOutput.xml успешно загружен
2015-04-19 14:50:39,640 [10] DEBUG XMLValidation.XMLValidation - Информация о процессах извлечена
2015-04-19 14:50:39,641 [10] INFO XMLValidation.XMLValidation - Подтверждена однозначность стар тового процесса модели
2015-04-19 14:50:39,641 [10] INFO XMLValidation.XMLValidation - Процесс 2650 распознан как стартовый
2015-04-19 14:50:39,641 [10] INFO XMLValidation.XMLValidation - = Проверка однозначности стар тового процесса модели завершена =
2015-04-19 14:50:39,641 [10] INFO XMLValidation.XMLValidation - = = Выполняется проверка связно сти процессов модели и хранилищ данных ==
2015-04-19 14:50:39,642 [10] DEBUG XMLValidation.XMLValidation - Файл модели FinOutput.xml успешно загружен
2015-04-19 14:50:39,643 [10] DEBUG XMLValidation.XMLValidation - Информация о хранилищах данных и коннекторах извлечена
2015-04-19 14:50:39,643 [10] INFO XMLValidation.XMLValidation - ==== Проверка связности хранилищ данных и процессов модели =
В дальнейшем данный лог-файл предполагается использовать для внесения содержательных изменений в исходную визуальную модель бизнес-процесса в случае обнаружения несоответствий. Не обходимо отметить, что текстовое представление файла журнала яв ляется не самым удобным для работы с ним, поэтому предполагается также разработать механизм получения структурированного пред ставления лог-файлов, пригодного для анализа с точки зрения нали чия несоответствий с требованиями, которые предъявляются к нор мализованной модели.
Библиографический список
1. Poryazov S. What is Offered Traffic in a Real Telecommunication Network? // Proceedings of ITC19/Performance Challenges for Efficient Next Generation Networks. - 2005. - P. 707-718.
2. Poryazov S. Towards Useful Overall Network Teletraffic Defini tions // International Journal «Information Technologies and Knowledge». - 2008.-Vol. 2. - P. 193-199.
3.Poryazov S. The overlaying free terminal states concept // Pro ceedings of a Conjoint Seminar “Modeling and Control of Information Processes”. - 2009. P. 110-116.
4.Доррер М.Г. Алгоритм преобразования моделей бизнеспроцессов в одноцветные сети Петри // Моделирование и анализ ин формационных систем. - 2010. - Т. 17, вып. 2. - С. 5-16.
5.Zhow W., Yang F., Zhu Y. A transformation method of OPM Model to CPN Model for System Concept Development // Proceedings of the First International Conference on Information Science and Electronic Technology (ISET). - 2015. - P. 98-102.
6.Ланцев E.A., Доррер М.Г. Агентное имитационное моделиро вания бизнес-процессов в нотации еЕРС // Научно-технический вест ник информационных технологий, механики и оптики. - 2103. - Т. 3, вып. 85. - С. 86-92.
7.W3C XML Schema Definition Language (XSD) 1.1 Part 1: Struc tures // W3C Recommendations [Электронный ресурс]. - URL: http://www.w3.org/TR/xmlschemal 1-1/ (дата обращения: 21.04.2015).
8.Apache log4net Manual: Introduction // Apache Logging Services [Электронный ресурс]. - URL: http://logging.apache.org/log4net/ release/manual/introduction.html (дата обращения: 23.04.2015).