Internal Use Cases

[ScottUML]

I'm trying to document an existing system which has no documentation whatsoever.  I have a few questions about the process I'm considering.

I imported all my existing java code into a Logical Model, which is under the umbrella of a Design Model.

Now, I am creating Use Cases for each use case that I can identify from the user perspective.  When I realize these use cases, I want to break these up into sub-use cases, that don't have any interaction with an external actor.  Is it valid to make an actor of another use case?

So my structure so far is that I have a Use Case Model and a Design Model.  The Design Model as three major divisions: Use Case Realizations, Logical Model (where the class diagrams live), and a Data Model.

First, does this breakdown sound about right so far?  And mostly, I am asking about traceability.  I would like to start with any high-level use case until I'm at the source code.  How do some of you experienced architects handle this?  I was thinking that I could go from use-case to use-case until I'm in the general area, then drill down to the realizations, leading me to the code.  Is that right, or do I need to stick with only user-interaction use cases and use other kinds of models or constructs to drill down with?

Thanks

[Geert Bellekens]

Scott,

Your "Internal use cases" are generally know as "secondary use cases".
Secondary use cases are generally created to isolate common functionality executed by multiple primary use cases.
The secondary use cases are then generally included by (or they extend) the primary use cases.
More then often secondary use cases don't have a primary actor, as they are only executed by other use cases, but they might still have secondary actors.

In any case, use cases are no actors (as by definition an actor is external to the system, and a use case is internal).

Just a word of warning, don't go too far into breaking up your use cases into "sub-use cases". This "antipattern" is know as functional decomposition, and it will make your use case model a mess.

Geert

[ScottUML]

Geert,

Thanks for the information.  Secondary Use Cases it is then.  That's what I was looking for, the proper terminology and validation that the idea is sanctioned as part of the process.

I will be careful.  There are major processes in our system that can be called from a variety of different flows that fit neatly into the concept of a secondary use case.

Thanks again,

Scott

[deefer]

Hi

during these days I was reading at this
http://www8.cs.umu.se/~jubo/Papers/INCOSE06a.pdf
and also this
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.65.1491&rep=rep1&type=pdf

Maybe it will help you, I've found it very useful for use cases and functional analysis

Davide

[ScottUML]

Thanks, Deefer for the links.  They've given me a lot to think about.

[PaulH]

The other book I find useful these days is Jacobson's "Aspect Orientated Software Development with Use Cases"

This can simplify both the primary and secondard use cases