A
Unified Modeling Language Diagrams

The Unified Modeling Language (UML) use case diagrams in this manual present a representation of the technology used in Advanced Queuing. A brief explanation of use case diagrams and UML notation follows.

This chapter discusses the following topics:

• Use Case Diagrams
• State Diagrams

Use Case Diagrams

In a use case diagram, the primary use case is instigated by an actor (stickman), which can be a human user, an application, or a subprogram. The actor is connected to the primary use case, which is depicted as an oval (bubble) enclosing the use case action, as shown in Figure A-1.

Figure A-1 A Primary Use Case

Text description of the illustration uml001.gif

Primary use cases may require other operations to complete them. In Figure A-2,

• specify queue name

is one of the suboperations, or secondary use cases, needed to complete

• ENQUEUE a message

The downward lines from the primary use case lead to the other required operations (not shown).

Figure A-2 A Primary Use Case with Suboperations

Text description of the illustration uml002.gif

As shown in Figure A-3, a secondary use case with a drop shadow expands into its own use case diagram, thus making it easier to:

• Understand the logic of the operation
• Continue a complex operation across multiple pages

In this example

• specify message properties
• specify options
• add payload

are all expanded in separate use case diagrams.

Figure A-3 A Use Case Diagram with Drop Shadows Representing Secondary Use Cases

Text description of the illustration uml003.gif

The diagram fragment in Figure A-4 shows an expanded use case diagram. While the standard diagram has the actor as the initiator, here the use case itself is the point of departure for the suboperation. In this example, the expanded view of

• add payload

represents a constituent operation of

• ENQUEUE a message

Figure A-4 The Expanded Use Case Diagram

Text description of the illustration uml004.gif

Figure A-5 shows how note boxes are used:

• Note boxes can present an alternative name. In this case, the action SELECT propagation schedules in the user schema is represented by the view USER_QUEUE_SCHEDULES.
• Note boxes can qualify the use case action. In this case, the list attribute names action is qualified by the note that you must list at least one attribute if you do not list all the attributes of the propagation schedule.

Figure A-5 Note Boxes

Text description of the illustration uml007.gif

The dotted arrow in the use case diagram indicates dependency. In Figure A-6

• free a temporary LOB

requires that you first

• create a temporary LOB

The target of the arrow shows the operation that must be performed first.

Figure A-6 Dependencies

Text description of the illustration uml008.gif

Use cases and their suboperations can be linked in complex relationships. In the example in Figure A-7, you must first

• REGISTER for notification

to later

• receive a notification

Figure A-7 Use Case and Suboperation Relationships

Text description of the illustration uml009.gif

In Figure A-8, the branching paths of an OR condition are shown. In invoking the view, you can choose to list all the attributes or view one or more attributes. The grayed arrow indicates that you can stipulate which attributes you want to view.

Figure A-8 The Branching Paths of an OR Condition

Text description of the illustration uml007.gif

In Figure A-9, the black dashed line and arrow indicate that the targeted operation is required. The gray dashed line and arrow indicate that the targeted operation is optional. In this example, executing

• write append

on a LOB requires that you first

• SELECT a LOB

You may optionally choose to

• OPEN a LOB or get chunk size

The diagram shows that if you open a LOB, you must also close it.

Figure A-9 Required and Optional Operations

Text description of the illustration uml011.gif

State Diagrams

A state diagram presents the attributes of a view. Attributes of a view have two states--visible or invisible. In this example, a state diagram (the Queue, Name, Address, and Protocol boxes in the gray area at the bottom of the figure) is added below a use case diagram to show all the attributes of the view.

Figure A-10 shows that the view is for querying queue subscribers. You can stipulate one attribute, some combination of the four attributes, or all four attributes.

Figure A-10 Use Case and State Diagram to Show Attributes of a View

Text description of the illustration adque031.gif

The class diagram in Figure A-11 shows:

• Whether classes, interfaces, and exceptions are entailed in the interrelationship by means of the <<>>, stereotype, such as <<interface>>
• The name of the package in which the class is found, such as oracle.jms
• The name of the class, such as AQjmsConnection

Figure A-11 A Class Diagram Representing Classes, Interfaces, and Exceptions

Text description of the illustration adque371.gif