Use Cases - Prmary Actor (Multiples?)

[bioform]

I have a question about associations between actors and use cases...

Most use cases will be modeled with a primary actor:
e.g., Actor_1 <<use>> UC_A

A usecase that has a generalization relationship:
e.g., Actor_1 <<use>> UC_A <<generalization>> UC_A1, UC_A2
These usecases that are specific forms of the general form, if they do not have a <<use>> realtionship with an actor, then their primary actor can be derived to be Actor_1

A usecase that has an extend relationship, if it is in fact a stand-alone use case would by definition have it's own primary actor...

My problem is with modeling a usecase that has an include relationship with two or more use cases... If it is modeled as an include, then would you NOT identify a primary actor?

I'm trying to understand how I could test the completeness of a model... e.g., All use cases have a single primary actor, or the single primary actor can be derived...

Would/Should I treat "includes" as exceptions to this rule, or should they be modeled with a primary actor (if so which one would serve as the primary?)

This is NOT a major issue, but I am working on integrating MS Word with EA data (via SQL) for documentation generation, and I am trying to understand/develop a style that is consistant an logical...

Thanks for the comments ahead of time!

[jeshaw2]

I hope I understand your question correctly.  

I would think that the primary actor for an included or extending use case would be the base use case itself since it is the base use case that initiates actions within the included or extending use cases.

[«Midnight»]

Or, depending on how you want to define things, the primary actor of the 'extended' case would also be the primary actor for the 'extension' use case. This would perhaps be even more likely in the case of «include» relationships. In most cases, the actor invoking 'outer' use case is also the root cause of the 'inner' ones being invoked.

[bioform]

Yes, I agree...

Usually I find that an extend UC, would function as a stand-alone UC, so it WOULD have it's own primary actor (1:1), same with a generalization UC (1:1).

But an include UC, seems like by definition it is NOT a stand-alone UC, but "serves" more than one stand-alone UC, so if I derived the actor it would be a 1:Many, thus negating the concept of a "primary actor".

Of course if the include UC serviced UCs that all shared the same actor, it would be no problem...

It's when the serviced UCs have different primary actors that I have a problem...

Is the "fix" for a UC model validation process, to have a "Primary" actor, and then "Supporting" actor? I don't really like that approach since it seems rather arbitrary as to which actor would be considered primary...

The reason I am asking this, is I want to be able to "validate" some UML models that will be delivered to us for "completness" from our modeling POV.

I'm beginging to believe that a UC that does NOT have a primary actor identified, but has an "include" relationship to more than UC (and where their primary actors are different) will not have a primary actor identified. Again this is JUST from a validation/style checking point-of-view...

[«Midnight»]

Think of the «include» use case as a subroutine. While it is true that the 'calling' use case directly invoked the 'subroutine,' the whole process - outer and inner process combined - was started by, and for the benefit of, the actor that invoked the 'calling' use case.

An «include» relationship has another parallel with a subroutine. It contains common 'code' that several different use cases can invoke.

If there were only a single use case that invoked this common (included) behavior you could simply model the whole package as a single use case. If you were to do this there would only be a single primary actor, the actor that invokes the entire package. So far so good, and fairly self-explanatory.

The above thought experiment can be carried out for each use case that invokes the common behavior. In each case the included behavior is providing benefit to the primary actor of the 'including' use case.

Another way of looking at this, is that there is no particular rule that says there must be a primary actor defined for each use case, no matter how the use case fits into the model. You don't have to go out of your way to specifically association an actor with a use case that simply provides common behavior.

[bioform]

After reading everyone’s comments and doing some more thinking, I believe the following "logic" (implemented via SQL queries) will meet my needs...

A delivered UC Model will be evaluated by a series of checkpoints, that I can answer by querying the model via SQL… Here is the check point for the “Primary Actor” assignment,,,
========================================
Checkpoint: Does Each Use Case Have a Primary Actor Assigned?

Test 1) Does the UC have a direct association with an actor?
Yes: Good we are done...  No: Continue to test 2)

Test 2) Can the UC primary actor be derived from the model?
Yes: Good we are done...
    - Generalization = derive from parent

No: continue to test 3)

Test 3) Does the UC service an include relationship to ANY UC?

Yes: Good we are done... (Derive primary actor IF all serviced UC's share the same actor...)

No: PROBLEM - orphaned UC
========================================
Once again THANKS to everyone for taking the time to discuss this!

[jeshaw2]

Use case inclusion is a form of composition.  Logically, the included use case is merged into the base (including) use case resulting in only one composite use case.  While one my speak of a primary actor for a concrete (complete in contrast to a fragmentary) use case in a stand-alone context, one my not do so in an inclusion context.

Therefore, there is no actor to be derived for an included use case as it has lost its identity and individuality.  The primary actor is initiating the composite use case and not the base nor included use cases.

[bioform]

Jim,

I rarely have used the "include" association between use cases in the past. I understand that the include means the UC's interaction with the system will ALWAYS occur as part of the "calling" UC, but how should the included UC be modeled?

Since each UC should model a complete interaction with the system, thus achieving the actor's goal, it would seem that you COULD assign an actor to the included UC, and then the "calling" UC is assuming the "Role" of the included UC for the duration of that interaction, then reverting back to the calling UC's actor's role?

Example:
Actor1 = Loan Officer, Actor2 = Account Clerk
UCA: Review Loan Application <= Load Officer
UCB: Check Outstanding Account Balance <= Account Clerk

UCA <includes> UCB

If this approach is taken, then UCB should in fact have a priamry actor assigned.

And if this is the case, then my "validation" check should be modified to ensure that a primary actor is assigned to EACH UC (with the exception of generalizations, that if they do NOT have a primary actor associated directly, that I would derive it from the base UC?

[«Midnight»]

Another way of looking at your example is:
Loan Officer is the Primary Actor for UCA.
Account Clerk is a Secondary Actor for UCA, and becomes involved in response to UCB being invoked.

[jeshaw2]

I agree with Midnight;  Loan Officer is the Primary Actor, Account Clerk is a Secondary Actor.

Do not expect to convey much information with a UML use case diagram.  The available semantics in such a diagram are not rich enough to stand alone.  The real story is conveyed in a text based model called a  Use Case Description.

I understand that the include means the UC's interaction with the system will ALWAYS occur as part of the "calling" UC, but how should the included UC be modeled?

 You draw the base and included use cases as a pair ellipses connected with an <<Include>> relation as usual.  However, an including use case does not "call" the included use case.  Instead, the text for the included use case [UC-B] is merged with the text of the base use case [UC-A] forming a new, third use case [UC-C].  The text for the included use case appears as either, or both, Alternative Flows or Named Sub-flows in the new use case [UC-C], merged with the Alternative Flows and Sub-flows from [UC-A].  The composition of [UC-C] is occuring at design time, not compile- or run-time.

Since each UC should model a complete interaction with the system, thus achieving the actor's goal, it would seem that you COULD assign an actor to the included UC, and then the "calling" UC is assuming the "Role" of the included UC for the duration of that interaction, then reverting back to the calling UC's actor's role?

Definately not!  You may speak of a primary actor for each of the three use cases [UC-A, UC-B, and UC-C], but you may not speak of two primary actors for [UC-C].  You must understand that [UC-A] is one use case, and [UC-A] plus [UC-B] is not another variant of [UC-A]...it is [UC-C]...a third distinct use case.  

Does this help?

[«Midnight»]

Some more thoughts on this.

Jim is correct of course...

In particular, I ran roughshod over the real situation with my subroutine analogy, in particular by using the metaphor of "calling" an included use case. This was meant purely for illustration of the relative positioning of included use cases, and not as a description of the actual mechanism.

When we talk about a use case modeling a "complete" interaction with a system, there are necessary scope issues here. Depending on your point of view, the Check Outstanding Balance use case may be a "complete" interaction - from the Account Clerk's point of view - or simply a necessary step - to the Loan Officer performing the  Review Loan Application use case.

It is easy to just paste all kinds of use cases onto a diagram, tie them together with links to actors and each other, and then try to infer some kind of system-wide meaning from the results. What's more difficult - and often more valuable in the long run - is to get several perspectives, each at an appropriate level of detail, point of view, or with a specific scope. There are some pretty good works on this, so it might be time to visit your local book store.

In particular, remember that use cases somewhat predate UML. This is a contributing factor to their semantic 'looseness' (for lack of a better word). To balance that weakness, use cases - the "text based model" portion Jim refers to - can have value and convey meaning without having to build other supporting model artifacts. Use cases can be entirely textual, and can often convey sufficient meaning to clients (in whatever sense of the word you might want to use) where a formal model would not.

David

[bioform]

I'm not usre if I agree with these comments. I have based most of my use case modeling on the series by the 3 amigos. Specifically: Managing Software Requirements, A Use Case approach, Succeeding with Use Cases, and Advanced Use Case Modeling...

I use activity diagrams and robustness diagrams to document the interactions in the use case to disambiguate "text", this in combination with a RAD approach (ICONIX), seems to work pretty well.

I believe if the use case is NOT clear, concise, and meaningful it does not serve it's purpose of presenting the requirements (developed through goal based functional decomposition) in a coherent manner that preserves the business context of the use case.

I have been trying to document the parts of a use case (Cockburn) that we include in our models, using the existing attributes of a UC as implemented in EA or extended using tagged values on a UC stereotype.

For example:

Tag: Goal, Risk, Priority, Frequency, etc.

Constraints: Pre-conditions & Post-conditions, also Minimal & Success Guarantees (Process)

Scenarios for Basic Path, Alternate Path(s), and Exception(s), programmatically derive the script for the basic path and alternate paths from associated activity diagram...

Stakeholder Needs: Actors trace to instances of a "Need" class, which trace to the UC (allowing the specific need to be shared across UCs)

Traces from the UC to business objects (domain model), and Logical UI that are used to capture the requirements for the UI that will support the interaction described in the UC. These logical UIs are NOT a implementation (there is no graphical detail in the object, it serves as the container for capturing the responsibilities of a UI, thus delivering the specification that will be designed too.. Additionally, this allows the developers to not have to wade through requirements to the find specifications for the functionality that the UI must provide to support the UC.

I believe writing UC, rather that modeling them in this way leads to a significant burden on keeping them in synch throughout the systems lifespan. As we are using EA's test integration with UCs (and other objects) AND have a robust trace to realizations, this means we can provide impact analysis that will present both a scope report on a change at both the implementation level, but also at the functional level.

Additionally we are "developing" an approach using the "Change" object to be used with our Change Control Board (CCB) process for proposing changes to the baseline. This allows us, using the hierarchy view to "see" what CCB items affected a specific UC.

I do not believe documenting these things as "text" within a UC without a tool that can imbed dynamic references (which EA cannot currently provide) is practical.

[bioform]

I forgot to add to that last paragraph... "... over the lifespan of a system." If the use case model is NOT to serve as an active part of the development and maintenance life cycle, then this degree of modeling detail would not provide the same benefit.

[bioform]

Currently I am completing work on a prototype for an EA addin that takes this information captured in the uscase modele, and extracts it into a text format that is similar to Cockburns "Fully Dressed" UC.

We also make use of his idea of UC precision levels. Based on the metric values capture during analysis (see.. Succeeding with Use Cases, by Richard Denney) and the realtionships that exist between a UC and other objects in the model, we can derive an estimate of the precision level needed for the documentation of the use case.

This we can concentrate our efforts on those UCs that have the greatest risk/benefit to the current release of the project... This same analysis can be used to target testing depth and resource allocation.

[jeshaw2]

I too, have cut my teeth on those early texts, but I have learned much since their publication.

A more current text might be Use Case Modeling, by Bittner & Spence, Addison-Wesley, 2003.  ISBN 0-201-70913-9

It is blessed with a forward by Ivar Jacobson and carries the logo of Booch, Jacobson, and Rumbaugh.  Kurt Bittner is Director for Requirements Management Solutions at Rational Software and Spence, a senior consultant at Rational, specializes in the adoption of RUP and the use case driven approach that it recommends.

This text is better aligned with the current Use Case state-of-art.  It also forms the basis of some Use Case Writing tools which are currently under development.  These tools, when developed, make the management of included and extending use cases much easier and will produce the benefits you seek.

But, you are the one with a mandate to successfully deliver a product.  Go with what you think best.