how to model include relationship in uc scenario

[karomann]

Hi,
how do you model the include relationship in the use case scenario? Do you create a separate step e.g. 5. Include UC XXX or is there a better solution?

[«Midnight»]

Yes, that sounds correct.

Often the phrasing is simply something like: "5 Perform UCYYY" (or the name of the included use case, or both).

[jeshaw2]

The answer to your question is a bit complex. A simple answer is to say yes, the included use case is modeled apart from the base use case that includes them.  A factor to consider, however, is what  you are trying to accomplish.  Is the included UC produced by factoring out common logic from several other use cases, or are you trying to cope with cross cutting concerns as in Aspect Oriended Design? These are handled in different ways.  Also, Included use cases are broader than a single scenario.

I'm not sure if you are referring to a UML diagram of a use case or the textual description of the use case.  May I recommend that you read my article on Use Case Descriptions published on the EA Wiki?  I know it is more than you asked for, but I think your answer is in there somewhere.  If not, let me know.

I would encourage you to read the entire article and not just jump to the Include section.  There is a larger pattern of logic that sets up a context for what you are trying to understand.

-Jim

[sargasso]

... and for the sake of your sanity don't what ever you do search the archives of this forum for my and Paolo's and others dicussions of "include"  

OBTW '''  extends '''       that way lies madness.

In short, if it aint obvious dont use it.
hth
bruce

[karomann]

Thank you for your answers, the purpose I want to achieve is to factor out common logic from several use cases.

More specifically, I want to include an authorisation logic in a separate use case. According to UML specification, will the invoking (including) use case be aware of the included (authorisation) use case result (successful/failed)?

And one more question, BTW: Is there any difference between the "include" and "uses" relationship?

[«Midnight»]

Wouldn't there have to be some kind of understanding? If not, how would the invoking use case know how (or whether) to proceed?

[karomann]

Of course! I have misunderstood the definition of Include relationship on wikipedia. Read only "There are no parameters or return values." but missed "The first use case often depends on the outcome of the included use case."

[Gary W.]

More specifically, I want to include an authorisation logic in a separate use case.

For this sort of thing, we document it as a precondition on the use case(s).  For example, "Lands Administrator is logged on and has been granted the appropriate authorization to bla bla bla...".

However, be aware that Use Cases aren't *great* at documenting non-functional requirements (i.e. complex system logic that has little use interaction).  A Use Case that simply documents that logic may end up being one long paragraph, or a bunch of pseudo-code.

HTH
gary

[«Midnight»]

Also note that you don't 'call' a use case in the same sense as you do a subroutine. Nor does the use case take parameters or return a result, at least not in the sense of a subroutine hierarchy.

[Henk]

I general i do would steer away from includes and excludes, simply because they denote solution. That is what you try to avoid with use cases.

I think the order of execution is better documented in the sequence diagram.

Keep in mind, UML is not about the pictures really (on use case level) it is about the use case description, and as said before pre and post conditions are a good way to establish what has to be "true" before the use case starts.

Just my 2 cents worth (keep the change :-))

[jeshaw2]

I general i do would steer away from includes and excludes, simply because they denote solution. That is what you try to avoid with use cases.

I think the order of execution is better documented in the sequence diagram. ...

Its OK to avoid Includes, Extends, and Generalize, stereotypes particularly with stakeholders, but it is not correct to say they denote a solution.  These stereotypes denote the structure of a text document, not the structure of an application system.

I would also recommend Activity Diagrams over Sequence diagrams;  users understand them better.

Jim
I'll keep your change  

[karomann]

These stereotypes denote the structure of a text document, not the structure of an application system.

Well I can't really agree with you. Why can't those stereotypes be used while modelling an application system? The system use-cases idea states that the use cases document the iteractions between the actors and the system. And, therefore, one can use the 'extend' relationship when from a level of one interaction with the system (e.g. use case "browse invoices") he/she may invoke another iteraction (e.g. use case "download invoice documents")

Also note that you don't 'call' a use case in the same sense as you do a subroutine. Nor does the use case take parameters or return a result, at least not in the sense of a subroutine hierarchy.

You mean the function decomposition? Because, AFAIK, the use cases DO act "similar to calling a function or invoking an operation within source code" (Scott W. Ambler's article on reuse in use case model: http://www.agilemodeling.com/essays/useCaseReuse.htm).

As far as the preconditions are concerned, I agree it is a brilliant solution to most of the authorisation/login problems.  Though, in my application there will be various authorisation levels and the application will have to check user's authorisation level every time a "protected" operation would be accessed by him. Unluckily, this check often takes place in the middle of a use-case logic and according to our project methodology (maybe not the best one) we want to describe the use cases at such a detail level that we want to know when the authorisation level checking takes place (e.g. because very often we display a higher-level-authorisation-form then).

And thanks for your replies .

[Gary W.]

... in my application there will be various authorisation levels and the application will have to check user's authorisation level every time a "protected" operation would be accessed by him. Unluckily, this check often takes place in the middle of a use-case logic and according to our project methodology (maybe not the best one) we want to describe the use cases at such a detail level that we want to know when the authorisation level checking takes place (e.g. because very often we display a higher-level-authorisation-form then).

Then you really have no choice but to factor out the portion-of-the-use-case that requires an up-front authorization check.   Well, either that or come up with a another way to document such cross-cutting concerns in a section separate from the use case body, but which can be readily cross-referenced.

We'll be tackling the exact same problem in about 6 months, when we begin design of an application that requires such fine-grained security.  We have yet to decide how to specify this =8^(

gary

[jeshaw2]

Karomann

Well I can't really agree with you.

I would like to respond to your comments but avoid an ontology war at the same time.  We all are free to agree or disagree with each other on this forum.  One posts what they have to offer, others take away what they like.

Why can't those stereotypes be used while modelling an application system?

Those stereotypes can an should be used when modeling an application system, but not all the time and not in all cases.  When writing a Use Case, one must consider:  Who will be the reader, what is the purpose of the reading of it, at what level of abstraction is the Use Case being written, what is the nature of the primary actor (human or system), etc.

The system use-cases idea states that the use cases document the iteractions between the actors and the system.

True enough.  A use case can specify the actor/system interface protocol.  

And, therefore, one can use the 'extend' relationship when from a level of one interaction with the system (e.g. use case "browse invoices") he/she may invoke another iteraction (e.g. use case "download invoice documents")

For me, this conclusion does not logically flow from the preceding assertions.  Even if it did, this design approach would reduce the reuse-ability of the Use Case.  I am, however, open to a more persuasive argument.

Because, AFAIK, the use cases DO act "similar to calling a function or invoking an operation within source code" (Scott W. Ambler's article on reuse in use case model: http://www.agilemodeling.com/essays/useCaseReuse.htm).

Scott's full statement to which you refer is:

Similar to calling a function or invoking an operation within source code, isn’t it?

The answer to this question is both yes and no.  Rhetorical questions, meant as trial balloons, are often mistaken as statements of fact.  Yes, include and extending Use Cases affect the way in which the base Use Case is read by a human.  And, that is similar to the way a computer reads the program code, but no, it is not an implementation specification.   There are other authors, applauded by Scott, that express this differently.

Different ontologies, however, approach a system's development in different ways. For my practice, I follow the blended ontologies of the OMG's MDA and UML.  Within that framework, 90% of the time, Use Cases are written by Business Systems Analysis.  These analysts operate very early in the development process and work at very high levels of abstraction (e.g.; The MDA CIM & PIM levels).  While I afford my Analysts the ability to use Included and Extending Use Cases as appropriate, I certainly would not want them designing a solution architecture within a Use Case document!  Most effective Business System Analysts have long forgotten how to code programs.