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.
764 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

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