Use Case Include & Extend: Revisited

[jeshaw2]

Two questions if I may,

Question # 1
When a base use case "A" includes, or is extended by use case "B", the logical merging of the behavior specifications takes place at the level of the Basic Flow, Alternative Flows, and/or the Named Sub-flows (and possibly others).  In the Alternative and Named Sub-flows, each behavior fragment has a name.  (Obviously, I'm in the context of a textual use case specification and not a UML Diagram

It is possible that specifications for both use cases A and B end up with behavior fragments having the same name but different behavior specifications.  Note:  I'm not saying that this is correct or incorrect at this point, only that my use case writing tool (MS Notepad  )allows this to happen.

My question is: Within the Alternative Flows and/or Named-Sub-flows sections, how does one interpret the behavior fragment specification in the face of behavior specifications having the same name?  

• Is this invalid?
• Are the two merged in some way?  If so, how is that done?
• Do the included or extension fragments redefine the base specification?
• Do I get to choose by providing a specialization of the <<include>> and <<extend>> relations that determines how to interpret the merge?
  

From comments in the UML 2 Superstructure, they (the OMG/UML committee) plan to remain silent on this issue.

Question # 2
Logically, <<include>> and <<extend>> are relations between use case specifications.  They are not run-time relations between use case objects (scenarios) or "Emergent behaviors" as the UML Superstructure refers to them.

Has anyone thought about or used (perhaps a guarded) <<inject>> type relation to specify a run-time use case extension?  

This may be helpful in Aspect Oriented or Dependency Injection ontologies.  I would argue against a run-time specialization of the <<include>>; that would really invite the functional decomposition bad guy.  Jacobson mused about this in a recient paper of his.

Are there any best practices on this?  (This is not a third question; it <<extends>> questions #s 1 and 2 above. )

[thomaskilian]

Hi Jim,
regarding #1: if you say it's invalid, then most of your questions will be answered. So I'd apply Occam (or Ockham) and cut it off.

#2: honestly I did not know about an <<inject>> relation. So I'm clueless here.

[jeshaw2]

Hi Jim,
regarding #1: if you say it's invalid, then most of your questions will be answered. So I'd apply Occam (or Ockham) and cut it off.

#2: honestly I did not know about an <<inject>> relation. So I'm clueless here.

Re #1: I'd prefer either or both of the last two options, but I'd like to hear pros and cons if any are known.

Re #2:  <<inject>> is my invention; just wondering what the folks here thought of it?

[jeshaw2]

I've made some progress on my #1 question.

First some background information.  It was initially argued that extension points belonged to the extending use case for that was the use case that needed them.  Rumbaugh, arguing from the basis of encapsulation, won the point that extension points belonged to the extended use case because the extending use case should not have any internal knowledge of the extended use case!  I would also argue that the extended use case should not have any knowledge of the extending use case's internals.  The same would apply between a base and included use cases.

So back to my situation in #1.  I think Thomas was very close in his comments, but it isn't that duplicates are invalid, they are impossible!  (That is, as a result of a merge and if one stays within the O-O ontology on encapsulation.)

Let's say that in use cases "A" and "B" I have a flow name of "CalculateSalesTax".  We must recognize that these two flows are in different name spaces; thus, their fully qualified names are A.CalculateSalesTax and B.CalculateSalesTax.  These names are not duplicates.  Because of encapsulation, neither A nor B can reach the CalculateSalesTax flow in the other's name space;  each may only reach their own flows.

Therefore, all of my optional interpretations are moot.

This does, however, raise Question # 3.

Many authors note that the extension relation is beneficial because it allows one to add functionality to a base use case who's specification has been locked.  The idea being that the locked use case is not modified to accomplish the extension.

So how do the extension points get into the base use case?  Do we have perfect vision into the future to plan ahead for all needed extension point names and provide them before we lock the specifications?  I think not.  Can it be that a specification lock is not violated by the later addition of extension point names?

How do you guys handle this?

[thomaskilian]

Hi Jim,
I guess that #3 is nonsense/too much simplified. Since you need to refer to the extension you NEED to modify your extended UC. Except, of course, you're clairvoyant and have foreseen the extensions already

Regarding <<inject>>: I think that include/extend is fine for me and I even do not use them often. It proofed to be a starting point of analysis paralysis in almost each case. However, I also found out that there are circumstances where you want to show things in a different aspect (I have that thread with the directed relations between UC and Actor). So there should be no hindrance in using <<inject>> for you purpose.

[sargasso]

I commonly use <<extend>>, rarely <include>>.  The basic web browse/buy model has always seemed to me to be :

(buy) -----<<extends>>-----(browse)

My rationale being that (browse) can often satisfy an end user goal in itself and can thus stand alone as a use case,

e.g. (research train timetables) ----->(reserve travel)

Obviously, to the primary actor, (research train timetables) can be a standalone goal.

bruce

[«Midnight»]

See Scott Ambler, The Elements of UML 2.0 Style: Rules 72, 73, 74 and perhaps 75.

He gives a good explaination of <<extend>> and how it differs from generalzation.

In particular note rule 73, "Use Extend Associations Sparingly."

NB: Thomas, he also gives some worthwhile guidance on when and how to use directed associations between actors and use cases. However, this pretty much confirms what you've been saying.

[thomaskilian]

Thanks David, I probably have to order that book. I nomally do it like a famous novellist (whos name I forgot): Most of the stuff I'm reading I write by myself

[«Midnight»]

It is difficult not to be bogged down by weighty tomes, each providing at best a sliver of unique insight.

Ambler's book - at least this one - is a true exception. It is incredibly clear, and refreshingly inexpensive. My edition had no price marked by the publisher, and cost me around $20 CAD, give or take a buck or two.

The book is also both small and concise. This could well be from Ambler's work in Agile Modeling. While it does have the Agile glyph on the cover, it devotes only a brief isolated section to that paradigm. The main body of the text is written to be methodology agnostic, but often references specific styles and exceptions that work well with the various popular 'taos' of UML.

[bioform]

I'm out of my league here, but:

I use UC A <extend>  UC B to mean that UC A provides optional functionality to UC B (as in a reference to UC A in an alternate path).

I use UC A <includes>  UC B to mean that UC A provides functionality to UC B that is ALWAYS used.

[«Midnight»]

I don't know what you imagine your league to be Bioform, but IMO you have the overall intent dead on!

I'd add to your bracketed example that the <extend> case might be called from one or more different places in the 'parent' use case.

There are all kinds of nuances of course, but you should keep this big picture in mind when working on a technique. Once you stray from these confines it is time to realign your goals and methods.