Author Topic: Use Case Arrows - what to use?  (Read 2904 times)

Ingrid

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Use Case Arrows - what to use?
« on: October 01, 2003, 10:04:28 am »
Hi:  We just brought UML in house with EA (which we love!). So while we learn EA, we are learning UML. What myself and my team argue on is what arrows we should be using to show relationships between use cases. For example, we have the following use cases:
Log in
Search
View
Update

We are using generalization arrows, but the use cases aren't children or parents of one another (they do not inherit functionality), then we thought, maybe we need to use dependency arrows. We'd like to do this right, can someone point us in the right direction? What types of arrows should we be using to indicate that if the person can update, they can view, search and log in etc. Please see our simple use case diagram below.





« Last Edit: October 01, 2003, 10:42:34 am by Ingrid »

LaurentM

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: Use Case Arrows - what to use?
« Reply #1 on: October 01, 2003, 10:29:38 am »
hmm.... have the same request. Created some use cases and was hopping that the 'uses' relationship would show up on screen with the direction of the relationship (especially considering the data has the notion of From/To). Can someone let me know how to get the arrow heads to show???

cheers,

Laurent Mihalkovic

Fintan

  • EA User
  • **
  • Posts: 28
  • Karma: +0/-0
    • View Profile
Re: Use Case Arrows - what to use?
« Reply #2 on: October 02, 2003, 12:33:54 am »
Hi Ingrid / Laurent,

The correct way to show the connection between the Actor and the Use Case is to use the Association line.  The arrow should be pointing to the Use Case, i.e. from Actor to Use Case.

If you double click the association (or right click and choose Association Properties), the Association Properties dialog pops up.  In the 'Direction' combobox (originally "Unspecified") select "Source -> Destination".  This will put an arrow on the Association.

Ingrid :
<<extends>> and <<include>> are the only arrows that should be between Use Cases.  In your diagram you should not display any links where your generalisation links are.

Instead you should have association links (with arrows pointing to Use Cases) from the actors to each Use Case.  This is so we know who can trigger each use case.  The Use Case Model does NOT allow you to show the order that Use Cases are executed.  If you need to show this you will have to use Activity diagrams.

Hope this helps,

Fintan

JEff Russell

  • EA User
  • **
  • Posts: 24
  • Karma: +0/-0
    • View Profile
Re: Use Case Arrows - what to use?
« Reply #3 on: October 02, 2003, 12:53:46 pm »
Fintan:
I have a question regarding your statement:
Quote
<<extends>> and <<include>> are the only arrows that should be between Use Cases.  

In my little corner of the universe, I decided to decompose a use case into <<included>>'d cases to focus on different aspects during phased development.   In the attached diagram, a use case displays information about an "architecture" which at some low level consists of "procedures".  (The domain model expresses this relationship.) In addition to decomposing the use cases, I made the "Display procedure" use case abstract.  Then, it is specialized as two different use cases: a text display case and a graphics-based case.  What the use case accomplishes is the "same", but from the user perspective (and the required system design), these are separate use cases, right?
Any comments?  Good/bad approach?  
(The abstract use case also helped with documentation because the requirements "pass through" to the specialized use cases.)
JEff

dlundy

  • EA User
  • **
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: Use Case Arrows - what to use?
« Reply #4 on: October 06, 2003, 01:44:05 pm »
I wouldn't have done it that way. The foundational characteristics of a Use Case are "That it return some value to the Actor" endit. Your two use cases that do the same thing - are as you suspected - just one use case.

For what its worth in your model: I further disagree that everything ends up in procedures.(Granted its a sample) You are following the well traveled path of functional decomposition of Use Cases in your thinking - it will not lead you to where you want to be. Your referenced Domain Model contains Class Diagrams, Sequence Diagrams, etc. These are your: Objects!! (sorry pet peeve!)

The includes/extends are not intended for functional decomposition (although they are often used that way up to a point) - rather they are intended as notational conveniences (again, mostly) so that you do not have to repeat the entire content of a Use Case over again when you wish to use it as part of another Use Case.

A Use Case model centers around the Actors and their interactions (Use Cases) that provide value to them. If you constantly stick to that rule, you will find many so called Use Cases disappearing from your diagram.

Dan


« Last Edit: October 06, 2003, 01:45:40 pm by dlundy »
Dan Lundy

JEff Russell

  • EA User
  • **
  • Posts: 24
  • Karma: +0/-0
    • View Profile
Re: Use Case Arrows - what to use?
« Reply #5 on: October 07, 2003, 11:27:16 am »
Dan,
Thanks for the comments, they really are appreciated.
Quote
For what its worth in your model: I further disagree that everything ends up in procedures.(Granted its a sample) You are following the well traveled path of functional decomposition of Use Cases in your thinking - it will not lead you to where you want to be. Your referenced Domain Model contains Class Diagrams, Sequence Diagrams, etc. These are your: Objects!!

Just to clarify a point: the "procedures" are objects in the domain model, not procedures that would be used to implement my UML modeled system. (The domain is the interactive analysis of a hardware design specified with a hardware description language whose fundamental grouping of operations is a "procedure".)

Also, discounting the specialization aspect of the use case diagram, I fully expect an actor to invoke each <<included'd>> use case either separately or from the "top" level.  Granted, it is functional decomposition, but it is decomposed from the actor's point of view.  The actor may display everything (e.g. architecture), or only lower levels of detail (e.g. functional architecture or a single procedure).
Originally, I listed each of these use cases separately with a corresponding association to the actor.  I found the diagram very busy.  Adding the hierarchy (from decomposition) helps organize these related use cases.
What do you think, now, with a little more explanation?
I like your "returns something to the actor rule".  My reasoning doesn't directly address this one.
JEff