Transforming UML <<Activity>> Diagrams to WebSphere Business Modeler processes

This article shows how to automatically transform UML activity diagrams into WebSphere® Business Modeler processes. Requirements analysis is frequently performed using UML, creating activity diagrams to describe business processes. However, UML tools usually do not provide support for cost and duration analysis and simulation, which is why it is important for a model-driven architecture (MDA) approach to be able to reuse the UML diagrams in a more business-oriented fashion. This content is part of the IBM WebSphere Developer Technical Journal.

Catherine Griffen (catherine_griffin@uk.ibm.com), Software Development Engineer, IBM

author imageCatherine Griffin is a Software Development Engineer in IBM Software Group, Information Management Master Data Management Platform Services Development.



Ruo Bo Huang (huangrb@cn.ibm.com), SOA Software Designer and Manager , IBM

author imageRuo Bo Huang is a SOA Software Designer and manager in IBM Software Group, Application and Integration Middleware Software.



Zhang Sen (samuel.zh@gmail.com), SOA Software Designer, IBM

author imageZhang Sen is a Service Oriented Architecture Software Designer in IBM Software Group, Application and Integration Middleware Software.



Marc Fiammante, WW Chief Architect SOA Advanced technology engagements , IBM

author imageMarc Fiammante is WW Chief Architect SOA Advanced technology engagements in IBM Software Group.



18 July 2007

Also available in Chinese

Introduction

Since UML's inception, Activity diagrams have identified and addressed the need for describing the workflow of a business use case.

<<Activity>> diagrams as defined in the Unified Modeling Language are derived from various techniques to visually illustrate workflows; see, for example, Johansson et al. And much of the basis for the definition of the activity diagram notation is found in Martin and Odell.

As a consequence, many enterprises that use UML as their main modeling approach have captured all of their workflows as "<<Activity>> Diagrams". However, UML models and tools are perceived by the business analyst community as not being directly relevant to their needs because they do not address some of the essential business questions around workflows, such as:

  • What resources?
  • What duration?
  • What cost?
  • Where are the bottlenecks of my business processes?

In the recent years, dedicated tools such as WebSphere Business Modeler (hereafter called Modeler) have appeared on the market, covering all of these business analyst requirements. Enterprises do not want to re-enter their business processes, but would like to transform their existing UML <<Activity>> Diagrams and import them as Modeler processes.

This article describes how to tranform UML activity diagrams to Modeler processes, using the Rational platform with the Model Transformation Framework tool from alphaWorks.


Comparing UML and Modeler models

In this section we will look at the different UML models and how they correspond to Modeler models.

UML Models

The Rational platform captures the UML models using XMI, which is an XML representation of the models. For example Figure 1 shows the visual representation of the .emx file generated by Rational Software Architect.

Figure 1. Sample activity diagram in Rational Software Architect
Sample activity diagram in Rational Software Architect

Listing 1 shows an extract of the original EMX file that contains the UML activity diagram. Notice the XMI specialized types, such as uml:Action, uml:ControlFlow, uml:InitialNode, uml:DecisionNode, etc. which all represent elements on the activity diagram.

Listing 1. Equivalent XMI content for the activity diagram in the .emx model file
<node xmi:type="uml:Action" xmi:id="_Avu8wIUVEdm56dw_R1diwQ"
name="Display the invalid transaction method" outgoing="_HWnxMIUVEdm56dw_R1diwQ"
incoming="_G8_wQIUVEdm56dw_R1diwQ" inPartition="_Ma1wgCxWEdmvKqXrpJi5vg" />

<edge xmi:type="uml:ControlFlow" xmi:id="_ToFR0ItkEduYV7PKgmO2BA"
source="_PGZ2YItkEduYV7PKgmO2BA" target="_D6QW4CxTEdmvKqXrpJi5vg"
inPartition="_Ma1wgCxWEdmvKqXrpJi5vg">
    <guard xmi:type="uml:OpaqueExpression" xmi:id="_ToFR0YtkEduYV7PKgmO2BA" />
    <weight xmi:type="uml:LiteralInteger" xmi:id="_ToFR0otkEduYV7PKgmO2BA" value="1" />
 </edge>

<node xmi:type="uml:InitialNode" xmi:id="_CnqM0Ov4EdiPOP7oqdlXhA" name="Initial Node"
outgoing="_0zcw8IUUEdm56dw_R1diwQ" inPartition="_KMFZ8CxWEdmvKqXrpJi5vg" />
 
<node xmi:type="uml:DecisionNode" xmi:id="_dGPToCxSEdmvKqXrpJi5vg"
outgoing="_G8_wQIUVEdm56dw_R1diwQ _PZwhMIUVEdm56dw_R1diwQ"
incoming="__Vbh8IUUEdm56dw_R1diwQ" inPartition="_Ma1wgCxWEdmvKqXrpJi5vg" />

<node xmi:type="uml:ActivityFinalNode" xmi:id="_D6QW4CxTEdmvKqXrpJi5vg" 
name="Activity Final Node" incoming="_ToFR0ItkEduYV7PKgmO2BA"
inPartition="_Ma1wgCxWEdmvKqXrpJi5vg" />

<node xmi:type="uml:MergeNode" xmi:id="_KLhj0CxXEdmvKqXrpJi5vg"
outgoing="_MgsEYCxXEdmvKqXrpJi5vg" incoming="_HWnxMIUVEdm56dw_R1diwQ
_S1GmsIUVEdm56dw_R1diwQ" inPartition="_Ma1wgCxWEdmvKqXrpJi5vg" />

<node xmi:type="uml:Action" xmi:id="_nWKFYIUUEdm56dw_R1diwQ" 
name="Customer/Teller selects Transfer money from menu"   
outgoing="_3eaoIUUEdm56dw_R1diwQ" incoming="_0zcw8IUUEdm56dw_R1diwQ"
inPartition="_KMFZ8CxWEdmvKqXrpJi5vg" />

XML schema for importing into Modeler

Modeler provides an XML schema that defines the structure of an XML file that you can import as a business process along with associated artifacts. The XML schema is located under the Modeler installation path in: samples\import\xml\wbimodeler.xsd. Listing 2 shows an extract of the schema that represents the content of a process flow

Listing 2. Schema representing the content of a process flow
<xsd:element name="flowContent" minOccurs="0">
	<xsd:complexType>
		<xsd:choice maxOccurs="unbounded">
		<xsd:element name="startNode" minOccurs="0">
		"€¦
			</xsd:element>
			<xsd:element name="stopNode" minOccurs="0">
			"€¦
			</xsd:element>
			<xsd:element name="endNode" minOccurs="0">
			"€¦
			</xsd:element>
			<xsd:element name="task" type="Task" minOccurs="0"/>
			<xsd:element name="decision" type="Decision" minOccurs="0"/>
			<xsd:element name="merge" type="Merge" minOccurs="0"/>
			<xsd:element name="fork" type="Fork" minOccurs="0"/>
			<xsd:element name="join" type="Join" minOccurs="0"/>

Mapping UML XMI content to Modeler XML

So now if we want to convert from UML to Modeler, we just have to convert XMI elements to their respective Modeler equivalent. Table 1 shows the respective elements that we have to transform to convert an activity diagram to a Modeler process.

Table 1. UML to Modeler element mapping
UML element or attribtueModeler tag or attribute

xmi:type="uml:Activity"

"Process"

xmi:type="uml:Package"

"Catalog"

xmi:type="uml:Class"

"Service"

xmi:type="uml:Action"

"Task"

xmi:type="uml:ControlFlow"

"Connection"

xmi:type="uml:DecisionNode"

"Decision"

xmi:type="uml:MergeNode"

"Merge"

xmi:type="uml:ForkNode"

"Fork"

xmi:type="uml:JoinNode"

"Join"

xmi:type="uml:InitialNode"

"startNode"

xmi:type="uml:ActivityFinalNode"

"endNode"

xmi:id

Modeler elements are identified by "name" attribute

name

"description"


Transforming models with the Model Transformation Framework

The IBM Model Transformation Framework (MTF) is a set of tools that help developers tranform between Eclipse Modeling Framework (EMF) models. Using this framework we can implement the mapping described above.

MTF lets you define a transformation between models as a set of declarative rules (also called relations), using the MTF relation definition language. The MTF transformation engine then executes those rules to synchronize the target model files with the source model files. The advantage of this approach is that you can define complex mappings very concisely (compared with the equivalent Java code) which lets you quickly prototype transformations. MTF works only with EMF models, which you should be familiar with to use it successfully.

Before implementing the transformation, we must identify the EMF models that we need to use. In this case, the source for the transformation is a Rational .emx file (UML model). This model can be read using the Eclipse.org UML2 implementation, which is an EMF model.

The XML schema in Listing 2 defines the target file. We could use the EMF tools to generate an EMF model from the XML schema, but in this case there is no need because the EMF model corresponding to the schema is included with the Modeler tools.

You define the rules for the transformation in a text file with the extension .rdl. This file extension is associated with the MTF mapping rules editor. The file begins with some import statements, which tell MTF which EMF models the rules refer to, as Listing 3 shows:

Listing 3. Import statements specifying the EMF models
import uml "http://www.eclipse.org/uml2/1.0.0/UML"
import bom "http://www.ibm.com/wbim/bomSchema1.0"
import emf "http://www.eclipse.org/emf/2002/Ecore"
import uml "http:///com/ibm/mtf/xtools/uml2.ecore"
import ws "http:///com/ibm/mtf/model/workspace.ecore"
import emf "http:///com/ibm/mtf/model/emf.ecore"
import util "€http:///com/ibm/mtf/util.ecore"€

The first three import statements declare the UML2 model, the Modeler XML schema, and the EMF Ecore model, respectively. The remainder of the imports refers to EMF models that are supplied with MTF, which provide various utilities to make it easier to write the rules.

We can quickly define some initial rules based on the mapping table above, as Listing 4 shows:.

Listing 4. Mapping rules
relate activity2process(uml:Activity activity, bom:Process process)
relate pkg2Catalog(uml:Package pkg, bom:Catalog bomCatalog)
relate action(uml:Action action, bom:Task task)
relate connection(uml:ControlFlow flow, bom:Connection conn)

Each of these relate statements is a rule. You can think of each rule as defining a mapping (look-up table) between elements of the indicated types. For each rule, we can now define a set of constraints to apply to the mapped elements. The MTF transformation engine will try to create or modify the target model to make those constraints hold.

For example, the rule in Listing 5 specifies that whenever a UML Action is mapped to a Modeler Task, the name of the Action should be the same as the description of the Task. It also defines a constraint as a prerequisite an Action can only be mapped to a Task if the XMI ID of the Action matches the name of the Task. This sort of prerequisite constraint is important to ensure that each Action maps to only one Task.

Listing 5. Rule relating Actions to Tasks
relate action(uml:Action action, bom:Task task)
	when equals(action.xmi_id, task.name) {
	equals(action.name, task.description)
}

EMF provides several other kinds of constraint in addition to equals. The most important of these allows you to link together rules so that when two elements have been mapped, further rules apply to related elements. For example, when you map a UML Activity to a Modeler Process, we would like to map the Actions contained by the Activity to the Tasks contained by the Process, as Listing 6 shows:

Listing 6. Mapping Activity Actions to Process Tasks
relate activity2process(uml:Activity activity, bom:Process process)
	when util:MatchString "{0}##{1}" 
		(activity.package.xmi_id, activity.name, process.name) {
	action(over activity.action, over process.flowContent.task),
	connection(over activity.edge, over process.flowContent.connection)
}

The constraints in Listing 6 apply the action and connection rules to the content of the UML Activity and Modeler Process. The over keyword indicates that a collection of elements will be processed.

Once you have written some rules, you can execute them directly by creating an MTF Mapping Rules launch configuration (from the Run menu) or you can use the MTF Java API within a Java application or Eclipse plug-in. We implemented a simple Eclipse plug which added a pop-up menu item to execute the transformation for any.emx file.


Cleaning up the process for readibility

If you look closely at the UML model in Listing 1, XMI differentiates IDs and names. For example, the action Display the invalid transaction method has an id xmi:id=_Avu8wIUVEdm56dw_R1diwQ. This action would be translated to an activity named _Avu8wIUVEdm56dw_R1diwQ in Modeler, with a description of Display the invalid transaction method, but the name would not be very legible in the business process diagram.

So we need to replace the IDs by the names, respecting the Modeler length limits of 50 characters for names, and suffixing with "1, 2, 3" when duplicate names result. This step requires post-processing after MTF has completed its transformation, using the Modeler APIs.

To complete that task we use the com.ibm.btools.te.xmlplug-in in Modeler, which defines the related Modeler meta-model interface. Figure 2 shows the elements of this package.

Figure 2. Modeler class diagram
Modeler class diagram

The result of the MTF transformation is a Modeler business process embedded in a standard EMF Resourceobject, as Listing 7 shows:

Listing 7. Resulting Resource object
Resource targetResource  = set.createResource
(URI .createPlatformResourceURI(target.getFullPath().toString()));
"€¦"€¦  
/*MTF invocation, transforming original UML model into Modeler resource */
ITransformationSession engine = MappingEngineFactory.createTransformationSession(def);
Object[] args = new Object[] { source, targetResource };
Mapping mapping = engine.map(rule, args, new SubProgressMonitor(monitor, 27));

This resulting Resource object includes hierarchical information about the Modeler business process. For the naming problems that cannot be resolved by simple mapping, we directly retrieve the content of the Resource object, then cast it into Modeler objects, and use the related Modeler package API to manipulate it.

The DocumentRoot instance object is the first retrieved, and is the root node used in the operation logic in Listing 8:

Listing 8. DocumentRoot instance object
DocumentRootImpl wbmDocRoot= (DocumentRootImpl)  targetResource.getContents().get(0);
// Then, using DocumentRoot, retrieve the Processes object.
ModelType modelType = wbmDocRoot.getModel();
ProcessModel pcsModel = modelType.getProcessModel();
ProcessesType pcsType = pcsModel.getProcesses();
EList processes = pcsType.getProcess();

Then in Listing 9 we drill further down to retrieve the various flows as FlowContentType and access the various embedded Modeler element objects: Task, Connection, Decision, Join, Fork and Merge.

Listing 9. Retrieving flows
for (Iterator i = processes.iterator();i.hasNext();){
	ProcessImpl process = (ProcessImpl)i.next();
	FlowContentType flowCType = process.getFlowContent();
	EList tasks = flowCType.getTask();
	EList connections = flowCType.getConnection();
	......
}

Now that we have access to these detailed element objects, we can implement the necessary additional logic. For the naming problem, we need to convert names using the more readable descriptions, but limit their length to no longer than 50 characters. Also, to avoid conflicting duplicates, we assign suffixes to any duplicates ":1,:2,:3". To replace the original ID name with a more readable description and limit the length, we access the runtime element TaskImpl object.

We store all the changed names into another HashMap called nameUpdateMap. TheKey of this HashMap is the original name (UMLID) and Value is the maximum number of its occurrences. Taking Task as an example, Listing 10 shows the complete logic for resolving its duplicate name problem.

Listing 10. Duplicate name logic for Tasks
private HashMap taskNameMap = new HashMap();
....
// associate task names with a  legible description
for (Iterator j = tasks.iterator();j.hasNext();){
	TaskImpl task = (TaskImpl)j.next();
	String name = task.getName(); 
	// The current name that comes from UML and which is a unique Id.
	String desc = task.getDescription();
	if (desc!=null && !("").equals(desc)){ //  truncate desc length to 50 at most
		if (desc.length() > 50) { desc = desc.substring(0,50); }
		// verify whether desc already exists and 
		// update the max ID value for same Name
		iif (taskNameMap.get(desc)== null)  { 
			taskNameMap.put(desc,new Integer(0));
		} else { // Update the suffix maximum
			Integer maxID = (Integer)taskNameMap.get(desc);
			maxID = new Integer(maxID.intValue()+1);
			taskNameMap.put(desc,maxID);
			desc += maxID.toString();
		}
		task.setName(desc);  
		nameUpdateMap.put(name,desc); 
		// Update the names correspondence with the suffixes
	}
}

// Then process the nodes to update the names in the model.

The same logic also applies to other nodes elements, such as Decision, Fork or Merge. Next you need to update the connection links of type Connection in the transformed Modeler process, as the SourceType and TargetType might be linking elements with changed names.

Listing 11 updates Connections to ensure they are still valid.

Listing 11. Ensuring connections are still valid
for (Iterator k = connections.iterator();k.hasNext();){
	ConnectionImpl connection = (ConnectionImpl)k.next();
	SourceType sourceType = connection.getSource();
	TargetType targetType = connection.getTarget();
	String cp = sourceType.getNode();
	if (nameUpdateMap.get(cp)!=null) 
		{ sourceType.setNode((String)nameUpdateMap.get(cp)); }
		cp = targetType.getNode();
		if (nameUpdateMap.get(cp)!=null) 
		{ targetType.setNode((String)nameUpdateMap.get(cp)); }
}

Finally, you save the Modeler Resource, therefore providing the better readability in the resulting file, as Figure 3 shows:

Figure 3. Resulting process in Modeler
Resulting process in Modeler

Conclusion

The transformation described in this article lets users that modeled their processes in a Rational Software Architect UML environment easily reuse these models in a Modeler environment. Given the existing Modeler to Rational transformation, the availability of this Rational to Modeler transformation facilitates round-trip business engineering between the Rational platform and WebSphere Business Modeler.

This transformation also means you can validate functional business architectures, produced in UML, against their performance requirements, e.g. business requirements for throughputs, processing, loadings, and resource availability.

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere, SOA and web services, Architecture
ArticleID=240254
ArticleTitle=Transforming UML <<Activity>> Diagrams to WebSphere Business Modeler processes
publish-date=07182007