Workflow modelling

[Franky Cheung]

Dear all

We can use Activity Diagrams to model the workflow/steps involved in a Use Case. What about if those Use Cases themselves form a workflow of certain process, how can we model that, by use of which diagram or methodology?

Thanks a lot.
Cheers/Franky

[Edwin Dalorzo]

Welcome to Java Ranch, Franky.

A use case represent an interaction between an actor, most typically a user, and the system. Commonly this interaction produces some value to the user.

Since A use case may involve multiple scenarios therefore multiple activies are carried out during the flow of events of a use case. Depending of the particular execution of the flow of events the use case brings many different scenarios to life.

This set of activities can be well represented, sometimes, using an activity diagrams. There are occasions in which the use case may involve so many scenarios that it could be necessary to use multiple activity diagrams to explain the use case.

Now, it is a common mistake to create one use cases per every single step of a business flow. Some people even uses the include and extend relationships to depict in a diagram all the steps of such a business flow. But that wouldn't be correct.

Now, could you please explain a little better when you say that the use cases are part of a work flow, because it should be all the way round. That is to say, the work flow (which represents a particular scenario) is part of a use case.
[ July 19, 2006: Message edited by: Edwin Dalorzo ]

[Franky Cheung]

Hi Edwin,

Thanks for the explanation.

I agreed that we cannot create use cases for every single steps of a business flow. When there are two use cases, each of them would consists of a set of event flows which describe its activity.

I am thinking of how to model the sequence of these two use cases. Let me give an example. I have two use cases: "Maintain the account balance" and "Print Balance Report". Each of them would has a activity diagram depicting its events flow. But I want to emphasize that each actor should maintain its account balance before printing the report. What (diagram/method) should I use in that situation? (or simply state the post- or pre-condition in the Use Case narrative?)

Thanks/Franky

[Edwin Dalorzo]

Well, Franky

According to you, the client can only print its account balance until the other use case has happened.

In what cases it is possible to Print the Balance Report without Maintain Account Balance?

If you tell me that this is never possible, then the use case Print Balance Report should have never existed. This would be just another step in the Maintain Account Balance use case.

In a case like this, the only way you could justify the existence of the Print Balance Report use case would be that this printing behavior is also performed in other use cases, and therefore you could refactor this behavior in an independent use case that you could include in another use cases.

In other words, if the Print Balance Report use case cannot be performed independently of the other use case, there should be an include relationship between this and the other use case, if and only if, this printing behaviour is shared by another use cases, otherwise, you are better of without it and simply specify the printing behaviour as a sub flow within the Maintain Account Balance use case.

Another option could be that you assume that the account is maintained until the report is printed. Then you can put that in the preconditions. But this conditions are never validated, you assume they are true.

Then, if the use case should enforce the rule that the account cannot be maintained until the report is printed, then the Print Account Balance use case could be actually an alternative flow of the Maintain Account Balance use case.

In this last case you can have an extension point in the Main Flow of the Maintain Account Balance use case and you specify in the alternative flows what wold happen if the balance report is not printed.

In the diagram this could be depicted as an extension use case, if the complexity of the alternative flow is big enough to justify the existence of the extension use case.

What do you think, Franky?
[ July 21, 2006: Message edited by: Edwin Dalorzo ]

[Franky Cheung]

Thanks Edwin,

I got a much clearer mind now. Based on our discussion, the turning key is on the levels of abstraction when describing the use cases or scenarios.

It is better for us to fit a procedure into a basic flows or alternative flows if it cannot be justified as large as a use case. If such flows are "big" enough or shared by other use cases, you can consider to form a separate use case and think about the use of "extend" or "include" relationship between them.

One more question:
Is "include" relationship apply on those events mentioned in basic flows where "extend" relationhip apply on alternative flows ?

Thanks/Franky

[Edwin Dalorzo]

Well, Franky, I believe the most important reason to use an include relationship is because you feel you may refactor some use case behaviour that is common to various other use cases.

It is very typical that the include use case cannot exist by its own, in other words, it is always included from other use cases, and never by direct interaction with any actor (although this is not necessarily prohibitive). The flow described in the in the included use case is always include as part of the flow of the main use case. That is why the include relationship is a dependency between the main use case and the included use case.

Nevertheless, there are cases when you may find useful to refactor some flow although it is not necessarily reused by other use cases. Maybe it is just reused by the same use case, or maybe it helps the reading and understanding of the use case itself.

In such cases it is a better idea to create a section named Sub Flows in the use case specification itself where you can refactor common or specific behaviour within the same use case. In the place where this behaviour should be placed simply put the words: Perform "The Name of the Sub Flow"..

Whatever the case, the sub flows and included use cases are always executed as part of the main flow. It can be said then, any scenario instantiating the main use case will perform the included use case.

On the other hand, the main use case do not depend on the extended use case. As matter of fact, the main use case must be completely unaware of its existence. If the extended use case is removed, the main use case must continue to be valid.

In this regard, these kind of use cases are used to add new behaviour to an application or simply to offer the possibility to perform additional flows of execution based on certain conditions.

It is said the an extended use case is always performed at an extension point within the main use case when a condition happens.

For example, in the "Order Item" use case, when the stock of certain item is under the stock reorder limit, the extended use case "Reorder Item" should be performed.

In this case the extended use case is executed depending on a condition that will happen at the extension point in the main use case.

Therefore we can say that the extended use case depends on the main use case, that is why the relationship is a depency between the extended use case to the main use case.

Now, when we use an extended use case, the main use case is complete by itself. In other words it can be performed without the existence of the extended use case. It is a common mistake to use extended use case to depict all alternative behaviours within the main use case.

However, if your use case have a lot of alternative behavior (if-then-else) that do not justifies the existence of an extended use case, then simply write them in sub flows if you consider they shadow the use case's business flow.

And use alternative flows to describe what happens at the extension points.

This is hard to explain in a brief forum answer. I indeed recommend you to read the following books:

Use Case Modeling
Use Cases Patterns and Blueprints

Good luck, comrade!
[ July 25, 2006: Message edited by: Edwin Dalorzo ]