Excellent ideas, excellent read!

In this book, Eriksson and Penker (E-P) define UML extensions for describing business processes. Here's a summary of my interpretation of thier ideas:

Processes are generally modeled using UML activity diagrams. A "process" is shown as an Activity stereotyped as <>. The <> activity is also given a new icon and a set of tagged values. I think the icon was added to make buissness developers feel more at home. Instead of a retangle with rounded corners, it looks like a big arrow. Four base types of objects are shown in a process diagram: Goal, Input, Output and Resource objects. "The input objects are resources that are transformed or *consumed* as part of the process..." An input object may become an output object with a state change, but this is not always the case. Sometimes input objects are consumed. E-P say "An output object can be a completely new object created during the processes or it can be a transformed input object". Another quote: "During its execution, the process interacts with other resource objects, objects other than the input and output objects, that are just as vital. These objects carry information required by the process or they are resources responsible for executing the activities in the process, such as people or machines.". Output objects flowing from one process can become input objects or resource objects flowing to another process. Goal objects define a set of rules for controlling the process. A process diagram is drawn with input objects to the left, resource objects below, goal objects above and output objects to the right of each process symbol. Object flows (dashed arrows) are used to connect the objects to the processes. Just as in standard UML, <> Activities can contain sub <> Activities and Activities. Non-process Activities being automic. The State of an object can be shown with standard UML syntax. A description on the use of "swimlanes" in activity diagrams is also given. Classes of objects and their associations are provided by standard class diagrams. E-P also describe the use of sequence diagrams and state diagrams in a business modeling context. They even provide a meta-model for thier Modeling extensions! The book also describes another type of process diagram that they call an "assembly line" diagram. It appears to be a process diagram that utilizes Packages to represent resource collections. I believe that Eriksson and Penker stayed within the UML standard and in fact thier extensions don't appear to be that "extensive". Mostly some stereotyping, some tagged values and an icon. The second half of the book is dedicated to design patterns for busineess development. But many of these patterns could be very usefull to you. They also show how to provide object constraints using OCL and provide a pretty decent UML primer.

One thing that is bothering me about the process diagrams it that they do not show object collaboration very well. I think that the contractual message passing between objects needs to be shown with informational interface objects rather than parameter lists. I'm withholding judgement at this point. After all, the business models they are describing will never be translated into code, but rather business forms and process documentation and executed by people and not computers. They do however, give a method for creating software system models for automating part of the business system.

All mistakes, misconceptions and missuse of terminolgy in the above description of Eriksson and Penker's book are my own.

Adios,
-Andy

Other Reviews

• Not particularly useful
• A very good guide to business-level modelling with UML
• Excellent ideas, excellent read!
• Very high level, often inconsistent