John Reynolds's Blog

UML and Process Definition for Java - JSR 207

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

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.

Comments

• embedding modeling information into your code
  We embed java doc, and inline comments in applications today. Soon we will be embedding metadata and we already embed xml config files in our applications.

  Embedding model information into an application should not be a stretch.

  Pictures and words are a powerful combination. It is how children learn to read and a very effective communication mechanism.

  Application teams use models differently:

  a. Cave drawings (white board)
  b. Art ( slides shows)
  c. Blueprints ( UML diagrams )
  d. Cookie Cutter (Model Driven Development)
  e. Alchemy (Model Driven Architecture)

  If you imagine that the embedded models will be a reversed engineered UML version of the code -- I suggest visiting http://www.omg.org/mda and read up on the MDA open standards.

  It would also be redundant.

  The embedded model will be a level of abstraction higher than a source code model but remain reflective of the platform.
  

  Posted by: witkop on November 20, 2003 at 05:40 PM

• Productivity on software development
  Dear John,

  I have been following the ceaseless struggle of the technologie companies in search of productivity on software development, especially in J2EE.
  I agree that exists a big gap betwenn a minority that look for the creation of artefacts/tools in order to minimize the codification time and the great majority of developers that barely know the language sintax, and these are the ones that get their hands dirty on building the software. I've been accompanying some development teams, where a long and tiresome labor is necessary to introduce the knowledge which will help them to use less than 40% of their IDE. I found in some cases that the only object that is missing is the support material for the developer (something like a kit). I believe that the arise of such tools will be, for a long time, tools for "Architects". Meanwhile, the companies are worried on how to eliminate the developers.

  Posted by: mayworm on January 27, 2004 at 12:10 PM

• Productivity on software development
  I don't see POA so much as a productivity ploy to get rid of developers, more like a new paradigm that could help us build better software.

  I was a relatively early adopter of OO (C++ in 1989), and rather then a productivity booster, I found it to be an awareness booster. My OO designs were simply heads-and-shoulders better then my structured designs.

  I think that Process Oriented Architectures are going to provide the same sort of sea-change. The "problem" with OO modeling to be addressed is that there is not a direct link between the code composition and the requirements for which the model was generated. The class diagrams are king, and everything else is just documentation.

  With POA, the requirements are clear, and the linkage is direct. Add to that the underpinnings of Pi Calculus and there is a chance that this will be as significant as the advent of the RDBMS (which I think was 1970 or so).

  Then again, it could just be wishful thinkinking on my part ;-)

  Posted by: johnreynolds on January 27, 2004 at 03:34 PM

This work is licensed under a Creative Commons License.