Business process model example

[JEff Russell]

If interested, please comment on the following attempt at modeling a business process. This (mostly) academic exercise closely resembles a real-life business process...

My goal is to construct an analysis model for a computer-aided design tool for embedded systems, specifically to assist during a system-level design phase. To set the context, I modeled a design flow that would be used by an engineering organization. Of course, this process exists in a company-wide product lifecycle model.  A key aspect is that the Product Lifecycle diagram both intersects and hierarchically represents a portion of the Codesign Flow diagram.

The diagrams are shown below (if I figured out the YABB buttons).  My discussion points are:
1. Any general advice from you experienced UMLers.
2. Some of the (same) discrete processes show up in both diagrams, but the connecting flows differ. Any problems with this?  (E.g. In the Product Lifecycle diagram, "Describe Product Concept" flows through a decision before reaching "Analyze System Requirements"; while in "Codesign Flow" the two diagram elements are directly connected.
3. In the Product Lifelcyce diagram, the "Development" entity hierarchically represents the rest of the Codesign Flow diagram (elements "System-Level" design through the end).
I'm sure this breaks UML semantics... but this is a real-life process.
4. Let's say I want to define the Codesign Flow element "System-Level Design". Is is right/wrong to explode this into its own flow of processes?  For example, I want to show about 3-4 sub-processes, with iteration, that define this System-Level Design activity, maybe even with an activity diagram...   What would I start and end this diagram with? Events? And how would those events tie back into higher level diagrams?

Thanks for indulging such a long discussion-starter, and feedback on appropriateness of using pictures is welcome, too.
JEff Russell

The Product Lifecycle diagram:

(Also at: http://www.ece.utexas.edu/~jrussell/product_lifecycle.gif
The Codesign Flow from the engineering point of view:

(Also at: http://www.ece.utexas.edu/~jrussell/codesign_flow.gif

[PhilR]

Hi Jeff,

I have a few constructive comments that may help.

First thing - great idea to use diagram to illustrate your points.  UML is all about "visual" modelling.  Right?

Also, remember that the diagrams you are using are Activity Diagrams with a "stereotype" symbol for an activity to highlight the fact that we are modelling business activities rather than the activity flow of a class operation etc.

This means that the diagram should obey the rules of activity diagrams.  One of the clearest descriptions of Activity Diagrams I have ever come across is at (shock horror)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dniuml/html/rep
resentationofactivities.asp

Another (less surprisingly) is at

http://www.therationaledge.com/content/jan_02/t_activityDiagrams_me.html

As for your points:

1) The branch symbol (diamond) should be associated with "Guard Conditions" on the dependencies flowing out of the branch.  A branch can be regarded as an "xor" and is optional.  Be certain that you are not trying to show concurrency, which uses the "Fork/Join" notation.

The dashed line on an Activity Diagram indicates object flow.  If you want to show an Actor "executing" an Activity it might be better to use swimlanes.  Alternatively you can stereotype a Dependency (or Association?) as <<executes>> and use this to associate Actors and Activities.

2) No problems that I am aware of.

3) The UML has a stereotype icon for an Activity that can be "decomposed".  EA does not support it.  See UML 1.4.

4) Don't get me started on activity decomposition   Functional decomposition of *software* is bad, bad, bad and one of the major drivers behind the switch to OO techniques.  Why is it bad?  Because software designs based on *functional* decomposition are hard to reuse and change.

This fact has led some people to think that all types of decomposition are bad.  Try convincing systems engineers that this is true!  The UML allow the decomposition of Activities but sort of hides it due to an awkward embarrassment about decomposition in general.

Hope this helps Jeff and I welcome any corrections from others if I got it wrong.

PhilR

[JEff Russell]

Phil,
Thanks for the comments.

Here's some points on your points:

1.) I was cheating with the branch symbol: trying to show a decision to continue or quit, implying parallel courses were taken when continuing (there should be a fork/join symbol).  The problem is, this would scare most non-technical types.  
[Side bar:] My most recent experience was a company with executives/non-engineering management that documented the company's processes with PowerPoint.  The level of rigor was limited by the "autoshapes" and the page size :-(  I got snickered out more than one meeting for being too concerned with details, and I would hessitate to show a "real" UML diagram to such a crowd.  My point being...?  [end of side bar]

Does anyone "dumb" down UML diagrams for non-technical types, thereby breaking UML rules?  Or would it be best to try and teach notational concepts like fork/join and guard conditions?  

4.) I see your point on functional decomposition for software.  However, these diagrams attempt to model real-life business processes (that will not necessarily become software). I've heard of business consultants using UML to diagram business flows. Shirley, they must use functional decomposition.

JEff

[PhilR]

JEff,

Points on points, on points...

1. Take your point but if one wants to be pedantic a branch (xor) without guard consditions is meaningless cos you can't take all branches of an exclusive or.

Universal question - how do we communicate precisely with business users?  I don't have the answer but here are some things I've found.

a) Don't explain too much.  Just start using fork/join.  If you use it consistently people get the idea.  If someone asks "what's that?".  Don't offer too much explanation.  Don't call it a "uml-fork-join-concurrent-widget-a-bob".  Just say it means that all of the activities to the left must be complete before this one can start.

b) Cut slack to the bsuiness people while you work with them but build rigour into the models behiond the scenes.

c) Accept that very often rigour is simply not necessary.  This is particularly true if we are modelling business processes as a precursor to defining software requirements.

d) Try to build an understanding of the importance of standards by analogy.  Is it really important to follow Accounting Standards?  Is it really important to adopt best practice HR standards?  Do we really need to have ISO9000?  (Be careful onm the last one they might say no )

Finally "dumb down" the UML by all means but either stick to the vanilla standard or develop a UML Profile that allows you to do what you want.

4) What I was saying in a round-about way was decomposition for buisness activities is quite OK and I would say essential.  Decomposition is only bad as a software design approach.

Hope this helps,
PhilR

[georgesd]

I have a similar problem that is solved in most non UML modelling tools.
The question of using a 'bar' for junction exclude the use of Boolean junction, and this affect most of the junctions.
Instead of writning the whole boolean equation on top of the bar (I.E. a and b  or d)
I used the symbol Sync with as name the Boolean variable AND, OR or XOR
I also wrote to OMG but never got an answer.
UML is wide open in some interpretation and this is one case.
For the rest I used as an entry point the diagram as recommended by EA and it does the job liaising data, goals and processes.
I also use 'Packages' in a hoerarchichal pattern.

[angel-o-sphere]

Hi,

in 95% of my activity diagrams I use either fork/join elements or *nothing*.

The later means I just use several outgoing flows from an activity and place guard conditions on them.

Decissions I only use for diagrams which model algorithsms where I want to translate the decission later into an "if" or "swich" or any kind of loop.

The reason is: as long as you are modelling on the business or requirements level you have likely not much understanding about what you want to model or not all relevant informatinos or the audience is in that situation.

Thus you will change your models very often and its far easyer to just connect activities to activities and place guard conditions instead of continiously adding and removing decisions.

I use descisions as "emphesizers" to show important points ... and very often if something is that important a join/fork is even clearer.

Regards,
  angel'o'sphere

[carlclarke]

Business 'viewers' of your models should be very interested in the Fork/Join symbol especially as a Join often represents a 'wait-state' in the business activity such as synchronising payment and availability of goods prior to dispatch. At the very least it is important to highlight the fact that the process cannot progress until the synchronisation is complete. Some businesses may want to look at optimising this wait-state.

The importance of (business) Decision symbols should be fairly obvious to the viewer too.

So thumbs up to Forks/Joins