[sigfreed77]

This is a simple question for those who are extremely proficient with UML use cases. This is an Object Oriented use case using UML, so all I'm asking for is for feedback to improve the current design, IF needed. If you got any ideas to improve the following diagram, let me know please. I'll appreciate it. Review the attached picture for details.

Note: This isn't a UML forum, but this diagram is for a to-be design program, in either Java or C++. So, it's related in some way to this forum. Thanks 

Attached image(s)

• 

[macosxnerd101]

Moved to Software Development for better visibility.

[sigfreed77]

You moved it or I need to move it myself? Just clarifying that. Thanks for replying.

[macosxnerd101]

I already moved it.

[sigfreed77]

Thanks again.

[BobRodes]

I would start by changing the titles of your use cases slightly. Make each of them an activity, like "book flight". For example, "Enter passenger and payment information." Then, look into includes and extends. Entering passenger and payment information is actually included in booking a flight, so you would want to set it up as an include for booking a flight. I would also consider setting up a separate use case for credit card approval, and including that in booking a flight. (If you can book a flight in any way without a credit card, then you would set up "approve credit card transaction" as an extension point of book flight rather than an include. You would also set up the other means of booking a flight--for example, frequent flyer mile turnin--as a separate use case which would also be an extension point for booking a flight.)

Another thing is that you might consider using a different symbol for non-human actors. Different people feel different ways about this, and human symbols for computers is fine too. You can do something as simple as putting a box with <<actor>> on top of it (this is called a "stereotype" and is one of the means of extending the UML).

If there is a reason other than esthetic that you have alternating colors, you'll need to name them with a stereotype and explain the stereotype in a note somewhere.

Digest that, and feel free to post back with questions. We could talk about "use case narratives" and "use case scenarios" and how to diagram them if you're going into that level of detail. The level of detail depends on who is consuming your document, of course.

[sigfreed77]

Thanks BobRodes. Your level of explanation this diagram much easier to re-design and clearer to understand. On a side note, I also program in VB and every now an then need some help, so you might see some of my posts floating around dreamincode[dot]com. Thank you again