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

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC