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 6: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 6: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 6: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 8: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/26/2010 12:27 AM
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

In today's ever-evolving market, businesses must adapt swiftly to remain competitive and meet the needs of a fast-paced digital economy. Among the various business strategies available, digital transformation, customer-centricity, and sustainability have emerged as top priorities. Let’s explore why these strategies are critical for busine...
The Cisco Certified Network Associate (CCNA) certification is a pivotal credential for networking professionals, validating your skills in networking fundamentals, security, automation, and programmability. Preparing for the CCNA exam can be challenging, but with the right strategy, resources, and mindset, you can successfully achieve this certific...
The CEO/CIO's Guide to Architecting AI: Vision to Value in Minutes Introduction to Architected AI Artificial intelligence (AI) is becoming part of our life at an unprecedented pace. As CEOs and CIOs grapple with how to leverage this powerful technology to drive strategy and enhance operations, the concept of Architected AI becomes importa...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC