Диссертация (1145120), страница 47
Текст из файла (страница 47)
При этом активно использовались многомерные проекции. Например, тернарная проекция описываетпереход от одной операции к другой через произошедшее событие. Но сюдаеще можно присоединить порождаемый при этом документ и пр. При такомопределении потока управления возникали проблемы с ветвлениями, c выходами за границу областей видимости и пр. Однако аналитики привыкли работать так и были способны очень быстро создавать объёмные спецификации— действительно, при наличии опыта такое представление оказываетсяудобнее графического. Кроме того, оно позволяло применять общий механизм разработки отчётов к процессным моделям. С другой стороны, такойспособ работы делал ОРГ-Мастер исключительно внутренней технологией —все попытки обучить внешних пользователей этим правилам разработки процессных моделей окончились безуспешно.
Кроме того, в таком виде было невозможно обсуждать процессные модели с клиентами. Также, такой подходне позволял говорить об интеграции с различными другими средствами разработки и исполнения процессных моделей. Наконец, данный способ идеологически устарел с появлением BPMN. Одним словом, было принято решениеперейти на использование BPMN для работы с процессными моделями вОРГ-Мастере, создав соответствующий внешний редактор на основе Visio иглубоко интегрировав этот редактор с продуктом ОРГ-Мастер.Остановимся на языке моделирования, который является следующей выборкой из BPMN: мы взяли процессы (processes) с атомарными операциями(tasks) и свёрнутыми процессами (с возможностью развернуть процесс на отдельной диаграмме), порты для обозначения исключающего или/и распараллеливания потока управления, дорожки (lanes), а также документы и хранилища данных и средства их связи их как друг с другом, так и с операциями ипроцессами. Предполагалось помещать процессные модели в листовые узлыдекомпозиции функций предприятия в исходной модели ОРГ-Мастера.
Та287ким образом, для таких узлов предполагалась возможность создавать BPMNмодели. Между собой они могли соотноситься только через повторно используемые сущности — процессы и операции. Соответствующая метамодель в терминах ОРГ-Мастера (то есть с помощью классификаторов и проекций) представлена на рис. 5.7. Эта диаграмма выполнена во внутреннем редакторе схем моделей ОРГ-Мастера. Такой способ задания метамодели былвыбран для того, чтобы зафиксировать внутреннее представление таких моделей в ОРГ-Мастере — именно в этих и только этих классификаторах ипроекциях должны храниться все сущности таких моделей, нарисованные вVisio. Рассмотрим подробнее эту метамодель.Все BPMN-модели, которые у нас имеются, помещаются в классификатор«Элементы потока управления и данных».
Например, если их всего три —«Модель1», «Модель2», «Модель3», — то в классификаторе появится три соответствующих позиции. Далее, в подуровнях этих позиций появятся позиции, которые будут являться наборами элементов потоков управления ивхождениями используемых документов для соответствующих моделей. Поскольку в данном классификаторе имеется два разных вида элементов, то,соответственно, у этого классификатора имеется два базовых типа, реализующих эту возможность — «Модель» и «Элементы потока управления и данных». Возможные варианты элементов потока управления и данных задаютсяв справочнике типов как подтипы типа «Элементы потока управления и данных».Связи между элементами потока управления реализуются проекцией«Поток управления и данных», связывающей рассматриваемый классификатор с самим собой.
Связи, которые могут быть созданы в рамках данной проекции, имеют два атрибута — тип и комментарий. Разрешено устанавливатьболее двух связей с одним элементом, так что все варианты ветвлений и соединений возможны в рамках данной спецификации (возможны также и лишние, несуществующие варианты — но об этом будет рассказано отдельно).288Элементы потокауправления и данныхБазовый тип: Модель,Элемент потокауправления и данныхИспользование документов- Свойство: СвойствадокументовИсполнителиэлементовуправленияИсполнителиДокументыБазовый тип: ИсполнительИсполнителиэлементовуправления(глобальные)Поток управления и данных- Тип перехода: Типы переходов- Комментарий: ТекстХранилища документовХранилищаБазовый тип: ДокументБазовый тип: ХранилищеИспользование документов(глобальных)- Свойство: СвойствадокументовЭлементы потока управленияи данных (глобальные)Использование глобальныхэлементовБазовый тип: Элемент потокауправления и данных(глобальный)Хранилища документов (глобальные)Поток управления и данных(глобальные)- Тип перехода: Типы переходов- Комментарий: ТекстРис.
5.7 Метамодель процессной моделиС задачами могут быть связаны исполнители — данная возможностьреализована с помощью классификатора «Исполнители» и проекции этогоклассификатора с классификатором «Элементы потока управления иданных». С элементами данных (вхождениями документов и пр.) могут бытьсвязаны определения этих документов, а также хранилища — имсоответствуют классификаторы «Документы» и «Хранилища».Глобальные элементы потока управления хранятся в специальномклассификаторе — «Элементы потока управления и данных (глобальные)».Там могут содержаться как отдельные задачи, так и целые процессы.Использовать эти элементы в обычных моделях можно через проекцию«Использование глобальных элементов» — то есть в конкретной моделиможно загружать элементы потока управления из этого классификатора исоединять их с другими элементами данной модели.Охарактеризуем ограничения корректности, накладываемые на эту мета289модель: очевидно, что она слишком «свободная», то есть допускает большевариантов, чем их в действительности должно быть.
Например, исполнителине могут быть связаны с вхождением документов, несмотря на то, что последние входят в классификатор «Элементы потока управления и данных» ипоэтому могут быть связаны с исполнителями связями по проекции «Исполнители элементов управления». В свою очередь, хранилища могут быть связаны только с вхождениями документов и не могут иметь связи с элементамипотока управления, но имеется проекция между классификаторами «Элементы потока управления и данных» и «Хранилища» и ограничений на связи, которые можно создавать в рамках этой проекции, нет. Точно также, возможность создавать связи типа «один-ко-многим» (1:n) в рамках проекции «Поток управления и данных» необходима только для портов, но не нужна длязадач — контроль того, когда эта возможность нужна, а когда нет, выраженсредствами метамодели. Список таких ограничений, не выраженных метамоделью с рис.
5.7, можно продолжить. На рис. 5.8 представлена каноническаяметамодель для этого же языка, выполненная с помощью диаграмм классовUML, которая гораздо точнее, однако менее полезна в данном случае, так какоставляет вопросы по её представлению в ОРГ-Мастере.290аBPMN Model0..*1Global taskName0..10..*0..*0..*0..1ProcessRoleGlobal: bool0..*0..*0..1-Name0..*ActivityName0..*0..* Document_Occurrence10..*0..*FinishStartGatewayState0..*0..*1Kind0..* 0..*0..10..1DocumentResourceStatesNameNameа) Основные сущностибSourceDestination11StartActivityFinishActivityGatewayб) Связив1Gateway2..*ConditionDestinationString0..11в) Условные ветвленияРис.
5.8.Другая версия метамодели подмножества BPMN: а — основныесущности, б — связи, в — условные ветвления2915.1.2 Программные средстваПродукт реализован как многооконное приложение (см. рис. 5.9) и содержит: меню в стиле Microsoft Fluent Interface64; основную рабочую область: окна для редактирования классификаторов,проекций, для создания отчётов, диаграммы внутреннего редактора ипр.; браузер модели, разделённый на четыре закладки (классификаторы,проекции, отчёты, диаграммы); окна для работы с различными свойствами классификатора, проекции,позиции, связи и пр.Рис. 5.9. Пользовательский интерфейс продукта ОРГ-МастерИнтерфейс продукта разработан с помощью технологии WPF65 ибиблиотеки DevExpress66. Репозиторий основан на XML и стандартных64Часто этот вид интерфейса называют Ribbon-интерфейс.
В качестве примера можнопривести интерфейс последних версий пакета Microsoft Office: большое главное меню сзакладками, в которые сгруппирован функционал пакета.65MSDN Library –Windows Presentation Foundation, https://msdn.microsoft.com.292средствахсериализациимногопользовательскуюплатформыработув.Net.режимеПродуктслиянияподдерживаетверсиймодели.Архитектура продукта представлена на рис. 5.10.МетаредакторПоддержка моделейПоддержкаклассификаторовПользовательскийинтерфейсГенератор отчётовРепозиторийПоддержка плагиновПоддержка проекцийВнешние редакторыРис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
