Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  General  Use Case Extension Points and Alternative Flow
Previous Previous
 
Next Next
New Post 12/2/2011 4:17 AM
User is offline a3000
5 posts
10th Level Poster


Re: Use Case Extension Points and Alternative Flow 

Thanks! Makes a lot of sense now!!!

 
New Post 12/2/2011 7:55 AM
User is offline Adrian M.
739 posts
3rd Level Poster




Re: Use Case Extension Points and Alternative Flow 

Kimbo gave a good example! 

One clarification, an extension point usually references another use case rather than another flow.

The way I like to think about the difference is that the alternate flow is another way to get to an outcome for a given use case as opposed to an extension which is an optional set of steps and therefore can be easily specified/described as a separate use case.

There are two ways of answering your question:

  • Practical - Understand your need and solve it?
  • Exact - What does the UML specification say?

Practical

From a practical standpoint - I already provided you with my view in my previous post.  What I would add is to think about when you might want to break a use cases into multiple use cases.  I usually separate functionality from one use case into another use case for 3 reasons:

  • Deal with complexity - when a use case specification becomes very large (with numerous alternate flows and exception flows) it is a sign to consider breaking the use case down further.
  • Deal with optional behavior - when you need to add to a use case optional behavior which does not alter the outcome of the main use case, it's another case to consider expressing that logic as another use case.  Example: Main use case would be the place purchase order allowing the actor to buy a set of items.   An optional set of steps during the process of the main use case or at the end of it is to request a new product catalog.  The process for requesting a new product catalog can be expressed as another use case since regardless of its outcome it has not impact on the main "purchase order" use case.
  • Deal with common behavior - think of this as reuse at us case level.  If you have two processes/use cases that share something in common - the flow/steps/process in common is a candidate for being described in a separate use case and simply referenced from the other two use cases.

Exact

If you really want to know exactly how these constructs are supposed to be used then your definitive source is the UML specification published by OMG (free to download).

The actual, formal, specification is a bit hard to navigate if you're not familiar with it so here are some excerpts.

The UML specification defines 2 main relationships between two use cases: extend and include:

Include: "An include relationship defines that a use case contains the behavior defined in another use case."

Extend: "A relationship from an extending use case to an extended use case that specifies how and when the behavior defined in the extending use case can be inserted into the behavior defined in the extended use case."

As you can see, the definitions are not very practical - aka you need to re-read the entire section on use cases a number of times.

A little bit more from the specification (see Chapter 16 of the UML Superstructure document):

Extend

"This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case and is meaningful independently of the extending use case. On the other hand, the extending use case typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending use case defines a set of modular behavior increments that augment an execution of the extended use case under specific conditions.

Note that the same extending use case can extend more than one use case. Furthermore, an extending use case may itself be extended."

Include:

"Include is a DirectedRelationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case. It is also a kind of NamedElement so that it can have a name in the context of its owning use case. The including use case may only depend on the result (value) of the included use case. This value is obtained as a result of the execution of the included use case.

Note that the included use case is not optional, and is always required for the including use case to execute correctly."

Again, for all practical purposes, an extend is functionality which is generally NOT required, but the include is generally functionality which is required.

IMPORTANT NOTE: The UML Specification does NOT contain any guidance on how to describe the internals of a use case and therefore it does not include any topics such as: main flow, alternate flow, exception flow.  These constructs are found more as an informal agreement of what these terms mean among the practitioners that use use cases.

Hope this post did not add to the confusion.

Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 12/3/2011 3:33 PM
User is offline a3000
5 posts
10th Level Poster


Re: Use Case Extension Points and Alternative Flow 

 thank you very much Adrian!

 
New Post 12/4/2011 5:08 PM
User is offline a3000
5 posts
10th Level Poster


Re: Use Case Extension Points and Alternative Flow 

 

I have another question...

Take this use case as an example:"Manage Document"basic flow:

- Create a document 


- Save a document


- Submit a document


- Evaluate a document

 

Now the Manage Document use case shares an include relationship with 5 other usecases ( Manage attachments, Manage Notes, Manage Related Documents, Manage Location etc). But I'm being told to write include use cases as extenion points. Some of those use cases are optional like " Add related documents" and some are mandatory in order to submit the document. Is it corect to write an include relationship as an Extension Point? I don't think it is right specially based the defintions. But no one has flagged it in my team. 
Thanks again for the help!

 

 
New Post 12/19/2011 12:47 AM
User is offline KJ
243 posts
6th Level Poster


Re: Use Case Extension Points and Alternative Flow 

This whole thing looks like "functional decomposition", which is a no-no. Rather consider what is the goal. I guess when you create a document you save a document; you submit an existing document. Not sure what evaluate a document means -- ie what is teh goal.

Just some thoughts.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  General  Use Case Extension Points and Alternative Flow

Community Blog - Latest Posts

So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...
Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified. 1. Not understanding underlying business need Organization’s business environment keeps changing with respect to Customer...
TOGAF is a certification that is handed over by The Open Group. It is an open corporate architecture means used to improvise upon the business effectiveness across the world’s leading business set-ups. Aspirants wishing for a successful career in corporate architecture must go for the TOGAF certification in order to explain the...

 



 

Copyright 2006-2021 by Modern Analyst Media LLC