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

on

Процесс разработки информационных систем развивается по спирали, практически всегда возвращаясь к постановке задачи, но уже с новыми спецификациями. Таким путем бизнес непрерывно стремится улучшить свою эффективность за счет применения гибких, адаптируемых и перестраиваемых технологий. Долгосрочные прогнозы все сложнее сделать в изменяющейся окружающей среде. Поэтому предприятие (бизнес) должно не только быстро приспосабливаться к изменениям, но также и непрерывно развиваться. В этих условиях способность информационной системы перестраиваться становится постоянным внутренним процессом, а не просто внешним фактором, к которому предприятие должно приспособиться. Технологичное бизнес-моделирование представляет собой необходимый элемент создания адаптируемого программного обеспечения. Материализация бизнес-идей (представленных диаграммами бизнес-процессов) в виде модели программного обеспечения является трудоемким процессом. Сложность обусловлена применением технологически разрозненных методов и средств описания бизнес-процессов; в частности, на практике применяются как функциональное моделирование бизнес-процессов, так и объектно-ориентированное. Не все классы и объекты, определенные в бизнес архитектуре, могут быть включены в модель программного обеспечения (например, диаграмму UML). Поэтому трансформация бизнес-модели в модель программного обеспечения не является строго формализованным процессом .146 Не существует полностью универсальных инструментов, поэтому задача заключается в том, чтобы найти соответствующий инструмент для проектирования. Для заказчика важно, чтобы он предоставлял ясные описания бизнес-процессов. А для проектировщика важно, чтобы инструмент был удобным в работе и содержал максимум возможностей и их эффективную реализацию. Примерами инструментов являются средства построения бизнес-модели (AllFusion Process Modeler, AI0Win, Rational Rose) . Бизнес-модель может использоваться в процессе разработки программного обеспечения для того, чтобы: 65535принимать решение при выборе вида информационной системы (инновационная, стандартная или соблюдающая преемственность); 65536определять функциональные требования: набор функций использования (Use Cases), которые должна поддерживать информационная система; 65537определять нефункциональные требования (затрагивающие всю систему); 65538идентифицировать подходящие бизнес-компоненты, которые инкапсулируют определенную область бизнес-функциональности. На стадии перехода к модели программы возникает проблема трансформаций диаграмм бизнес-процессов в диаграммы описания программного кода. Здесь полезны автоматизированные средства представления требований на изменение, которые были сделаны в одном средстве, в терминах и моделях другого средства. В частности, при повторном использовании данных (CASE-средства зачастую оперируют одними понятиями и терминами), удобнее не ручной перенос их из одной модели в другую, а чтобы это выполнялось автоматически или с минимальным вмешательством в особых случаях. На этапе проектировании программного продукта перед его имплементацией разрабатываются диаграммы на основе моделей «Сущность-Связь» (ERD). Это может являться и диаграммой классов UML, и диаграммой IDEF1X — в зависимости от архитектуры системы (база данных, система управления, локальное приложение и так далее). На основе таких объектных диаграмм дальше работают архитекторы программного кода, оптимизаторы, и проводится рефакторинг . Примерами инструментов, поддерживающих построение ER-моделей, являются Together, Rational Rose, ERwin, Paradigm+. 2. Программные средства для трансформации диаграмм IDEF0 Ряд инструментов, поддерживающих данные технологии, позволяет проводить трансформацию диаграмм бизнес-процессов в диаграммы классов (BPwin, ERwin, Paradigm+, Rational Rose, BPLink). Был проведен их анализ. В качестве критериев оценки возможностей, предоставляемых данными средствами, были использованы: 1) ) время на выполнение; 2) сложность освоения и проведения; 3) потери данных при трансформации; 4) ) время, с которого возможно проводить трансформацию (на какой стадии проектирования бизнес-процессов можно проводить пробную трансформацию без существенных затрат времени и средств); 5) возможность настройки процесса трансформации (степень автоматичности); 6) ) стоимость подхода (дополнительного программного обеспечения). 147 Результаты исследований различных подходов для трансформации диаграмм совпадают с указанными авторами назначениями программ. А именно то, что они в большинстве своем служат: 65535для связи моделей, а не для повторного использования предыдущих; 65536для поддержания целостности представления всей системы в различных разрезах и с различных точек зрения; 65537для мультипользовательской разработки и контроля версий. С другой стороны, при сравнении линеек BPwin-ERwin-Rational Rose и BPwin-ERwin-Paradigm Plus было выявлено, что: 1) ) требуется время на заполнение словарей сущностей и атрибутов (и связывание их с процессами и стрелками), при этом, в случае их большого количества, возможно внесение ошибок (также требуется настройка как промежуточного, так и конечного средства проектирования); 2) требуются навыки моделирования на промежуточном средстве (ERwin, Paradigm Plus); 3) при трансформации теряется основное, что создается в IDEF0 — процессы; 4) проведение трансформации возможно лишь при заполненных словарях сущностей и атрибутов, которые чаще всего заполняют только при связывании модели бизнес-процессов с ERwin (и выполняется это чаще другими людьми, например, администраторами баз данных); 5) трансформация полностью автоматична. Вносить исправления возможно, лишь открыв диаграмму классов в конечном средстве проектирования; 6) в стоимость проекта добавляется стоимость промежуточного средства проектирования. Перечисленные особенности чаще всего не позволяют повторно использовать модель бизнес-процессов для автоматизированного построения диаграмм классов. Использование же подхода BPwin-BPLink-Paradigm Plus напрямую не дает диаграммы классов. Требуется трансформация диаграмм Use Case в диаграмму классов, что представляет собой отдельную задачу. К тому же теряются связи входных и выходных параметров. 3. Формальное описание элементов нотаций Для описания системы трансформации следует выделить основные элементы диаграмм. Обозначим множество названий элементов (собственных имен, например «Адаптация») как N, состоящего из элементов ni. По диаграммам IDEF0 выделим пятерку: E = F, A, EN, R, ATR , где F — множество функциональных блоков на диаграмме; A — множество стрелок; EN — множество сущностей; R — множество ролей стрелок; ATR — множество атрибутов. 148 Множество F состоит из элементов fi = Пі, pi , где ni — элемент из множества названий N; pi — ссылка на родительский блок для данного блока из множества F. Множество R состоит из элементов R = I, C, O, M , где I — обозначение входной стрелки; C — обозначение стрелки управления; O — обозначение выходной стрелки; M — обозначение стрелки механизма. Множество A состоит из элементов aj = nj, rj, pj , где nj — элемент из множества названий N; rj — элемент из множества ролей стрелок; pj — ссылка на блок, который связан с данной стрелкой Множество ATR состоит из элементов atrm = nm, pm, pEnm , где nm — элемент из множества названий N; pm — ссылка на блок или стрелку, связанных с данным атрибутом; pEnm — ссылка на сущность, агрегирующей данный атрибут. Множество EN состоит из элементов enk = nk, pk , где nk — элемент из множества названий N; pk — ссылка на блок или стрелку, связанных с данной сущностью. Для диаграмм классов выделим такую совокупность: U = CL, AtrCl, MT, PM, RL, T, OB, TREL , где CL — множество классов; AtrCl — множество атрибутов классов; MT — множество методов классов; PM — множество параметров методов классов; RL — множество отношений между классами (наследование, ассоциация и т.д.); T — множество типов; TREL — множество типов отношений; OB — множество объектов. Множество T состоит из элементов ti = ni, pCli , где ni — элемент из множества названий N; pCli — ссылка на класс, который реализует тип. Множество OB состоит из элементов obj = nj, pTj , где nj — элемент из множества названий N; pTj — ссылка на тип данного объекта. Множество AtrCL состоит из элементов atrClk = nk, pTk, pClk , где nk — элемент из множества названий N; pTk — ссылка на тип данного атрибута; pClk — ссылка на класс, агрегирующий данный атрибут. Множество PM состоит из элементов pmn = nn, pTn, pMtn , где nn — элемент из множества названий N; pTn — ссылка на тип данного параметра метода; pMtn — ссылка на метод, которому принадлежит параметр. Множество RL состоит из элементов rlr = pClParentr, pClChildr, pTrelr , где pClParentr — ссылка на класс-родитель отношения; pClChildr — ссылка на класс-приемник отношения; pTrelr — вид отношения. 149 Множество MT состоит из элементов mtm = nm, pTm, pClm , где nm — элемент из множества названий N; pTm — ссылка на тип данного метода (возвращаемое значение); pClm — ссылка на класс, агрегирующий данный метод. Множество TREL состоит из элементов Trel = As, Ag, Comp, Gen , где As — ассоциация; Ag — агрегация; Comp — композиция; Gen — наследование; Множество CL состоит из элементов clp = np , где np — элемент из множества названий N. Итак, получаем, что требуется сформировать такое множество правил перевода RULES, которое будет отображать из E в U. RULES: E — U. На основе приведенных описаний элементов можно перейти к формальному построению правил трансформаций, например, с помощью применения технологии онтологического анализа. Но перед этим шагом, следует рассмотреть технику неформальных методов правил трансформаций — для этого был проведен анализ приемов ряда специалистов, используемых ими при переходе от функциональных диаграмм к объектно-ориентированным. В результате были выявлены как наиболее простые (и наиболее часто встречаемые) правила, так и правила, сильно зависящие от контекста данны на IDEF0-диаграммах. Обобщенные результаты представлены в табл. 1. В — такая трансформация возможна; Н — трансформация сильно зависит от настроек правил; А — трансформация является автоматической (выполняется, если иное не определено проектировщиком); 1 — трансформация, которая встречается чаще, нежели другие в данном столбце. Для формализации правил трансформаций необходимо сравнить семантику понятий, используемых при объектно-ориентированном и функциональном 150 проектировании. Далее выделены основные моменты, которые следует учитывать при их определении (табл. 2). Таблица 2 Сравнение семантик при объектно-ориентированном и функциональном проектировании (полужирным шрифтом выделены элементы определенной нотации) Объект трансформацииОписание возможных трансформаций 12 Диаграммы функциональной модели на нижнем уровне детализируют верхние.Порядок создания элементов диаграммы классов должен быть в целом таков: 1) определение типов; 2) определение классов; 3) определение наследования; 4) определение объектов типа класса; 5) определение атрибутов класса; 6) определение методов, параметров метода, типа метода, ролей ассоциации. По стандарту ИСО каждый блок должен иметь хотя бы одну управляющую и одну исходящую дугу.Исполнитель метода не всегда определен. В таких случаях в качестве исполнителя следует брать ближайший механизм на родительской диаграмме или преобразовывать название блока в класс с одним методом, причем, возможно, имя класса будет либо именем блока, либо именем выхода. Выход при этом может быть атрибутом механизма. Управление — это часть блока.Управление может быть одним из атрибутов класса. Дуга должна быть помечена до разветвления. А после разветвления, если есть пометка — дуга содержит все или часть объектов, указанных до разветвления, если нет пометки — дуга содержит все объекты, указанные до разветвления. Дуга должна быть помечена после слияния. А до слияния, если дуга не помечена — она содержит все объекты результата, если помечена — содержит все или часть объектов результата. Разветвляющиеся/соединяющиеся дуги отражают иерархию объектов, представленных этими дугами.Эти правила должны определять возможность наследования (либо указано пользователем, либо употреблены однокоренные слова в названиях стрелок). Дуги представляют множество объектов: планы, данные в компьютерах, машины и информация, бумажные материалы, физические материалы, инструменты, чертежи, рабочая среда, управленческая информация. Дуги описываются существительными или существительными с определениями.Чаще всего дуги относятся к именам классов, атрибутам, типам и объектам. Дуги механизмов — отражают, как функции реализуются. Показывают физические аспекты функций (склады, людей, приборы).Дуги механизмов чаще всего являются классами, объектами класса, для которых блок — это их метод, а входы и выходы могут быть атрибутами. Класс — описание объектов со свойствами. Атрибут — свойство класса — принимает множество значений. Блок может быть меткой роли ассоциации.Понятие атрибут больше относится к стрелкам вход-выход, а класс — к стрелкам меха-низм-уп равление. При существовании лишь одиночных стрелок, входящих в блок, можно интерпретировать его как роль ассоциации. 151 Использование приведенных в таблице правил позволит сформулировать алгоритм автоматической трансформации. В программной реализации используются следующие правила: 1) ) все стрелки механизмов на диаграмме IDEF0 трансформируются в имена классов — владельцев методов, в которые трансформируются блоки; 2) все блоки — в имена методов классов (при этом они дублируются в каждом механизме-классе, который входит в блок); 152 3) ) внешние входы (не образованные от выходов) — в классы, и являются атрибутами класса-механизма, входящего в блок; 4) ) внутренние входы (образованы от выходов) — в классы, типы параметров метода (блока, в который входят), связаны ассоциацией с классом-механизмом, входящим в блок; 5) все управления — в классы, связаны зависимостью с классом-механизмом, входящим в блок; 6) все выходы — в типы возвращаемого значения метода (на каждый выход создается свой метод в данном классе-механизме); 7) диаграмма А-0 не участвует в трансформации (слишком много лишних зависимостей). При проведении программной реализации был использован ряд паттернов проектирования («компоновщик», «посетитель», «итератор», «фабричный метод»), который позволил построить гибкий каркас приложения, легко адаптируемый под разные требования к организации системы трансформации . Noran O. UML vs IDEF: An ontology-oriented comparative study in view of business modelling : Paper accepted at the 6th International Conference on Enterprise Information Systems. 2003. 53 p. // http: // www.cit.gu.edu.au/~noran (по состоянию на 29.03.2006). Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. СПб.: Питер, 2002. 496 с. Моделирование бизнес-процессов с AllFusion. М.: Диалог-Мифи, 2003. 224 с. Технологии разработки программного обеспечения. СПб.: Питер, 2003. 528 с. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Патте