2015-05-20
286
Представление о Business Intelligence отечественных специалистов, например [112], позволяет рассматривать программный CASE-инструментарий моделирования бизнес-систем и бизнес-процессов как разновидность BI-инструментария при условии, если он:
a) обеспечивает «процесс превращения данных в информацию и знания для поддержки принятия улучшенных и неформальных решений»;
b) встраивается в «информационные технологии (методы и средства) сбора данных, консолидации информации и обеспечения доступа бизнес-пользователей к знаниям»;
c) позволяет представлять и систематизировать «знания о бизнесе, добытые в результате углубленного анализа детальных данных и консолидированной информации».
При этом в работах [40, 113] отмечается необходимость разработки «CASE- инструментария, ориентированного на рассматриваемую предметную область», а также то, что «такой инструментарий должен обеспечивать:
1) регистрацию информации по бизнес-процессам;
2) продуцирование высокоуровневых представлений бизнес-процессов;
3) сопровождение репозитария;
4) контроль синтаксиса описания бизнес-процессов;
5) контроль его полноты и состоятельности;
6) анализ и верификацию описаний процессов и формирование соответствующих отчетов;
7) продуцирование спецификаций бизнес-процессов».
Хорошо видно, что реализация при разработке CASE-инструментария требований 1) – 7) приводит к удовлетворению условий b) и c) его соответствия Business Intelligence.
Кроме того, в статье [25] отмечается, что наименьший вред организации принесет инструментарий моделирования, «лишающий разработчика той части «творческих» возможностей, которые ведут к разнообразию представления организационных моделей». При этом степень соответствия этому требованию инструментария, использующего нотацию SADT (IDEF0), оценивается как крайне низкая. Последнее требование непосредственным образом связано с тем, что инструментарий моделирования должен быть средством поддержки принятия решений, а не художественного творчества. Таким образом, реализация этого требования при разработке CASE-инструментария приводит к выполнению условия a) его соответствия Business Intelligence.
Следовательно, можно утверждать, что в настоящее время происходит эволюция части CASE-средств, предназначенных для анализа и моделирования. И в результате этой эволюции CASE-инструментарий моделирования бизнес-систем становится средством для Business Intelligence, т.е. BI-инструментарием.
Рассмотрим инструментарий моделирования бизнеса, олицетворяющий этот эволюционный процесс на практике, т.е. программный инструментарий, автоматизирующий УФО-анализ («UFO-toolkit»). Хотя название данного инструмента легко ассоциируется с аббревиатурой УФО (как и было задумано), в данном случае «UFO» – есть сокращение словосочетания «User Familiar Object» из английского компьютерного словаря, означающего «знакомый пользователю объект» (что также полностью соответствует сути дела).
Данный инструментарий, обеспечивающий проведение системологического (системно-объектного) анализа с помощью концептуальных классификационных моделей, является принципиально новым CASE-средством, впервые представляющим собой программную систему, основанную на знаниях.
Условия работы пользователей CASE-средствами (менеджеров, специалистов по консалтингу, аналитиков, инженеров по знаниям, специалистов по информационным технологиям, архитекторов проектов, разработчиков программного обеспечения), как правило, характеризуются следующим образом:
m преобладание сложных слабоформализованных задач в слабоструктурированных проблемных областях;
m эвристическая природа методов декомпозиции сложных систем и выбора набора абстракций для OOA и моделирования;
m сложность взаимосогласованного учета структурных, субстанциальных и функциональных характеристик систем в динамических моделях;
m отсутствие на рынке «хороших» (подходящих для таких условий) инструментов и высокая цена «удовлетворительных».
Проблемы, с которыми эти пользователи сталкиваются при осуществлении своей профессиональной деятельности следующие:
m отсутствие инструментальных средств системного анализа, которые могут быть применены при объектно-ориентированном проектировании (OOD);
m отсутствие инструментальных средств OOA и OOD, обеспечивающих решение задачи выбора подходящего набора абстракций для объектной декомпозиции и моделирования;
m отсутствие инструментальных средств OOA и OOD, адаптирующихся к предметной области решаемой задачи, т.е. учитывающих семантику предметной области;
m недостаточный уровень автоматизации аналитической деятельности.
Таким образом, наиболее общие и фундаментальные потребности аналитиков и проектировщиков, использующих системный анализ, CASE-технологию и объектно-ориентированный подход, могут быть сформулированы следующим образом:
m производить процедуры анализа и синтеза сложных динамических систем наиболее объективным образом;
m адекватно и взаимосвязано представлять структуру, состав элементов и функций моделируемых систем;
m имитировать функционирование системы на ее объектной модели;
m снизить трудоемкость проектирования (за счет уменьшения числа создаваемых моделей, а также, в частности, за счет единообразного (одними и теми же средствами) представления различных (внешних и внутренних) аспектов организационных систем (бизнес-процессов));
m иметь возможность учета семантики предметной области и семантического взаимодействия с инструментальным средством;
m использовать компонентные технологии при анализе и моделировании.
Описанные выше проблемы и потребности пользователей обусловили основное предназначение инструмента UFO-toolkit и его функциональные возможности. В самых общих чертах инструмент обеспечивает представление любой системы (а также любой ее подсистемы и т.д.) в виде трехэлементной конструкции: «Узел – Функция – Объект» (УФО-элемент). Для выполнения названной функции UFO-toolkit поддерживает классификацию (библиотеку) УФО-элементов, основанную на классификации связей, пересечения которых и образуют «узлы». Таким образом, назначение UFO-toolkit может быть представлено виде UML-диаграммы вариантов использования как показано ниже (см. рис. 5.14).
 | |||
|
Использование UFO-toolkit для моделирования предполагает предварительную специализацию классификации связей и УФО-библиотеки с учетом конкретной предметной области. Это позволяет создавать шаблоны классификаций и библиотеки для различных предметных областей, которые будут обеспечивать процесс моделирования множествами алфавитных УФО-элементов.
Использование инструмента непосредственно для моделирования организационных систем осуществляется следующим образом:
m Построение контекстной модели (объектной К-модели самого верхнего уровня иерархии) анализируемой/проектируемой системы в виде «черного ящика» с указанием входных и выходных связей (функциональных), которые должны быть представлены в классификации связей. Процесс может начинаться либо со стороны классификации связей, либо со стороны контекстной модели.
m Выявление функциональных узлов в структуре моделируемой системы, т.е. узлов, функция которых либо уже известна, либо может быть сформулирована в результате проектирования. Для этого используется таблица, в которой строки обозначаются входными связями, а столбцы – выходными. Эти связи также должны быть представлены в классификации связей. При этом процесс начинается с функциональных связей, показанных на контекстной модели. Если для моделирования используются шаблоны (алфавит) УФО-элементов, то обеспечивается возможность автоматической идентификации известных Инструменту узлов. Если шаблоны не используются или в них нет необходимых в данном случае узлов, то в таблицу добавляются внутренние связи, поддерживающие функциональные, показанные на контекстной модели. Этот процесс продолжается до тех пор, пока не будет обеспечен баланс «втекающих» и «вытекающих» потоков/связей контекстной модели. При этом ручная идентификация узлов должна сопровождаться модификацией классификации связей и УФО-библиотеке.
m Построение иерархической объектной О-модели анализируемой или проектируемой системы. Данная модель в процессе анализа/проектирования представляет собой (на каждом уровне иерархии) совокупность взаимосвязанных функциональных узлов, идентифицированных с помощью таблицы. При этом каждому узлу должна назначаться функция (из всех известных и хранимых в УФО-библиотеке вариантов) в максимально возможной степени точно балансирующая данный узел. Для каждой же функции, в конце концов, должен быть указан объект (из всех известных и хранимых в УФО-библиотеке вариантов), реализующий ее оптимальным с точки зрения данного проекта образом. В результате, следовательно, объектная модель системы представляет собой (на каждом уровне иерархии) совокупность взаимосвязанных функциональных объектов.
m Имитация функционирования системы. Данный процесс обеспечивается путем анимации объектной О-модели, которая сводится к визуализации изменения во времени (с возможностью его масштабирования) активностей функциональных объектов.
Схема функционирования UFO-toolkit представлена в виде UML-диаграммы деятельности на рис. 5.15.
В инструменте обеспечена возможность учета при анимации характеристик самих объектов (например: надежности), а также возможность подсчета показателей, позволяющих сравнивать различные варианты объектной модели с точки зрения выбранных для данных узлов функций и для данных функций – объектов (например: временных, стоимостных).
Кроме того, для функций, которые могут быть описаны математически, существует возможность вычисления их значений в ходе имитации, с использованием механизма скриптов. Целью имитации является обнаружение тормозящих или простаивающих связей, функций или объектов, а также определение наилучших структуры и состава проектируемой системы.
