Cascading use cases?

[miksko]

This is the situaton:

• A human actor perform the first use case, which creates a document.
• The creation triggers a second use case, with the system as the actor. The final step in that use case is to change the state of that document.
  

How would you model the dependency between the two use cases in UML?
How would you connect the use case model to the state model of the document?

[Richard Freggi]

You would not model it.  What you describe (a hierarchy of use cases) is not UML. 

Use cases are not meant for functional decomposition (google it or also 'structured analysis'). 

The closes thing would be <<include>> or <<use>> association stereotypes, but they are not meant for functional decomposition.

Sorry for the bad news.

[wivel]

Hi there

A use case has to bee seen as a step of processes, performed by the primary actor, to provide the actor with something of value.

In you case, it is not clear if the primary actor waits for the result from the system, or the system works async after the actor has finished, so to speak. Can you provide more details?

Also Richard is right here. Do not use use cases for functional decomposition. Use Cases are function requirements in a context, whereas function decomposition is part of the technical analysis/design discipline.

Henrik

[qwerty]

I always recommend reading Bittner/Spence about use case synthesis. Looks like more than 90% of all teaching does not do a good job which is why most people start with functional decomposition rather than synthesizing use cases (which is pointing out the added value for actors of the system under consideration).

q.

[Geert Bellekens]

What you want to do is loosely couple the use cases using post- and pre-conditions.

UC1 postcondition: Document X created
UC2 precondition: Document X created

Now it doesn't matter anymore whether UC1, UCX, or a non existing use case creates document X. Regardless of who or what creates Document X, if it's not created UC2 cannot be executed.

Geert

[wivel]

I always recommend reading Bittner/Spence about use case synthesis. Looks like more than 90% of all teaching does not do a good job which is why most people start with functional decomposition rather than synthesizing use cases (which is pointing out the added value for actors of the system under consideration).

q.

I can recommend 'Writing effective Use Cases' by Cockburn. Or my old course in writing Use Cases, which is based on Cockburns book  .

Henrik

[Richard Freggi]

I always recommend reading Bittner/Spence about use case synthesis. Looks like more than 90% of all teaching does not do a good job which is why most people start with functional decomposition rather than synthesizing use cases (which is pointing out the added value for actors of the system under consideration).

q.

qwerty is right on the money.  During my Master degree classes the teacher could not explain what to do with use cases, we focused mostly on class diagrams.  Use cases were a kind of oddity for me until I read Bittner/Spence and it changed my whole approach to modeling.  Applying use cases too by Schneider / Winters recommended as second reading!

[miksko]

Thanks for all the feedback!
My personal opinion is that use cases should only display the initial actor, which would be the human in this case. The fact that the system will take over at some point is lingering all through the use case flow, since the purpose of it is to describe the user's interaction with the system. But if you want to point out the handover, it would be by putting the second part in a separate use case, include it and use pre-conditions. Or you could display it by adding a UML sequence diagram (which would be a novel but odd way). Or your architect would describe it by adding diagrams for use case realisation (but with only one architect in a SAFe release train, that won't happen).

So, I agree with you all.
My reason for asking is that I have two colleagues who are of a different opinion and who stretches UML. I needed an external opinion.

PS to Wivel: In the second use case the "actor" is a listener which waits for a certain message/document to be created.

[qwerty]

A use case does not display an actor. It displays added value (linked to its actor). You and your colleagues need to step back since your next step will let you fall down the canyon. Unless you throw away your thought above you can only fail.

q.

[Richard Freggi]

Thanks for all the feedback!
My personal opinion is that use cases should only display the initial actor, which would be the human in this case. The fact that the system will take over at some point is lingering all through the use case flow, since the purpose of it is to describe the user's interaction with the system. But if you want to point out the handover, it would be by putting the second part in a separate use case, include it and use pre-conditions. Or you could display it by adding a UML sequence diagram (which would be a novel but odd way). Or your architect would describe it by adding diagrams for use case realisation (but with only one architect in a SAFe release train, that won't happen).

So, I agree with you all.
My reason for asking is that I have two colleagues who are of a different opinion and who stretches UML. I needed an external opinion.

PS to Wivel: In the second use case the "actor" is a listener which waits for a certain message/document to be created.

I understand your situation and I've been in similar cases.  This is why standards exist.  It's not your opinion or my opinion - just do what the standard says.  The books above mentioned give you the deep understanding to model well, but as an aid in "just doing what the standard says", get a copy of "The Unified Modeling Language Reference Manual" (Addison Wesley), look up the topic and in 5 minutes you know what you need to do.

[miksko]

Thanks for the book title.

Mikael