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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC