Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Use Cases Packages question
Previous Previous
 
Next Next
New Post 5/26/2008 12:25 PM
User is offline Roman
14 posts
10th Level Poster


Use Cases Packages question 

Dear community.

I am building a use case diagram to model the functionality of a system.  The diagram grew into quite a large size so I decided to make it more readable by creating packages for logically related use cases.  My problem with packaging arises when I extract commonly used use cases (inclusion and exclusion use cases that are used by a few other use cases in other packages) into a separate package.  I don't know the rules in regards to showing association between packages (i.e am I allowed to model association between package A and package B by connecting the two packages with an "Association" line).  I was hoping that someone may be able to clarify things for me in regards to this matter.

 

Best Regards,

Roman 

 
New Post 5/26/2008 1:03 PM
User is offline Perry McLeod
70 posts
8th Level Poster




Re: Use Cases Packages question 

Roman,

You sure can! Have a look at this lesson link for UML 2.0 http://www.agilemodeling.com/artifacts/packageDiagram.htm about half way down as long as you add value to the reader "how you categorize the diagram is of little real consequence." As you can see there is an association between packages.

UC packages are not like CLASS packages. They need not follow the same rules. Read the rest of the link for some tips and tricks.

Read on here, if you are interested in Uce Case desgin a more a advanced level ....

When formulizing a Use Case in an advanced design house...Formulizing a use case is about taking the diagrams and narratives and turning them into a real object oriented system

  • "A formulized use case goes through three phases: realization, refinement, and reification
  • use case realizations are the design models (activity diagrams, state machines …) that are translated from use case scenarios
  • use case refinement is about gathering all of the use cases for each modeling element contained within the system and model the collaborations among these elements (subsystems and classes)
  • use case reification is a method for turning use cases and actors into classes of the system
    • reification is literally the process whereby concepts become material
    • also called hypostatization its about treating an abstract concept as if it were a real concrete thing (use cases as eventual instantiated objects)
    • the use case therefore becomes part of a class category
    • each use case is an operation of the system
    • ‘AllActors’ becomes another class
    • each actor is an instance of ‘AllActors’
    • a class is then created for each use case
    • each scenario is added as an operation of its class
    • an actor object starts a scenario by sending a use case message to the system, which in turn instantiates a use case object from its class
    • the second message sent by the actor is the scenario name, It is sent to the instantiated use case object (this tells the use case object which
    • scenario it will be doing)
    • additional objects can then be instantiated by the scenario that are an actual part of the system
      the actor interacts with these new class objects normally, but can also send additional use cases messages (to System) or scenario messages (to use case objects)"

just in case you were wondering.

Perry McLeod, CBAP, PMP

 
New Post 5/26/2008 4:20 PM
User is offline Adrian M.
765 posts
3rd Level Poster




Re: Use Cases Packages question 

 Roman wrote

Dear community.

I am building a use case diagram to model the functionality of a system.  The diagram grew into quite a large size so I decided to make it more readable by creating packages for logically related use cases.  My problem with packaging arises when I extract commonly used use cases (inclusion and exclusion use cases that are used by a few other use cases in other packages) into a separate package.  I don't know the rules in regards to showing association between packages (i.e am I allowed to model association between package A and package B by connecting the two packages with an "Association" line).  I was hoping that someone may be able to clarify things for me in regards to this matter.

Best Regards,

Roman 

Hi Roman,

Here's what you can do:

  • Place the commonly used use cases in the logical package where it most make sense OR place all common use cases in one package called "Common".  I would opt for the first option.
  • Then when modeling the use cases in a separate package and you need to use one of the common use cases, just show the common use case in the diagram but prefix the name with the package name.  For example: "Common: Register".  This way it will be clear that even though the Register use case is used in a given use case diagram it actually belongs to a separate package called "Common".
  • Many UML modeling tools already support this feature (to prefix a use case from another package with that package's name).

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 5/27/2008 6:08 AM
User is offline Roman
14 posts
10th Level Poster


Re: Use Cases Packages question 

Adrian and Pmcleod.

Thank you kindly for prompt and resourceful answers!  Provided answers helped me a lot !

Cheers,

 

Roman

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Use Cases Packages question

Community Blog - Latest Posts

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...
In today's dynamic business environment, mastering effective business analysis techniques is crucial for organizations aiming to achieve sustainable growth and competitive advantage. Business analysis involves the systematic evaluation of business processes, requirements, and strategies to uncover insights that drive informed decision-making. T...
For many years now, a lot of people have found it difficult to identify the difference between Sankey diagrams and parallel sets. The two have made headlines, given that most people find it challenging to note what makes them different from each other. What remains to be undeniable is the fact that the Sankey diagram is among the top data visualiza...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC