Диссертация (1152223), страница 44
Текст из файла (страница 44)
В этом случае необходимо детально анализировать сцепление и связность подпроцессов и не исполнять их одновременно. Использование функциональной стратегию декомпозиции помогает избежать потерь и избыточности.В результате декомпозиции мы не должны потерять свойства системы или породить новые, которых у исходной системы не было.
Следует говорить о бездефектности декомпозиции,понимая под этим отсутствие потерь данных, работ и событий, и безызбыточности — отсутствие появления данных, работ и событий, которых не было в исходной системе.Практическая ценность метода структуризации модели бизнес-процессаПрактическая ценность предлагаемого метода декомпозиции заключается в том, что предложен метод структуризации отличающийся тем, что работы и данные процесса предлагаетсяразделять согласованно, а не по-отдельности, а затем группировать в подпроцессы с учетомвзаимосвязи между ними по работам и данным, причём сцепление подпроцессов рассматривается как взаимная зависимость подпроцессов по данным, а связность как степень совпадениясвязывающих их потоков управления и данных. Предлагаемый метод позволяет разбить процесс на подпроцессы, которые в минимальной степени оказывают друг на друга взаимное влияние и, таким образом, заменить рассмотрение сложного явления на совокупность более простых.Сформулированы регулирующие принципы декомпозиции модели бизнес-процесса, отличающиеся тем, что разделены понятия корректности (бездефектности и безызбыточности) и169годности к умственному восприятию, что гарантирует, что полученная в результате модель будет правильно отображать реальность, не потеряет свойств, важных для целей моделирования,не добавит новых, которые могут исказить модель.Аналитик, использующий предлагаемый метод структуризации модели бизнес-процесса,получает мощный инструмент анализа, позволяющий осуществлять декомпозицию процесса наподпроцессы.
Устраняется неоднозначность декомпозиции, поскольку предложенный критерийвыделения подпроцессов на основе анализа переменных состояния, является объективным инаблюдаемым.3.4Анализ выразительной способности языков и нотаций моделирования бизнеспроцессовВ течение, по крайней мере, последних лет создатели новых информационных технологийперманентно обещают моделеориентированную разработку бизнес-приложений в терминахпредметной области деятельности предприятия, где разработчик оказывается защищён отсложностей используемой им вычислительной среды.
Появившиеся не так давно системыуправления бизнес-процессами предприятия позволяют создавать исполняемые модели бизнеспроцесса, в которых программный код генерируется непосредственно из графической моделибизнес-процесса. Тем самым, казалось бы, реализуется моделеориентированный подход к разработке бизнес приложений, поскольку визуальная модель является основным артефактом проектирования СУБП.
Однако в реальности программировать СУБП приходится, причём довольно много.Можно предположить, что необходимость программировать в среде СУБП обусловленанеадекватностью используемых моделей поставленной задаче. Выскажем гипотезу, что языки инотации, используемые для описания бизнес-процесса: диаграммы состояний (STD) [210]; потоков данных (DFD) [211]; PERT [212]; потоков работ (WFD) [62]; сети Петри [213]; нотацииEPC [214] и BPMN [135] по отдельности не способны без потерь передать все свойства окружающей реальности. Целью настоящего исследования является проверка выразительной возможности перечисленных языков и нотаций моделирования.В качестве метода исследования мы используем подход Я.
Ванда и Р. Вебера, которыепредложили оценивать языки моделирования по их способности предоставлять своим пользователям набор примитивов, которые непосредственно выражающих соответствующие абстракций предметной области [215]. Известны работы, в которых языки и нотации моделирования:UML [216], BPMN [217], Petri Nets [218], EPC [219], ebXML [220], BPEL [221] проверяются на170соответствие этой онтологии, делается вывод о степени их выразительности и полноты.
В данном исследовании нас будет интересовать только дефицит выразительной возможности, который возникает, когда отдельные концепты модели Бунге-Ванда-Вебера не имеют отображенияв примитивы нотации моделирования. Нашей целью станет проверка предположения, что ниодин из вышеперечисленных языков и нотаций не в состоянии отобразить сразу все четыреконцепта, но только часть из нихДиаграмма состояний (STD)Диаграмма состояний (state transition diagram — STD) это традиционный способ описанияповедения системы, её узлы показывают состояния, которые может принимать объект, а дугиотображают допустимые переходы между этими состояниями.
С каждым переходом сопоставлены условие и событие. Рассмотрим пример, изображённый на рисунке 3.22-А, показывающийизготовление изделия. Пусть есть заготовка, мы можем представить себе, что это начальное состояние объекта. В результате процедуры изготовления может получиться либо изделие, либобрак. Соответственно, из начального состояния возможны два перехода: первому соответствуетпродукт, а второму брак. Одновременные переходы по обоим направлениям недопустимы, чтобы выбрать один из двух переходов используется условие. Мы будем сопоставлять условие свнутренним событием онтологии Бунге-Ванда-Вебера, оно позволяет выбрать один из нескольких альтернативных вариантов продолжения. Событие на диаграмме STD определяет моментвремени, когда инициируется переход состояния, его можно соотнести с внешним событиемБунге-Ванда-Вебера.
Длительность перехода из состояния в состояние, а также время нахождения объекта в каком-либо состоянии не специфицируются. Подведём итог. Состояние на диаграмме STD соответствует состоянию объекта. Сам объект и его структуру изобразить на диаграмме нельзя. Переход на диаграмме состояний соответствует трансформации онтологии Бунге-Ванда-Вебера, но изобразить и описать на диаграмме трансформацию негде.
Событие надиаграмме STD соответствует внешнему событию онтологии, оно отмечает момент времени,когда внешнее воздействие или оператор инициируют начало исполнения работы, а условиесоответствует внутреннему событию. Таким образом, диаграмма STD не позволяет отобразитьработы процесса.Событие 1Условие 1НачальноеСостояние(Заготовка) Событие 2Условие 2A) STDСостояние1(продукт)ПродуктЗакзчикСостояние2(брак)ЗаготовкаХранилищеизделийВыполнитьзаказБракБ) DTDРисунок 3.22 - Диаграммы STD, DFDИсточник: составлено автором.Склад брака171Диаграмма потоков данныхДиаграмма потоков данных (data flow diagram — DFD) — один из основных инструментовструктурного анализа ИТ-систем.
Она изображается графом, узлы которого суть единицы выполняемой работы (функции, операции, процессы), а дуги показывают информационные илиматериальные потоки, образуемые движением объектов, пересылаемых между узлами [147].Алгоритм преобразования входов узла в его выход есть предмет мини-спецификации каждойработы процесса.
Дополнительно, диаграмма изображает внешние сущности, например, клиентили хранилище данных и информационные потоки между ними и узлами диаграммы.Работы на диаграмме DFD соответствуют переходам на диаграмме STD, а объект, пересылаемый между работами, определяет состояние системы в соответствующий момент времени. Рассмотрим пример изображённый на рисунке 3.22-А и Б, показывающий исполнениезаказа.
Заказчик передаёт заготовку. В результате исполнения заказа может быть получен продукт, который возвращается заказчику, либо возникает брак, который передаётся на склад. Диаграмма потоков показывает только работы, которые преобразуют входной поток, а те, которыеего не изменяют, изображать не принято. При этом, изображаются только данные, непосредственно участвующие в преобразовании, а та информация, которая не используются, на схемене показывается.
Потоки должны быть именованы, причём это название характеризует объектданных и его состояние после выполнения соответствующей трансформации. Если междусмежными операциями пересылается несколько информационных объектов, то они объединяются в единый поток, изображать параллельные потоки между соседними работами не допускается. На вход узла поступает ровно столько данных, что бы сгенерировал выходной поток,последний без изменений передаётся на вход следующего узла.
Таким образом, информационный поток переносит результат исполнения текущей операции на вход следующей. Движениепотока означает физическое перемещения, только в том случае, если объект материальный. Если же объект является информационным, то поток образуется в результате трансформации этого объекта. Состояние объекта, полученное в результате обработки можно отобразить в формеподписи, уточняющей название объекта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
