«UFO - toolkit» – BI -инструментарий нового поколения

Маторин С., Попов А.
Харьковский национальный университет радиоэлектроники

1. Эволюция CASE -средств моделирования бизнес-систем и бизнес-процессов в разновидность BI -инструментария.

Представление о Business Intelligence отечественных специалистов, например [1], позволяет рассматривать программный CASE -инструментарий моделирования бизнес-систем и бизнес-процессов как разновидность BI -инструментария при условии, если он:

1. обеспечивает «процесс превращения данных в информацию и знания о бизнесе для поддержки принятия улучшенных и неформальных решений»;
2. встраивается в «информационные технологии (методы и средства) сбора данных, консолидации информации и обеспечения доступа бизнес-пользователей к знаниям»;
3. позволяет представлять и систематизировать «знания о бизнесе, добытые в результате углубленного анализа детальных данных и консолидированной информации».

При этом в работах [2, 3] отмечается необходимость разработки «CASE - инструментария, ориентированного на рассматриваемую предметную область», а также то, что такой инструментарий должен обеспечивать:

1. регистрацию информации по бизнес-процессам;
2. продуцирование высокоуровневых представлений бизнес-процессов;
3. сопровождение репозитария;
4. контроль синтаксиса описания бизнес-процессов;
5. контроль его полноты и состоятельности;
6. анализ и верификацию описаний процессов и формирование соответствующих отчетов;
7. продуцирование спецификаций бизнес-процессов.

Хорошо видно, что реализация при разработке CASE -инструментария требований 1) – 7) приводит к удовлетворению условий b ) и c ) его соответствия Business Intelligence .

Кроме того, в статье [4] отмечается, что наименьший вред организации принесет инструментарий моделирования, «лишающий разработчика той части «творческих» возможностей, которые ведут к разнообразию представления организационных моделей». При этом степень соответствия этому требованию инструментария, использующего нотацию SADT ( IDEF 0), оценивается как крайне низкая. Последнее требование непосредственным образом связано с тем, что инструментарий моделирования должен быть средством поддержки принятия решений, а не художественного творчества. Таким образом, реализация этого требования при разработке CASE -инструментария приводит к выполнению условия a ) его соответствия Business Intelligence .

Следовательно, можно утверждать, что в настоящее время происходит эволюция части CASE -средств, предназначенных для анализа и моделирования. И в результате этой эволюции CASE -инструментарий моделирования бизнес-систем становится средством для Business Intelligence , т.е. BI -инструментарием.

Рассмотрим инструментарий моделирования бизнеса, олицетворяющий этот эволюционный процесс на практике.

2. Методология, положенная в основу нового инструментария моделирования.

Фактические возможности инструментария визуального графо-аналитического моделирования бизнеса ограничиваются потенциальными возможностями метода моделирования, положенного в основу данного инструментария. Поэтому претензии к существующим инструментам и рекомендации по их усовершенствованию вполне обоснованы. Дело в том, что методы, положенные в их основу (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) любая бизнес-система (если она находится в структуре и функционирует) обязательно существует как материальное явление (персонал, здания, оборудование, документы и т.д. и т.п.).

Рис.1. УФО-элемент с узлом (У) – перекрестком потоков o, g, f; функцией (F) – процессом преобразования потоков g, f в поток o; объектом (О) – материальным образованием, физически выполняющим данный процесс.

Узловая характеристика бизнес-системы это качественная характеристика входных и выходных потоков/связей. Она характеризует бизнес целостно как структурный элемент (подсистему) системы более высокого яруса (вышестоящей организации, рынка в целом и т.д.). При этом вышестоящей организации или рынку конкретная бизнес-система представляется перекрестком, т.е. узлом связей, по которым что-либо поступает к ней («втекает») от других и что-либо поступает от нее («вытекает») к другим. Если связи отсутствуют, то данную систему вообще нет смысла рассматривать. Таким образом, любая бизнес-система обязательно является и потребителем каких-то видов ресурсов (материальных и информационных) других систем и поставщиком каких-то видов ресурсов для других систем. Каждая бизнес-система характеризуется определенными видами связей с другими системами, категориальная классификация которых в зависимости от видов «протекающих» по ним ресурсов представлена на рис.2.

Функциональная характеристика бизнес-системы это абстрактная характеристика ее потенциальных способностей. Она характеризует бизнес целостно как функциональный элемент, способный обеспечить баланс «притока» и «оттока» по связям узла путем преобразования входных ресурсов в выходные. При этом баланс одного и того же узла может быть обеспечен, в принципе, разными наборами функциональных способностей (наборами процессов), т.е. разными функциональными зависимостями выхода от входа.

Рис. 2. Базовая классификация связей

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

Например, АООЗТ (акционерное общество очень закрытого типа) «Рога и копыта» может быть представлено как УФО-элемент следующим образом.

В целом, как узел, АООЗТ является перекрестком связей/потоков представленных на рис.3 (в наименованиях связей через буквенно-цифровые обозначения показано, как эти связи вписываются в базовую классификацию связей на рис.2).

Рис. 3. АООЗТ "Рога и копыта" как перекресток входных и выходных связей, т.е. Узел

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

АООЗТ «Рога и копыта» в целом, как функция, в самом общем виде может быть представлена в виде процесса, изображенного на рис.4.

Рис. 4. АООЗТ «Рога и копыта» как процесс преобразования входа в выход, т.е. Функция.

Естественно, это представление может и должно быть дополнено описанием этой деятельности как процесса такой степени подробности и формальности, которые соответствуют имеющейся информации и целям анализа.

Как объект АООЗТ «Рога и копыта» в целом может иметь, например, следующие общие характеристики, которые также могут изменяться и дополняться (рис. 5):

Рис. 5. АООЗТ «Рога и копыта» как объект, осуществляющий торгово-закупочную деятельность.

Декомпозиция АООЗТ «Рога и копыта» на УФО-элементы нижнего уровня может быть осуществлена следующим образом.

С точки зрения узлов она может быть представлена, например, как показано на (рис. 6). Естественно, на данном уровне декомпозиции появляются новые связи, не использовавшиеся на уровне общего представления АООЗТ, но также включающиеся теперь в классификацию. В данном случае это: С3.1 – Заявки производственников на расходные материалы и канцтовары ; С3.2 – Заявки управленцев на расходные материалы, канцтовары и коммунальные услуги ; С4 – Контроль со стороны управления за основной и вспомогательной деятельностью ; D 2 .1 – Отчетность производственного отделения ; S 4 – Ремонтно-технический персонал для обслуживания . Кроме того, поток Е представляет собой объединение потоков Е1 и Е2 (т.е. родовой по отношению к ним поток), а поток S 2 – объединение потоков S 2.1 – S 2.3 (так же родовой поток).

Рис. 6. Декомпозиция узла, занимаемого АООЗТ «Рога и копыта».

При этом функция в узле УКП, соответствующая основной деятельности АООЗТ, может быть описана, например, как «деятельность по приобретению, транспортировке, хранению и сбыту товара». Объектом, который осуществляет эту деятельность фактически, может быть, например, производственное отделение (подразделения и должностные лица, занятые куплей, транспортировкой, хранением и сбытом товара).

Функция в узле УО, соответствующая вспомогательной деятельности АООЗТ, может быть описана, например как «работа по материально-техническому обеспечению основной и административно-управленческой деятельности АООЗТ». Объектом, который осуществляет эту деятельность фактически, может быть, например, вспомогательное отделение (подразделения и должностные лица, занятые вспомогательной, обеспечивающей деятельностью).

Функция в узле АУУ, соответствующая управленческой деятельности АОЗТ, может быть описана, например как «работа по координации и организации деятельности торгово-закупочного предприятия». Объектом, который осуществляет эту деятельность фактически, может быть, например, управление (подразделения и должностные лица, занимающиеся организацией, планированием, контролем, учетом, отчетностью, а также кадровыми вопросами).

Дальнейшая декомпозиция на УФО-элементы более глубоких ярусов (на узлы функциональные и функциональные объекты) осуществляется до тех пор, пока не будут выявлены узлы, функции в которых имеют четкое (по возможности формализованное) описание, позволяющее сформировать либо положения о конкретных подразделениях, либо инструкции конкретным должностным лицам. При этом должна быть гарантирована возможность существования объектов (людей, подразделений или технических средств), способных выполнить упомянутые функции.

Практически могут заранее разрабатываться, сохраняться в библиотеке (репозитарии) и затем использоваться отдельные УФО-элементы, моделирующие различные составные части бизнес-системы. Например, для рассматриваемого АООЗТ, могут быть использованы модели в виде УФО-элементов (если они заранее разрабатывались) бухгалтерии, отдела снабжения, отдела сбыта, отдела кадров и т.д. Сборка УФО-модели бизнес-системы из готовых УФО-элементов осуществляется путем использования следующих правил комбинирования УФО-элементами (правил системной декомпозиции):

1. Правило присоединения: элементы должны присоединяться друг к другу в соответствии с качественными характеристиками присущих им связей.
2. Правило баланса: при присоединении элементов друг к другу (в соответствии с правилом №1) должен обеспечиваться баланс «притока» и «оттока» по входящим и выходящим функциональным связям.
3. Правило реализации: при присоединении элементов друг к другу (в соответствии с правилами №1 и №2) должно быть обеспечено соответствие интерфейсов и количественных объектных характеристик функциональным.

Описанный кратко метод анализа «Узел-Функция-Объект» (УФО-анализ) дает в руки аналитика формально-семантический аппарат, который резко снижает «разнообразие представления организационных моделей». С другой стороны, он позволяет создавать предметно-ориентированные модели, обеспечивая сохранение и использование знаний об элементах бизнеса, которые могут отобразить любой бизнес с необходимой степенью адекватности, точности и подробности.

В рамках данного подхода может использоваться классификация бизнес-систем в зависимости от типов входных и выходных связей. Рассматриваются следующие типы связей:

входные связи :

• производственные,
• обеспечивающие (вещественные, энергетические и информационные),
• управляющие;

выходные связи:

• продуктовые,
• информационные,
• отходы.

Это позволяет рассматривать следующие классы бизнес-систем: производственные , транспортные и распределительные , для каждого из которых рассматривать по три подкласса: «вещества», «энергии» и «информации».

При этом обеспечивается учет в одной модели и структурных, и функциональных, и объектных (субстанциальных) характеристик бизнеса (любой системы вообще). Кроме того, представленный метод впервые в практике системного анализа и объектно-ориентированного проектирования информационных систем решает проблему согласования их процедур и результатов.

Таким образом, можно утверждать, что метод УФО-анализа является знаниеориентированным, а также системным и объектным одновременно.

3. Функциональные возможности нового инструментария.

В целях автоматизации применения метода УФО-анализа спроектирован и реализован CASE/ BI -инструмент анализа и моделирования «UFO-toolkit» (АС №7941) [11, 12]. Хотя название данного инструмента легко ассоциируется с аббревиатурой УФО (как и было задумано), в данном случае « UFO » – есть сокращение словосочетания «User Familiar Object» из английского компьютерного словаря, означающего «знакомый пользователю объект» (что также полностью соответствует сути дела).

Первой задачей, решаемой с помощью данного инструмента, в соответствии с методологией УФО-анализа, является построение классификации внешних (функциональных) и внутренних (поддерживающих) связей моделируемой системы путем специализации (итеративной) базовой иерархии связей. На основе данной классификации UFO-toolkit обеспечивает представление любой бизнес-системы (подсистемы и т. д.) в виде УФО-элемента, т.е. трехэлементной конструкции «Узел – Функция – Объект».

Суть алгоритма УФО-анализа, т.е. функционирования UFO-toolkit, может быть представлена следующими основными шагами:

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

При этом первый шаг может быть отождествлен с этапом собственно анализа системы, второй – с этапом ее проектирования (моделирования), а третий – с ее реализацией.

УФО-элементы, собранные в различные конфигурации, образуют диаграммы взаимодействия, которые позволяют визуализировать функциональность УФО-элемента более высокого уровня. Таким образом, моделируемая система представляется в виде иерархии УФО-элементов, начиная с контекстной модели. Данное представление позволяет учесть различные аспекты (структурные, функциональные, объектные) этой системы в одной модели.

Однажды разработанные УФО-элементы могут храниться в специальных библиотеках для обеспечения компонентного подхода к моделированию бизнеса. Это позволяет в значительной степени автоматизировать аналитическую деятельность за счет формирования и использования библиотек (репозитариев) УФО-элементов, а также за счет использования формальных правил сборки (системной декомпозиции) конфигураций из этих элементов (построения диаграмм).

На концептуальном уровне библиотеки представляют собой концептуальные модели соответствующих отраслей или частей бизнеса, в которых хранятся их структурные, функциональные и субстанциальные (объектные) характеристики. При этом библиотеки могут содержать не только одиночные УФО-элементы, но и их иерархии, что позволяет повторно использовать готовые подсистемы и системы. Таким образом, библиотеки представляют собой базу знаний специальной конфигурации, в которой хранятся УФО-элементы, соответствующие определенным классам бизнес-систем.

На логическом уровне библиотеки представляют собой фасетные классификации УФО-элементов, основанные на классификации связей. UFO-toolkit строит эти фасетные классификации автоматически, используя заданные диаграммы взаимодействия. Автоматическое построение библиотек на основе модели системы в значительной степени упрощает повторное использование УФО-элементов.

Использование библиотек позволяет накапливать, систематизировать и передавать знания о конкретных предметных областях. Решение конкретной задачи с использованием готовой библиотеки представляет собой достаточно простой и формализованный процесс, что позволяет рассматривать библиотеки УФО-элементов как самостоятельные, имеющие потребительскую стоимость продукты.

Для наглядности диаграмма декомпозиции контекстной модели нового программного инструментария моделирования UFO - toolkit на функциональные узлы, соответствующие его функциональным модулям выполнена с помощью самого этого инструмента (рис. 7).

Рис. 7. УФО-диаграмма взаимодействия действующих функциональных модулей UFO - toolkit .

Краткий обзор функциональных возможностей UFO - toolkit показывает, что он предназначен для построения системно-объектных моделей организационных систем и характеризуется следующими основными принципиальными особенностями:

  - Значительное снижение трудоемкости проектирования, за счет увеличения степени автоматизации аналитической деятельности.
  - Повышение объективности анализа и адекватности моделирования.
  - Использование при анализе и моделировании компонентной технологии, автоматизирующей процесс создания моделей, путем использования готовых (алфавитных) функциональных объектов, представленных в базе знаний в виде УФО-элементов.
  - Обеспечение интеллектуального взаимодействия с пользователем, в частности, путем «узнавания» готовых компонент (УФО-элементов).

UFO - toolkit может быть применен в следующих случаях:

  - Построение моделей существующего и планируемого бизнеса (со структурной, функциональной/процессной и объектной точек зрения) при проведении реинжиниринга бизнес-процессов.
  - Моделирование бизнеса (организаций и предприятий) при выполнении консалтинговых проектов.
  - Разработка распределенных информационных систем с применением средства бизнес-объектов CORBA (BOF).
  - Разработка технических систем с применением CALS-технологии и системы стандартов STEP.

Общее представление об интерфейсе UFO - toolkit отображено на экранной форме (рис. 8), показывающей вариант декомпозиции узла купли и продажи товара (УКП) АООЗТ «Рога и копыта».

Рис. 8. Пример экранной формы UFO - toolkit .

4. Преимущества UFO-toolkit в сравнении с BPwin .

Как знаниеориентированный, системно-объектный CASE / BI -инструмент нового поколения, UFO - toolkit обладает рядом преимуществ в сравнении, например с BPwin , поскольку позволяет накапливать, систематизировать и использовать в дальнейшем знания о предметных областях, а также полноценно использовать результаты системного анализа бизнеса в ходе объектно-ориентированного проектирования информационной системы.

Сравнение BPwin и UFO - toolkit (с использованием данных о SADT и DFD нотациях из работ [13, 14]) представлено в таблице.

UFO-toolkit	BPwin
Использование формализованных средств (правил) для построения и модификации визуальных графоаналитических моделей, что существенно сокращает разнообразие представления организационных систем (бизнес-систем).	Отсутствие правил и методических рекомендаций по построению моделей организационных систем (бизнес-систем), которые бы сокращали разнообразие получаемых результатов.
Возможность поддержки содержательной классификации связей, что позволяет сориентировать инструмент на любую конкретную предметную область. Модели являются формально-семантическими.	Не имеется средств ориентирования на конкретную предметную область. Модели имеют совершенно формальный характер.
Поддержка компонентной технологии моделирования и проектирования вследствие наличия репозитария/библиотеки, что обеспечивает возможность учета, систематизации и передачи знаний о предметной области.	Отсутствует возможность применение компонентной технологии моделирования, а также возможность учета, систематизации и передачи знаний о предметной области.
УФО-анализ и инструмент UFO - toolkit согласуются с требованиями объектно-ориентированной технологии проектирования информационных систем и позволяют упростить начальные технологические процессы разработки объектных приложений.	Результаты, полученные при моделировании бизнес-процессов в BPwin малопригодны для использования при создании объектно-ориентированного программного обеспечения.
Структурные, функциональные и объектные (субстанциальные) аспекты рассмотрения бизнес-системы объединены в одной системно-объектной УФО-модели.	Все системно-структурные методы, реализованные в BPwin , требуют построения двух или трех моделей одного и того же объекта: функциональной (активностной), информационной (данных), а также динамической.
УФО-анализ обеспечивает автоматизацию построения диаграмм взаимодействия УФО-элементов (декомпозиции) с использованием библиотек по заданной контекстной УФО-модели.	Не существует перспектив автоматизации декомпозиции моделей.
Динамическая модель есть результат активизации (анимации) статической модели взаимодействия объектов системы; привлечения других средств не требуется.	Для создания динамических моделей требуется использование дополнительных специальных расширений или других средств, с которыми технологии, реализованные в BPwin , плохо согласуются.

5. Направления развития.

Автоматизация построения диаграмм.

Использование библиотек (репозитариев) УФО-элементов и формальных правил сборки конфигураций из этих элементов позволяет автоматизировать процесс построения диаграмм взаимодействия (УФО-моделей). Для формального обеспечения (т.е. автоматизации) процедур УФО-анализа (системно-объектного моделирования) применен математический аппарат теории паттернов Гренандера.

На основании результатов исследований [15] в настоящее время осуществляется реализация модуля автоматического построения диаграмм взаимодействия. Данный модуль решает задачу автоматической сборки УФО-модели из библиотечных УФО-элементов в соответствии с заданным контекстом.

Имитационное моделирование.

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

Задача имитации функционирования системы на ее объектной модели приводит к необходимости моделирования различных функциональных (аналитических, логических и т.д.) зависимостей. Для решения данной задачи в рамках проекта по созданию инструмента UFO - toolkit разработан специальный язык сценариев ( scripting language ), а также компилятор и интерпретатор для него [16]. Данный язык позволяет описывать и визуализировать поведение УФО-элементов на этапе имитационного моделирования.

Преобразование УФО-моделей в UML -диаграммы.

Крупные проекты по моделированию и реинжинирингу бизнеса включают в себя также работы по созданию программного обеспечения поддержки бизнеса. В настоящее время для объектно-ориентированного проектирования широко используется язык 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. УФО-диаграмма взаимодействия действующих и разрабатываемых функциональных модулей UFO - toolkit .

Литература

1. Артемьев В. Что такое Business Intelligence ? // Открытые системы. 2003, №4 // http://www.osp.ru/os/2003/04/020.htm
2. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. М.: СИНТЕГ, 2000. 212с.
3. Калянов Г. CASE: все только начинается... // Директор ИС. 2001 , №3 // http://www. osp.ru/cio/2001/03/016.htm
4. Рубцов С. Какой CASE-инструмент нанесет наименьший вред организации? // Директор ИС. 2002, №1 // http://www.osp.ru/cio/2002/01/008.htm
5. Фаулер М., Скот К. UML в кратком изложении. Применение стандартного языка объектного моделирования / Пер. с англ. – М.: Мир, 1999. – 191с.
6. Кондаков Н.И . Логический словарь–справочник. – М.: Наука, 1975. – 720с.
7. Мельников Г.П. Системология и языковые аспекты кибернетики. М.: Сов. радио, 1978. 368с.
8. Маторин С.И. Системология и объектно-ориентированный подход (проблемы формализации и перспективы стыковки) // НТИ. Сер. 2. 2001. № 8. С.1-8
9. Бондаренко М.Ф., Маторин С.И., Соловьева Е.А. Моделирование и проектирование бизнес-систем: методы, стандарты, технологии / Пред. Э.В. Попова. Харьков: «Компания СМИТ», 2004. 272с.
10. Маторин С.И. О новом методе системологического анализа, согласованном с процедурой объектно-ориентированного проектирования. Ч.2 // Кибернетика и системный анализ. 2002. №1. С. 118-130.
11. Маторин В.С., Маторин С.И., Полунин Р.А., Попов А.С. Знаниеориентированный CASE-инструментарий автоматизации UFO-анализа // Проблемы программирования. 2002. №1-2. С. 469-476.
12. Маторин В.С., Маторин С.И., Попов А.С. CASE-инструментарий UFO-toolkit. Автоматизация построения УФО-моделей // Проблемы программирования. 2004. №2-3. С. 144-149.
13. Калянов Г.Н. Консалтинг при автоматизации предприятий. М.: СИНТЕГ, 1997. 316с.
14. Йордан Э., Аргила К. Структурные модели в объектно-ориентированном анализе и проектировании. / Пер. с англ. М.: «ЛОРИ», 1999. 264с.
15. Маторин С.И., Попов А.С., Маторин В.С. Применение теории паттернов в средствах Business Intelligence // Искусственный интеллект. 2004. №2. С. 345-349.
16. Попов А.С. О новом языке сценариев для объектного имитационного моделирования // Радиоэлектроника и информатика. 2002. № 1. С. 114–116.
17. Бондаренко М.Ф., Пирог С.С., Соловьева Е.А., Украинец А.Г. Взаимное преобразование UFO- и UML -моделей. // Проблемы программирования. 2004. №2-3. С. 150-154.