Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  HELP! - Specifying common behaviour across multiple use cases
Previous Previous
 
Next Next
New Post 2/25/2010 5:15 AM
User is offline Peter Herring
13 posts
10th Level Poster


HELP! - Specifying common behaviour across multiple use cases 

Hi,

I'm really looking for some advice. I am used to the concept of extracting common behaviour that occurs in the main flows of multiple use cases, and turning that common behaviour into an included use case to avoid duplication of effort.

In a current project I have about 5 use cases where in the alternate flows it's validating the users authority level to ensure they are able to perform the behaviour in that alt flow.

In this particular example the user is requesting to perform an action outside the normal flow that requires increased user authority. the system needs to check their permissions, and where they are not high enough stop the user performing the action, and then create a task for someone with the correct authority to resolve.

I can't add the check as a precondition of the use cases, because it only occurs if the alternative flow is initiated. My understadning of Inlcuded use cases is that they can only be called from the main flow of the calling use case? Forgive me if my understanding is incorrect. I would welcome any advice.

Logc tells me that there must be a way to specify this piece of behaviour once.

Regards

Pete

 
New Post 2/25/2010 5:35 AM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: HELP! - Specifying common behaviour across multiple use cases 

"My understadning of Inlcuded use cases is that they can only be called from the main flow of the calling use case?"

I don't believe this is true. Includes and Extends are always tricky, but I would not let them restrict what you are doing.


David Wright
 
New Post 2/25/2010 5:59 AM
User is offline madalinaro
9 posts
10th Level Poster


Re: HELP! - Specifying common behaviour across multiple use cases 

You cannot use the <include> relation in this case. As the UML specification states: "Note that the included use case is not optional, and is always required for the including use case to execute correctly."

Source: http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

 

My idea would be to use <extend> relation between the 2 use cases and add an extension point with a condition.

 

Example:

Online Help Use Case <extends> Perform ITM Transaction use Case

Extension point: Selection

Condition: Customer selected HELP

 
New Post 2/25/2010 7:32 AM
User is offline Peter Herring
13 posts
10th Level Poster


Re: HELP! - Specifying common behaviour across multiple use cases 

Hi Madalinaro

Yes this makes sense. So, with the new extending use case that's been derived from the alternate flow is it also possible for that to extend other use cases? Taking your example forward,  the online help may be called from more than just perform ITM Transaction? And can I also assume that the online help use case can stand on it's own. Some examples I've seen state that the extending use case cannot, but that doesn't seem to be the case. Having looked at the UML 2 spec, it does suggest that it may, or may not stand on it's own.

Im conscious of not over using the extend relationship, and in Martin Fowler's "UML Distilled" it goes so far as to say you should ignore it completely! But I seem to be at a cross roads where I am repeating behaviour across use cases, and from what you've said, it does see mto apply in this instance. 

 

 
New Post 2/25/2010 11:27 PM
User is offline madalinaro
9 posts
10th Level Poster


Re: HELP! - Specifying common behaviour across multiple use cases 

 pherring wrote

Taking your example forward,  the online help may be called from more than just perform ITM Transaction? 

  Yes

  And can I also assume that the online help use case can stand on it's own. Some examples I've seen state that the extending use case cannot, but that doesn't seem to be the case. Having looked at the UML 2 spec, it does suggest that it may, or may not stand on it's own.
True, even there it is ambigous.

As a conlusion, I think it's ok to apply it in your situation

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  HELP! - Specifying common behaviour across multiple use cases

Community Blog - Latest Posts

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
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...

 






 

Copyright 2006-2021 by Modern Analyst Media LLC