Использование библиотек (репозитариев) УФО-элементов и формальных правил сборки конфигураций из этих элементов позволяет автоматизировать процесс построения диаграмм взаимодействия (УФО-моделей). Для формального обеспечения (т.е. автоматизации) процедур УФО-анализа (системно-объектного моделирования) применен математический аппарат теории паттернов Гренандера.
На основании результатов исследований [15] в настоящее время осуществляется реализация модуля автоматического построения диаграмм взаимодействия. Данный модуль решает задачу автоматической сборки УФО-модели из библиотечных УФО-элементов в соответствии с заданным контекстом.
В целях автоматизации применения метода УФО-анализа спроектирован и реализован CASE/ BI -инструмент анализа и моделирования «UFO-toolkit» (АС №7941) [11, 12]. Хотя название данного инструмента легко ассоциируется с аббревиатурой УФО (как и было задумано), в данном случае « UFO » – есть сокращение словосочетания «User Familiar Object» из английского компьютерного словаря, означающего «знакомый пользователю объект» (что также полностью соответствует сути дела).
Первой задачей, решаемой с помощью данного инструмента, в соответствии с методологией УФО-анализа, является построение классификации внешних (функциональных) и внутренних (поддерживающих) связей моделируемой системы путем специализации (итеративной) базовой иерархии связей. На основе данной классификации UFO-toolkit обеспечивает представление любой бизнес-системы (подсистемы и т. д.) в виде УФО-элемента, т.е. трехэлементной конструкции «Узел – Функция – Объект».
Суть алгоритма УФО-анализа, т.е. функционирования UFO-toolkit, может быть представлена следующими основными шагами:
- выявление узлов связей в структуре моделируемой системы на основании функциональных связей системы в целом (соответствующих классификации);
- выявление функциональности, поддерживающей (обеспечивающей, балансирующей) обнаруженные узлы;
- определение объектов, соответствующих выявленной функциональности, т.е. ее реализующих.
При этом первый шаг может быть отождествлен с этапом собственно анализа системы, второй – с этапом ее проектирования (моделирования), а третий – с ее реализацией.
УФО-элементы, собранные в различные конфигурации, образуют диаграммы взаимодействия, которые позволяют визуализировать функциональность УФО-элемента более высокого уровня. Таким образом, моделируемая система представляется в виде иерархии УФО-элементов, начиная с контекстной модели. Данное представление позволяет учесть различные аспекты (структурные, функциональные, объектные) этой системы в одной модели.
Однажды разработанные УФО-элементы могут храниться в специальных библиотеках для обеспечения компонентного подхода к моделированию бизнеса.
Это позволяет в значительной степени автоматизировать аналитическую деятельность за счет формирования и использования библиотек (репозитариев) УФО-элементов, а также за счет использования формальных правил сборки (системной декомпозиции) конфигураций из этих элементов (построения диаграмм).
На концептуальном уровне библиотеки представляют собой концептуальные модели соответствующих отраслей или частей бизнеса, в которых хранятся их структурные, функциональные и субстанциальные (объектные) характеристики. При этом библиотеки могут содержать не только одиночные УФО-элементы, но и их иерархии, что позволяет повторно использовать готовые подсистемы и системы. Таким образом, библиотеки представляют собой базу знаний специальной конфигурации, в которой хранятся УФО-элементы, соответствующие определенным классам бизнес-систем.
На логическом уровне библиотеки представляют собой фасетные классификации УФО-элементов, основанные на классификации связей. UFO-toolkit строит эти фасетные классификации автоматически, используя заданные диаграммы взаимодействия. Автоматическое построение библиотек на основе модели системы в значительной степени упрощает повторное использование УФО-элементов.
Использование библиотек позволяет накапливать, систематизировать и передавать знания о конкретных предметных областях. Решение конкретной задачи с использованием готовой библиотеки представляет собой достаточно простой и формализованный процесс, что позволяет рассматривать библиотеки УФО-элементов как самостоятельные, имеющие потребительскую стоимость продукты.
Для наглядности диаграмма декомпозиции контекстной модели нового программного инструментария моделирования UFO - toolkit на функциональные узлы, соответствующие его функциональным модулям выполнена с помощью самого этого инструмента (рис. 7).
Поддержка в перспективе имитационного моделирования позволит эффективно решать проблемы, возникающие при моделировании больших систем, и позволит обеспечить как точный анализ, так и визуальное представление альтернативных вариантов. Кроме того, проведение экспериментов с имитационными моделями позволит проводить не только анализ их характеристик, но и решать задачи синтеза таких систем, т.е. эффективнее решать задачи автоматизации построения моделей, используя количественные оценки альтернатив, полученные в ходе имитации.
Задача имитации функционирования системы на ее объектной модели приводит к необходимости моделирования различных функциональных (аналитических, логических и т.д.) зависимостей. Для решения данной задачи в рамках проекта по созданию инструмента UFO - toolkit разработан специальный язык сценариев ( scripting language ), а также компилятор и интерпретатор для него [16]. Данный язык позволяет описывать и визуализировать поведение УФО-элементов на этапе имитационного моделирования.
Представление о Business Intelligence отечественных специалистов, например [1], позволяет рассматривать программный CASE -инструментарий моделирования бизнес-систем и бизнес-процессов как разновидность BI -инструментария при условии, если он:
обеспечивает «процесс превращения данных в информацию и знания о бизнесе для поддержки принятия улучшенных и неформальных решений»; встраивается в «информационные технологии (методы и средства) сбора данных, консолидации информации и обеспечения доступа бизнес-пользователей к знаниям»; позволяет представлять и систематизировать «знания о бизнесе, добытые в результате углубленного анализа детальных данных и консолидированной информации».
При этом в работах [2, 3] отмечается необходимость разработки «CASE - инструментария, ориентированного на рассматриваемую предметную область», а также то, что такой инструментарий должен обеспечивать:
регистрацию информации по бизнес-процессам; продуцирование высокоуровневых представлений бизнес-процессов; сопровождение репозитария; контроль синтаксиса описания бизнес-процессов; контроль его полноты и состоятельности; анализ и верификацию описаний процессов и формирование соответствующих отчетов; продуцирование спецификаций бизнес-процессов.
Хорошо видно, что реализация при разработке CASE -инструментария требований 1) – 7) приводит к удовлетворению условий b ) и c ) его соответствия Business Intelligence .
Кроме того, в статье [4] отмечается, что наименьший вред организации принесет инструментарий моделирования, «лишающий разработчика той части «творческих» возможностей, которые ведут к разнообразию представления организационных моделей». При этом степень соответствия этому требованию инструментария, использующего нотацию SADT ( IDEF 0), оценивается как крайне низкая. Последнее требование непосредственным образом связано с тем, что инструментарий моделирования должен быть средством поддержки принятия решений, а не художественного творчества. Таким образом, реализация этого требования при разработке CASE -инструментария приводит к выполнению условия a ) его соответствия Business Intelligence .
Следовательно, можно утверждать, что в настоящее время происходит эволюция части CASE -средств, предназначенных для анализа и моделирования. И в результате этой эволюции CASE -инструментарий моделирования бизнес-систем становится средством для Business Intelligence , т.е. BI -инструментарием.
Рассмотрим инструментарий моделирования бизнеса, олицетворяющий этот эволюционный процесс на практике.
Артемьев В. Что такое Business Intelligence ? // // Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. М.: СИНТЕГ, 2000. 212с. Калянов Г. CASE: все только начинается... // Директор ИС. 2001 , №3 // Рубцов С. Какой CASE-инструмент нанесет наименьший вред организации? // Директор ИС. 2002, №1 // Фаулер М., Скот К. UML в кратком изложении. Применение стандартного языка объектного моделирования / Пер. с англ. – М.: Мир, 1999. – 191с. Кондаков Н.И . Логический словарь–справочник. – М.: Наука, 1975. – 720с. Мельников Г.П. Системология и языковые аспекты кибернетики. М.: Сов. радио, 1978. 368с. Маторин С.И. Системология и объектно-ориентированный подход (проблемы формализации и перспективы стыковки) // НТИ. Сер. 2. 2001. № 8. С.1-8 Бондаренко М.Ф., Маторин С.И., Соловьева Е.А. Моделирование и проектирование бизнес-систем: методы, стандарты, технологии / Пред. Э.В. Попова. Харьков: «Компания СМИТ», 2004. 272с. Маторин С.И. О новом методе системологического анализа, согласованном с процедурой объектно-ориентированного проектирования. Ч.2 // Кибернетика и системный анализ. 2002. №1. С. 118-130. Маторин В.С., Маторин С.И., Полунин Р.А., Попов А.С. Знаниеориентированный CASE-инструментарий автоматизации UFO-анализа // Проблемы программирования. 2002. №1-2. С. 469-476. Маторин В.С., Маторин С.И., Попов А.С. CASE-инструментарий UFO-toolkit. Автоматизация построения УФО-моделей // Проблемы программирования. 2004. №2-3. С. 144-149. Калянов Г.Н. Консалтинг при автоматизации предприятий. М.: СИНТЕГ, 1997. 316с. Йордан Э., Аргила К. Структурные модели в объектно-ориентированном анализе и проектировании. / Пер. с англ. М.: «ЛОРИ», 1999. 264с. Маторин С.И., Попов А.С., Маторин В.С. Применение теории паттернов в средствах Business Intelligence // Искусственный интеллект. 2004. №2. С. 345-349. Попов А.С. О новом языке сценариев для объектного имитационного моделирования // Радиоэлектроника и информатика. 2002. № 1. С. 114–116. Бондаренко М.Ф., Пирог С.С., Соловьева Е.А., Украинец А.Г. Взаимное преобразование UFO- и UML -моделей. // Проблемы программирования. 2004.
Фактические возможности инструментария визуального графо-аналитического моделирования бизнеса ограничиваются потенциальными возможностями метода моделирования, положенного в основу данного инструментария. Поэтому претензии к существующим инструментам и рекомендации по их усовершенствованию вполне обоснованы. Дело в том, что методы, положенные в их основу (DFD , STD , SADT / IDEF 0, IDEF 3, а также UML , а также ARIS), методами, по сути дела, не являются. Это только нотации, нормативные системы, языки (если у Вас большие претензии). На это обстоятельство уже неоднократно обращали внимание соответствующие специалисты (например, [5]). Кроме того, например, в [6] объясняется, что «метод – есть система правил и приемов достижения определенных результатов, исходящая из знания закономерностей исследуемого предмета, помогающая исследователю выбрать существенное, наметить путь восхождения от известного к неизвестному». Совершенно очевидно, что системы правил, используемые в рамках перечисленных выше нотаций, абсолютно никак не исходят «из знания закономерностей исследуемого предмета» и никак не помогают «выбрать существенное». А вот перспективный CASE -инструментарий, эволюционирующий в BI -инструментарий, в соответствии с требованиями [2 - 4] должен это делать. Следовательно, такой инструментарий должен основываться на реальном методе моделирования бизнес-систем и бизнес-процессов.
В связи с тем, что любая бизнес-система представляет собой социальную, хозяйственную (следовательно открытую, сложную) систему целесообразно для ее анализа и моделирования использовать системный подход. Но, так как системный подход существует не в единственном варианте, необходимо сделать правильный выбор среди множества этих подходов.
Грубо говоря, существует два вида системного подхода. «Традиционный» системный подход рассматривает систему как разновидность множества. Этот подход получил широкое распространение для исследования и проектирования технических и технологических устройств и процессов в рамках так называемой системотехники.
Этот подход в данном случае совершенно бесполезен по следующим причинам. Он не способен использовать категорию «цель» для объектов произвольной природы; в качестве первичной категории рассматривает «часть» («структуру» и «состав»), а не «целое» и его функцию; не учитывает иерархическую структуру внешней среды; не использует понятия адаптации системы к требованиям системы более высокого яруса. «Ноосферный» системный подход (или системология) рассматривает систему не как множество, а как функциональный объект, функция которого обусловлена функцией объекта более высокого яруса (надсистемы) [7]. Данный подход специально предназначен для исследования целенаправленного взаимодействия систем любой природы, связи между которыми рассматриваются как потоки элементов глубинных ярусов связанных систем. Это обеспечивается путем учета функционального характера целостности системы, иерархической природы внешней среды и процесса адаптации системы к запросу надсистемы. Концептуальный аппарат системологии позволяет единообразно описывать понятия теории организации, логистики, инжиниринга бизнеса, а также объектно-ориентированной методологии создания информационных систем [8 - 10].
Применение системологии к анализу и моделированию бизнеса позволяет создать эффективный метод моделирования бизнес-систем, удовлетворяющий требованиям [2 - 4, 6].
Системологический подход, в первую очередь, позволяет представить бизнес-систему как функциональный объект, связанный входными и выходными потоками с другими объектами (системами). Детализация этого положения приводит к рассмотрению бизнес-системы с трех сторон. С одной стороны, как перекрестка входных и выходных связей/потоков, т.е. как Узла. С другой стороны, как процесса (процедуры) преобразования элементов , втекающих по входным потокам, в элементы, вытекающие по выходным потокам, т.е. как Функции . С третьей стороны, как материального явления, реализующего (выполняющего) функцию преобразования входа в выход, т.е. как Объекта.
Интеграция этих трех аспектов позволяет представить любую бизнес-систему как элемент Узел–Функция–Объект (УФО-элемент, рис.1), формализующий три очевидных факта:
1) любая бизнес-система обязательно находится в структуре ( является узлом) системы более высокого яруса (надсистемы),
2) любая бизнес-система обязательно как-либо функционирует (преобразует вход в выход),
3) любая бизнес-система (если она находится в структуре и функционирует) обязательно существует как материальное явление (персонал, здания, оборудование, документы и т.д. и т.п.).
Как знаниеориентированный, системно-объектный CASE / BI -инструмент нового поколения, UFO - toolkit обладает рядом преимуществ в сравнении, например с BPwin , поскольку позволяет накапливать, систематизировать и использовать в дальнейшем знания о предметных областях, а также полноценно использовать результаты системного анализа бизнеса в ходе объектно-ориентированного проектирования информационной системы.
Сравнение BPwin и UFO - toolkit (с использованием данных о SADT и DFD нотациях из работ [13, 14]) представлено в таблице.
UFO-toolkit | BPwin |
Использование формализованных средств (правил) для построения и модификации визуальных графоаналитических моделей, что существенно сокращает разнообразие представления организационных систем (бизнес-систем). | Отсутствие правил и методических рекомендаций по построению моделей организационных систем (бизнес-систем), которые бы сокращали разнообразие получаемых результатов. |
Возможность поддержки содержательной классификации связей, что позволяет сориентировать инструмент на любую конкретную предметную область. Модели являются формально-семантическими. | Не имеется средств ориентирования на конкретную предметную область. Модели имеют совершенно формальный характер. |
Поддержка компонентной технологии моделирования и проектирования вследствие наличия репозитария/библиотеки, что обеспечивает возможность учета, систематизации и передачи знаний о предметной области. | Отсутствует возможность применение компонентной технологии моделирования, а также возможность учета, систематизации и передачи знаний о предметной области. |
УФО-анализ и инструмент UFO - toolkit согласуются с требованиями объектно-ориентированной технологии проектирования информационных систем и позволяют упростить начальные технологические процессы разработки объектных приложений. | Результаты, полученные при моделировании бизнес-процессов в BPwin малопригодны для использования при создании объектно-ориентированного программного обеспечения. |
Структурные, функциональные и объектные (субстанциальные) аспекты рассмотрения бизнес-системы объединены в одной системно-объектной УФО-модели. | Все системно-структурные методы, реализованные в BPwin , требуют построения двух или трех моделей одного и того же объекта: функциональной (активностной), информационной (данных), а также динамической. |
УФО-анализ обеспечивает автоматизацию построения диаграмм взаимодействия УФО-элементов (декомпозиции) с использованием библиотек по заданной контекстной УФО-модели. | Не существует перспектив автоматизации декомпозиции моделей. |
Динамическая модель есть результат активизации (анимации) статической модели взаимодействия объектов системы; привлечения других средств не требуется. | Для создания динамических моделей требуется использование дополнительных специальных расширений или других средств, с которыми технологии, реализованные в BPwin , плохо согласуются. |
Крупные проекты по моделированию и реинжинирингу бизнеса включают в себя также работы по созданию программного обеспечения поддержки бизнеса. В настоящее время для объектно-ориентированного проектирования широко используется язык UML , который претендует на роль стандарта в данной области. Среди инструментов автоматизации анализа и проектирования программного обеспечения с использованием UML наиболее широкое распространение получил продукт Rational Rose фирмы Rational Software Corporation (США). Rational Rose позволяет генерировать исходные коды на различных языках и формировать проектную документацию. В то же время УФО-подход и инструмент моделирования согласуются с требованиями объектно-ориентированной технологии проектирования информационных систем и позволяют выполнять начальные технологические процессы разработки объектных приложений. Таким образом, перспективным направлением развития является создание модуля преобразования УФО-моделей в UML диаграммы. UFO - toolkit позволяет осуществлять эффективное моделирование бизнес-поцессов, а дальнейшие этапы разработки сложных программных приложений целесообразно выполнять в Rational Rose
В настоящее время уже проведены исследования по вопросу взаимного преобразования диаграммы классов UML-модели, созданной в Rational Rose, и UFO-модели, описанной в UFO-toolkit [17]. На основе этих исследований реализована программная система, которая осуществляет прямое и обратное конвертирование диаграммы классов модели, описанной в Rational Rose, и модели в формате UFO-toolkit.
В перспективе возможности программной системы могут расширяться за счет дополнения ее модулями для преобразования других видов диаграмм UML. Кроме того, может быть обеспечена точность и эффективность преобразования, за счет использования математических методов при разработке методики преобразования.
В заключении на рисунке 9 представлена УФО-диаграмма, на которой отражены основные направления развития BI -инструментария UFO - toolkit .
Рис. 9. .
Маторин С., Попов А.
Харьковский национальный университет радиоэлектроники