Business processes modelling

[lex_cz]

Hi,
though UML is not the best for modelling of BPM, I need to model some activity diagrams with EA. Now I have following question.
My activity diagrams contain repeating actions like "Button is pushed", "Form is filled out", where the "scenario" remains the same (someone pushes a button, someone filles out some form). The concrete person "pushing" or "filling out" and the concrete button or form changes, ie. "OK button is pushed by an customer", "Invoice form is filled out by manager", etc.

Is it possible to move the abstract processes to external BPM package and then using some sort of templating create the concrete processes in the activity diagram ? Anyone using this or some similar method ?

What about a case where in one activity diagram two buttons are pushed ? Must it be modelled with two processes ?

Regards,
Martin

[thomaskilian]

Hi Martin,
are you sure you talk about BPM and not scenarios of a Use Case? BPM is much more abstract and I can't imagine to include something like "button pushed" in a BP model.

[lex_cz]

Hi Thomas,
OK you are probably right that my example BPMs are too concrete (I am just modelling BP so I used what I have at hand).

Lets suppose in your model those two processes are part of an scenario of an UC. So we have:
1. User pushes button
2. System displays form
3. User fills out the form
...

Let's say I have 30 UCs. The problem here is I cannot find out with ease what everything user does, what everything system does.

OK, so I will model each UC with an activity diagram where each 1 step from UC is 1 action in AD. But this doesn't help because in the end I have like 30 times a process called "User pushes a button", etc.

What I need is to have 1 process called "Someone(operator) pushes a button" where in each AD is "someone" substitued with "User" or whoever. When I have something like this than I can make a simple select on the EA database and see who is involved in "pushing a button", which screens must the system show, etc.

Hope its more clear now
Martin

[thomaskilian]

In my eyes this is simply a Use Case "Push Button" which <<extends>> another Use Case. Create your AD inside that UC and you're done.

[Paolo F Cantoni]

In my eyes this is simply a Use Case "Push Button" which <<extends>> another Use Case. Create your AD inside that UC and you're done.

I agree with you Thomas.  

But doesn't this approach pose the perennial problem of you only get one extend per pair of use cases.  Suppose in the primary UseCase, Actor1 pushes the button and later in the UseCase Actor2 also pushes the button, don't we under current UML 2 have to define only one «extends»?  This would not meet Martin's requirements as I understand them.

Questioningly,
Paolo

[Kevin Brennan]

The use case diagram only shows relationships between use cases, not the flow of events (or to put it more simply, Paolo's right, although this sounds like an <<include>> relationship to me.

[Paolo F Cantoni]

The use case diagram only shows relationships between use cases, not the flow of events (or to put it more simply, Paolo's right, although this sounds like an <<include>> relationship to me.

Yes, Kevin,

It was late in my day, I'm at home with the "dreaded lurghie" (cold or influenza) and I had a slip of the brain - I agree it should have been an «include»!

However, it does beg the question.  In order to achieve Martin's requirements, we do have to work at the Activity level don't we?  Any ideas?

Taking Thomas's advice, and your observation, I might turn the major UseCase into a diagram; place two Partitions (swimlanes) in the diagram, one representing the major UseCase, the other the included UseCase.  Distribute the Activities or Actions between them (as appropriate) and then use the Nesting relationship to formally bind these to the Partition.  You could then trace these with Automation to derive the information that Martin needs wouldn't you?  What do you think?

Paolo

[lex_cz]

Hi,
to move this discussion a little bit forward I decided myself for the following solution.

1. I created a package called "Process base"
2. I created an activity called "Operator pushes a button" in this package. I added a tag called "operator" and a tag called "buttonName" to this activity
3. Now when I want to model in some activity diagram an activity, lets say "Customer clicks on Start" I just drag the "Operator pushes a button" from the "Process base" package into the AD. In the Paste dialog I choose "Paste as Invocation of Activity(Action)". Now I fill in the tags:"operator=customer", "buttonName=Start"
4. So my activity diagrams are now full of "Operator pushes a button", "System displays a screen" just the tag values differ.

In the end I hope I will be able to get from the database the information which screens must be displayed, which buttons must be pressed, by whom, etc.

Regards Martin

[thomaskilian]

The use case diagram only shows relationships between use cases, not the flow of events (or to put it more simply, Paolo's right, although this sounds like an <<include>> relationship to me.

Kevin,
this topic has been discussed in broad here (and elsewhere . Probably I still missed something. If you vote for <<include>> I'd expect that there is a "must press" for the  button. The unlikely event of not pushing anything is impossible with <<include>>. Am I right?

[Kevin Brennan]

As I understand it, «include» can be invoked within an alternate flow.

Here's the definition I have:

Extend: allows for the insertion of additional behavior into a use case. The use case that is being extended must be completely functional in its own right. The extending use case does not need to be complete. Extensions are most often used to encapsulate behavior that may not be present in the initial release of an application—otherwise they may be handled as an alternate flow.

Include: allows for the base use case to make use of functionality present in another use case. The included use case does not need to be a complete use case in its own right. This relationship is most often used when some shared functionality is required by several use cases.

I'm assuming that «include» is more appropriate here because I figure the button provides some sort of functionality within the calling use case, rather than triggering off some optional behaviour.

[thomaskilian]

Kevin,
thanks for clarification It's really a different viewpoint.

[Paolo F Cantoni]

Kevin,
thanks for clarification It's really a different viewpoint.

Well, Thomas, both Kevin and I have the same viewpoint...  

The key thing for me was the "the UseCase being extended must be completely functional in its own right".   Really makes it clearer for me.

Paolo

[Kevin Brennan]

Well...I also want to hear about it if I'm wrong, because that definition is going into the Business Analyst BoK...

[sargasso]

What's this "complete" stuff?

AFAIC any use case must be complete in the sense that once invoked it will complete - either with a success outcome or an alternate outcome.  On my planet use cases must not and cannot "not complete".

Also on my planet, <extending> use cases are optional behaviours that can be invoked in certain circumstances by the primary or other actor that interupt the flow of the extended use case at a specific (or mulitple) point(s) and invoke a continuation of the extended case on completion.

Finally on my planet, <included> use cases are a bunch of confusing elements inserted in the standard by OMG that have nothing to do with extends and have no (forgive my use of the word) rational right to exist.  

If you mean by "complete" that an extending case may not necessarily be directly invocable by a primary actor, then OK. i.f.:
a complete use case is one that can be directly invoked by a primary actor,
an incomplete use case is one that cannot be directly invoked by a primary actor.
However, there is no reason why an extending use case need be incomplete!
IOW, an extending case can be directly invocable by a primary actor in one set of circumstances and indirectly invoked (as an extension) in another.

or have I missed the point?

bruce

[Paolo F Cantoni]

What's this "complete" stuff?

AFAIC any use case must be complete in the sense that once invoked it will complete - either with a success outcome or an alternate outcome.  On my planet use cases must not and cannot "not complete".

Well, bruce, I can't speak for Kevin, but it may be that you have missed the point I was trying to make.  My use of complete is for the purposes that Antoine de St. Exupery indicates in:

“La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever,” or: “perfection is reached not when there is nothing left to add, but when there is nothing left to remove.” - Antoine de St. Exupery, The Little Prince.

That is to say, we can extend a UseCase by adding an alternate path or by directly adding an «extend» UseCase directly as you show below.  If I (or someone else) have previously extended by alternate pathing, then I know I can extract the extending UseCase, because if I do, then I still have a complete UseCase.  If however, I remove some portion of a UseCase and I no longer have a complete UseCase, then I can't call this an extending UseCase, it must be an «include»!  I've found this to be a very useful mechanism for showing others (and myself) how this works.

Also on my planet, <extending> use cases are optional behaviours that can be invoked in certain circumstances by the primary or other actor that interrupt the flow of the extended use case at a specific (or multiple) point(s) and invoke a continuation of the extended case on completion.

I (and I expect Kevin - correct me if I'm wrong) agree with you completely on this!

Finally on my planet, <included> use cases are a bunch of confusing elements inserted in the standard by OMG that have nothing to do with extends and have no (forgive my use of the word) rational right to exist.

Well, I hope from my explanation at the top, you'll agree there is now distinct difference between «extend» and «include».  Normally, I only create «include» relations where I have at lease two using UseCases, otherwise, as you point out, what's the point?

If you mean by "complete" that an extending case may not necessarily be directly invocable by a primary actor, then OK. i.f.:
a complete use case is one that can be directly invoked by a primary actor,
an incomplete use case is one that cannot be directly invoked by a primary actor.
However, there is no reason why an extending use case need be incomplete!
IOW, an extending case can be directly invocable by a primary actor in one set of circumstances and indirectly invoked (as an extension) in another.

I don't think either Kevin or I require that the extending UseCase need be complete or incomplete.  It can be either.  However, it can only be invoked by a primary actor if it is (itself) complete.

or have I missed the point?

bruce

I'll leave that up to you...

Cheerz,
Paolo