DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 2 of 2

Thread: Use Case Includes

  1. #1
    Jason Mowat Guest

    Use Case Includes

    Greets,

    I was wondering if you should show the includes use cases on your diagrams
    for alternate courses. For example, I have a use case that performs task A.
    However, an alternate course is that task A fails or otherwise can't be
    performed, in which case I include task B and task C. Should I show these
    includes on my diagram, even though they would be "executed" if task A
    fails?

    I'm thinking it clouds the diagram a bit. Should I perhaps create a use
    case exception diagram instead?

    Thanks,
    Jason



  2. #2
    Guy Smith Guest

    Re: Use Case Includes


    "Jason Mowat" <jmowat@sbgh.mb.ca> wrote:
    >Greets,
    >
    >I was wondering if you should show the includes use cases on your diagrams
    >for alternate courses. For example, I have a use case that performs task

    A.
    >However, an alternate course is that task A fails or otherwise can't be
    >performed, in which case I include task B and task C. Should I show these
    >includes on my diagram, even though they would be "executed" if task A
    >fails?
    >
    >I'm thinking it clouds the diagram a bit. Should I perhaps create a use
    >case exception diagram instead?
    >
    >Thanks,
    >Jason


    Jason, try reading this:

    http://www.zoo.co.uk/~z0001039/PracG..._use_cases.htm

    It is probably the best article I've found to help put use cases into perspective.
    I get the impression you are struggling with the big picture of use cases
    and the system development so I'll ramble on a bit.

    Remember use case diagrams are written to capture "user" scenarios/goals
    with the system and the system's responses to the user when accomplishing
    their goal. They are a high level concepts of "what" that system needs to
    do, written from the user's perspective. You should not be thinking in terms
    of system barriers, file formats, functions, etc when writing use cases.
    Those things will be captured later.

    If your thinking in terms of functions, file formats, etc your thinking too
    far down the line. Put these things out of your mind or jot notes in a book
    or have your object diagram handy and add some preliminary methods and objects.
    These things are important but are not part of writing use cases. If you
    are too focused on the details too soon you'll get bogged down and miss "what"
    the system needs to do. There will be lots of time to figure out the nitty-gritty...
    later.

    Use cases are created to capture what the user needs to do with the system.
    The "how" is going to be captured in the objects and their methods. That
    is what the object diagram, sequence diagrams and colaberation diagrams accomplish.
    If the use case seems too system specific, a lot of times those specifics
    should be a method or property of an object (or objects) and not a part of
    the use case.

    There are also some "gotcha" use cases that are typically missed. They entail
    such things as security, archiving, and auditing. Remember that "you" (or
    the system administrator) are also "users" of the system.

    Now to answer your question...

    As the article points out, alternative courses (anything that is conditionally
    executed) are always "extends" on the diagram. Extends alter the primary/happy
    course. So, if use case A has an exception where it cannot accomplish it's
    task, extend A with the alternative courses of use cases B and C.

    The "includes" relationships allows one use case to make use of another.
    Always look for common functionality and extract that common functionality
    into it's own use case. Then "include" this use case. For instance, drawing
    on the ATM example, say your starting to do analysis and so far you've only
    identified the need for a withdraw and deposit use case so far. Looking at
    them, you'll notice that a common step in each is to login and select an
    account, hence those two scenarios are broken out into their own use cases
    and "included".

    Also of value, the article points out that there is a trade off in making
    use cases - complexity vs understandability. You can load up the use case
    diagram to the point it is hard to understand. It is a common mistake to
    break things into too many details and end up with too many use cases on
    the diagram. A lot of those "extra" uses cases should be steps detailed
    in the text description of an encompassing use case.

    You'll also find that no one seems to agree exactly how to create use cases.
    Some say that they should be tied to psuedo elements of the user interface,
    others strongly disagree. You'll have to figure out what works for you.
    Bests advice I can give is that writing use cases should be iterative.
    As you learn more about the problem, it is okay to go back and adjust your
    use cases. Try hard to nail down everything you can initially but don't
    be afraid to adjust as needed. And when you are done the project, always
    sit down and evaluate what worked, what didn't work and why, that way you
    can do things better "next time".

    As for a book to read, try "Use Case Driven Object Modeling with UML - A
    Practical Approach" by Doug Rosenberg with Kendall Scott. It provides an
    end-to-end methodology for doing system development with use cases. The
    method may help you keep a focused direction. You may also like "UML", from
    the Schaum's Outline series as it has a lot of examples (although not the
    best read). There is also "Teach Yourself UML in 24 hours" which is a good
    intro but you'll find "24 hours later" you'll be looking for more meat and
    clarification.

    As for other articles try some of the articles at http://www.sdmagazine.com/uml/
    . Some articles are part of the book "Use case driven object modelling"
    (you'll recognize the authors names).

    Guy Smith

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center