Business Process Management Notation: Java Graphic Implementation for Today’s BPM World

By Eric Durocher April 13, 2007

Defining any business process today involves two groups of people, the user who identifies what the process must achieve, and the developer who implements the process. Graphical displays are, and have been, a great tool to help this collaboration. It’s much easier to discuss and exchange information using a diagram than a textual representation. Graphical displays are also essential to provide a quick, intuitive feedback on process application monitoring. With the continued growth of the BPM market, vendors realize they must provide a graphical process notation that’s intuitive enough for users, yet powerful enough for developers and technical users to define implementation details. Enter Business Process Management Notation (BPMN), the most promising attempt at defining such a notation. BPMN diagrams look familiar enough to users, but also carry many implementations and advanced diagramming details in the form of graphical annotations and symbols that are necessary for developers. Examples of such advanced diagramming capabilities include complex graphic objects with dynamic decorations, hierarchical swim lanes, expandable and collapsible sub-graphs, and automatic node and link layout. This article explains the tools that are essential in the implementation of BPMN, including data model mapping, composite graphics, styling, sub-graphs, and graph layout. The application illustration will show that implementation of BPMN is difficult and costly to achieve by using the standard Java2D Application Program Interface (API). BPMN solution developers will greatly benefit from the use of powerful tools such as graphic toolkits or diagramming components. Introduction to BPMN The goal of BPMN is to define a standard way to represent BPM diagrams. Figure 1 shows a BPMN diagram; it’s essentially composed of elements representing the tasks, events, and gateways of the process. Tasks have a rectangular border with rounded corners, and contain a label and optional markers showing some properties of the task, like the fact that a task is a loop, for instance. Events have a circular border, which can be a single line, a double line or a thick line, depending on the type of the event. Events also contain an icon that depends on the event type. Gateways represent the “test” points of the process and have a diamond shape. All these elements are connected by flow objects representing transitions or messages between elements of the process. BPMN processes can optionally be organized in pools and lanes: These are rectangular areas that represent logical organization units such as a company or department. BPMN defines other objects, but we won’t describe them here. You can find more information and the latest version of the specification on the BPMN Website. Implementing BPMN in Java Implementing BPMN is a typical situation where software architects face the choice between a homemade solution and external tools. You might decide the Java platform has all you need in terms of graphic functionality to display BPMN diagrams. The Java2D API provides a rich set of drawing features, so why would you need something else? But displaying BPMN diagrams isn’t just drawing shapes and lines on the screen; it involves several techniques and tools that aren’t provided by the Java platform. This is why your BPMN integration will be greatly eased by using an external graphic library. There are two kinds of graphic tools: - Graphic toolkits provide APIs that supplement the basic Java2D drawing APIs and implement a higher-level, object-oriented layer. With a graphic toolkit, you create graphic objects such as rectangles, text or lines. Once these graphic objects are created, the toolkit handles all the background tasks of drawing the graphic objects on the screen, repainting them when necessary (such as when the user scrolls the window or when the application is de-iconified), maintaining the data structures needed to know what object the user clicks in, etc. - Diagramming components go one step further than graphic toolkits. A diagramming component plugs directly to your application’s data and displays it graphically as a diagram, so you need not worry about any graphic API or objects. You need only create and modify your data model; the diagramming component automatically updates the graphic view. We’ll explain how these three strategies (direct use of Java2D, graphic toolkit, and diagramming component) compare in terms of development effort and design. For this, we’ll examine some key features needed to represent and manipulate BPMN diagrams: - Creation and management of the graphic view - Styling - Definition of composite graphic objects to represent BPMN processes, tasks and events - Representation of sub-processes using nested graphs - Automatic layout of diagrams. Here, we consider only pure Java options, so we won’t discuss other implementation choices such as the Eclipse/SWT platform or the .NET platform. Mapping the Data Model to Graphic Objects A BPMN diagram is basically a graph: tasks, events and gateways are the nodes of the graph, and flow objects are the links that connect the nodes. All applications must represent this graph structure in memory. The BPMN standard defines the types and properties of all the BPMN elements and flow objects. Even if the precise implementation of each object is left to each application, all implementations of this BPMN business model are essentially equivalent and the different strategies will only affect the way this business model is translated to a graphic representation. If you choose to use the Java2D API directly to implement BPMN in your application, you must traverse your data model each time the graphic view has to be repainted and issue the necessary Java2D drawing calls to represent each object of the data model. This represents an important development effort, given the number of different object types and combinations of BPMN. In addition, if the data model changes dynamically, it’s difficult to know which part of the drawing has to be repainted, so it’s likely you’ll have to repaint the whole diagram even if the change really affected only a small part of the graphic view. Using a graphic toolkit, you’ll create the graphic objects representing the various BPMN elements and add them to the graphic view container. For each BPMN object (task, event, and so on), you must choose the appropriate graphic object provided by the toolkit (rectangle, circle, and so on), and set its graphic attributes to match the representation defined by the BPMN standard. This is typically done once, when the diagram is loaded. The graphic toolkit then automatically paints these graphic objects on the screen when necessary. Note that you must maintain a mapping between the BPMN business objects and graphic objects because when the state of a BPMN object changes, you must update the corresponding graphic object according to the new state. A diagramming component automatically handles this mapping of the business model to the graphic representation. To plug the diagramming component to your BPMN business model, you must provide two essential pieces of information: - You must write a “bridge” (or connector) that tells the component the nodes and links of the diagram. For BPMN, the nodes will be tasks, events and artifacts, and the links will be the flow objects that connect tasks and events. Writing the bridge is usually a small development task compared to the advantages it brings. - You must also tell the diagramming component how to graphically represent the BPMN elements. This piece of information is called the graphical style. Once the bridge is written and connected to the BPMN business and the styling information has been supplied, the application can forget all about the graphic view. All it must do is create and modify the BPMN business model; the diagramming component will handle all the painting, updating and synchronization tasks necessary to display the diagram in the graphic view. Styling The BPMN specification defines precisely many aspects of the graphic look of BPMN elements. Tasks must be represented by a round rectangle, events must have a circle border and each message type must be represented by a specified icon, and so on. There’s still some freedom, though, to modify this basic, mandatory look to suit each company’s individual needs. For example, BPMN leaves the application developer free to use color instead of black lines, or to place additional icons to identify custom tasks. Styling is a common technique to do this. For example, in the Web world, style sheets are configuration files that define the look of HTML pages by associating fonts, colors and other graphic attributes to HTML elements. Since the style sheet is a configuration file that’s kept separate from the HTML contents, this technique makes it easy for users to modify the look of the page without modifying the HTML document itself. Considering an implementation of BPMN using direct Java2D calls, styling makes no real sense. Since the BPMN objects are drawn directly, using hard-coded Java2D API calls, there’s no realistic way to apply any styling at this stage. Graphic toolkits may or may not support styling as an option. If styling isn’t supported, you must implement it on your own if you want to provide a way to customize some aspects of the look of the BPMN graphic view. For example, the style sheet could be a simple Java property file containing key or value pairs such as: Task.Border.Color : blue. The code that creates the graphic objects would then read this styling information and set the properties of the toolkit objects accordingly. A diagramming component generally provides native support for styling, in one way or another, because the mapping of the data model to graphics must be customizable. For BPMN, two levels of styling should be defined: - The standard BPMN style reflects the BPMN specification. It tells that tasks are represented by a rectangle with rounded corners, that the name of the task is displayed as a label inside the rectangle, and so on. For BPMN, the full styling information is fairly complex, so it’s likely you’ll rely on the vendor of the diagramming component to provide this. - A second (optional) level of style can specify additional graphic information such as colors, fonts, custom icons, and so on. You can use this style to differentiate your BPMN application from other vendors or to define custom objects types. For example, if your application uses a special type of BPMN tasks, you can add your own icon to differentiate these tasks. Composite Graphics Nearly all BPMN elements are composite objects. For example, a BPMN task is, at a minimum, a composition of a rectangle and a text label. Depending on the task type or state, it can contain other elements such as marker icons for loops, parallel tasks, and so on. The end user sees composite graphic objects as one element of the diagram; they can be selected and moved as a whole. But, on the implementation side, they require a strong composition model that can assemble elementary graphic objects into complex ones, and that knows how to place the elements, one relative to the other. In a pure Java2D approach, as usual, you’re on your own. Given a BPMN element to paint, your code has to compute the geometry of each graphic primitive. For example, to draw a BPMN task, you must determine the position and size of the task on the screen, draw the round ed rectangle shape, then compute the position of the text label relative to the border, draw the text, and so on. This is a tedious job, and it doesn’t allow any easy adjustments without modifying the drawing code. Graphic toolkits and diagramming components generally provide some kind of support for composite graphics. Simple tools let you add custom graphic objects that you define through the tool’s API, while more advanced tools let you define complex graphic objects without programming. An important feature to define advanced composite graphic objects is the ability to specify the layout of the composite object. For example, to add an icon to a custom BPMN task defined by your BPM application, you could say the new icon must be placed on the upper-right corner of the task’s boundary. Sub-Processes and Nested Graphs BPMN processes can be nested. A BPMN process can contain a task that’s handled by a sub-process, which can itself contain other sub-processes, and so on. When translating a nested BPMN data model to graphics, nested sub-processes will be represented as nested graphs. Nested graphs are known to be a complex problem in graphic programming. Every access or modification to the graph must take the nesting level into account, and if this isn’t done properly, it might cause performance problems because nesting leads to highly recursive algorithms. There’s no doubt you’ll face these problems while implementing BPMN, using a pure Java2D approach, so the sub-process functionality alone will be an important part of the overall development effort. Most graphic toolkits and diagramming components support nested graphs, so using one of these two approaches will help you handle this problem more easily. In addition, graphic tools often provide advanced functionality such as the ability to expand and collapse sub-processes interactively: This feature makes it much easier to view or edit BPMN processes by hiding the details of individual sub-processes while viewing or working at the top-level process. Automatic Layout Automatic layout is another feature that graphic toolkits or diagramming components provide and that’s essential to improve the usability of a BPMN solution. Automatic layout algorithms fall in two classes: - Node placement algorithms will automatically compute the positions of the nodes, according to the structure of the graph. - Link routing algorithms compute the shapes of the links to prevent links from touching or crossing nodes and to minimize the crossings between links. Link routing algorithms can also reshape links into a sequence of orthogonal segments. Graph layout algorithms are typically used for BPMN diagrams (such as the “hierarchical layout” algorithm); they’re complex algorithms that require in-depth knowledge in graph theory, so graph layout is another critical area where developers will save big development efforts by choosing a graphic toolkit or component as opposed to a “homemade” Java2D approach. Conclusion The BPMN standard is a promising attempt at defining a graphical notation for a business process; integrating BPMN views and editors is becoming an important added value for any BPM solution. The development effort required can be dramatically reduced by the use of a third-party graphic product. Graphic toolkits handle all the low-level painting and drawing tasks as well as features such as nested graphs or automatic graph layout. Moreover, diagramming components automatically handle the connection and synchronization between your BPM data model and your graphic views, so using a diagramming component will significantly reduce the development time. Given all the importance of a powerful graphic tool for the integration of BPMN in BPM solutions, out-of-the-box support for BPMN will become an important differentiator for graphic tool vendors.
Eric Durocher has a Ph.D. in Computer Science and is principal architect for ILOG. He leads the ILOG JViews Diagrammer development team, which includes Stéphane Lizeray and Soyhy Lim, key developers for the JViews BPMN module.

About The Author(s)

Eric Durocher
Eric Durocher has a Ph.D. in Computer Science and is principal architect for ILOG. He leads the ILOG JViews Diagrammer development team, which includes Stéphane Lizeray and Soyhy Lim, key developers for the JViews BPMN module