Skip to main content

UML and Process Definition for Java - JSR 207

Posted by johnreynolds on November 14, 2003 at 11:01 AM PST

Martin Fowler's blog on the Unwanted Modeling Language caught my eye and prompted me to re-examine my own feelings about UML.

I've never been really fond of UML.
I am fond of the less formal "CRC Cards" approach, and I'm drawn to the ideals of Extreme Programming. If I knew more about Agile Modeling I would probably embrace it.

I was introduced to UML before it was called UML. Booch and Rumbaugh had not made peace yet, and you had to choose between "Fluffy Clouds" and OMT. OMT bothered me because it was not mandatory to specify the class interfaces. It also bothered me that I was encouraged to specify the data elements (attributes). To me, that violated what I considered the tenets of Object Oriented design. OMT had a data modeling feel to it and seemed to pay too much homage to Entity Relationship Diagrams. Perhaps this was more a failing of my instructors then of the methodology, but I never quite got over the bad first impression.

Over the years, UML tools became better (and cheaper), several new diagram types were introduced, and I somewhat resigned myself to the ubiquity of the "Rational Unified Process". I still ranted at the inability of tools to reliably extract UML diagrams from existing code (round-trip-engineering), but essentially I gave in to the pressure and shut up.

Why then did I race to read Martin Fowler's blog when I saw the tag "Unwanted Modeling Language"?

UML 1.x provides nine standard diagram types (UML 2.x raises the count to 13), but I’m really only “fluent” with three:

  • Class Diagram
  • Use Case Diagram
  • Sequence Diagram

I have found all three of these UML diagram types to be useful, but I have never found them to be integral to my development process. Inevitably the diagrams languish once "real development" begins, and if I need them later I reconstruct them from the code. I'm definitely not in the "UmlAsProgrammingLanguage" camp, and most of my colleagues prefer to "read the code" rather then fire up a UML tool. Javadoc is our preferred communication tool.

Perhaps better tools would change my habits, but there is still a big stumbling block for me.

Simply put, I have not mastered a UML diagram type that lends itself to the aspects of programming that I deal with most often. I gather a lot of requirements from users, and I design a lot of user interfaces. I have not found UML diagrams particularly helpful for either task, but have to admit that I really ought to learn more about the Activity diagrams.

"Activity diagrams are business process diagrams and track the flow of individual software objects from internally generated actions in a business context. They are often used to expose parallel and concurrent activities in use cases."

Most of what I deal with involves defining or understanding processes. User interfaces are very process oriented because they deal with the communication between humans and machines, but I think that it's safe to say that most programs implement a process or part of a process.

The UML activity diagrams seem well suited for my work, but there is a huge drawback (in my opinion). Nothing in the activity diagram is tied back to the source code (or visa-versa). You can't generate source from the activity diagram (not that I would really want to) and more importantly (for me) you cannot generate an activity diagram from source code.

Perhaps JSR-207 will change things and provide the kick in the pants that will drive me to master the UML activity diagrams.

"Process Definition for Java will build on Java Language Metadata technology (JSR-175) to provide an easy to use syntax for describing a business process at the source code level for the J2EE platform. Metadata will bind data and tasks within the process definition to variables, classes, and tasks in the source code. The metadata will be amenable to manipulation by tools."

JSR-207 (also known as PD4J) is still a work in progress, but it is based on BEA's Java Process Definition and close to fruition. JPD is included in Weblogic Workshop 8.1 and supports the following Process Definition Constructs:

  • Client Interactions
  • Control Interactions
  • Branching
  • Looping
  • Business-level parallelism
  • Blocking for one of multiple events
  • Transparent access to custom code
  • Arbitrary grouping of nodes
  • Exception handlers and timeouts
  • Explicit JTA transaction blocks

JSR-207 is limited to J2EE. It doesn't define a standard Process Definition Diagram, but I think it could definitely nudge UML tools in that direction. I've seen the modeling tools in Weblogic Workshop 8.1 and the process diagrams have been instantly embraced by my business owners. I love the idea of being able to navigate between a process diagram and the source code that implements a specific step of the process. The more that I can associate a piece of code with what it does for the user, the more confidence I will have that I've implemented what the customer wanted.

Another push for standardized process definitions comes from the Workflow Management Coalition's XML Process Definition Language - XPDL 1.0. From their press announcement

"Together with other WfMC standards, XPDL provides a framework for implementing business process management and workflow engines, and for designing, analyzing, and exchanging business processes."

"XPDL 1.0 uses the popular XML language to describe a business process. A process defined in XPDL (a set of XML statements) can be imported into any workflow engine that supports XPDL. The related objects and attributes (data associated with the process) are now also included in the XPDL process definition. The XPDL process definition can be generated by workflow modeling and simulation tools, or can be manually coded, or can be exported from another XPDL-compliant workflow engine."

Read the article...

This is great stuff and I sure hope the JSR-207 and XPDL groups are talking to each other.

Much of the code that I have written has "died young' or been "stillborn", and unfortunately the same is true for many of my colleagues. There have been many reasons for this (changing technologies, company deaths, etc.) but I believe that in many cases I have been asked to develop software for a poorly thought out business process, or I have developed "tunnel vision" and implemented software that did not really match the desired process.

Perhaps a stronger linkage between the business process definition and source code implementation will produce applications that will live longer. At the very least, it should make it much easier to develop modeling tools that are valuable throughout an application’s lifecycle.

Update: See my later thoughts on BPEJ.

Related Topics >>