Preface, 2 of 2

Use Cases Diagram Elements

Use cases are generally employed to describe the set of activities that comprise the sum of the application scenarios.

Figure 0-3 Use Cases

The following sections describe how to interpret how the elements of a use case diagram as applied in different cases.

Graphic Element Description

Each primary use case is instigated by an actor ('stickman') that could be a human user, an application, or a sub-program.
The actor is connected to the primary use case which is depicted as an oval (bubble) enclosing the use case action.
The totality of primary use cases is described by means of a Use Case Model Diagram.

Primary use cases may require other operations to complete them. In this diagram fragment:

specify queue name

Is one of the sub-operations, or secondary use cases, necessary to complete

ENQUEUE a message

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

Secondary use cases that have drop shadows expand (they are described by means of their own use case diagrams). There are two reasons for this:
(a) It makes it easier to understand the logic of the operation.
(b) It would not have been possible to place all the operations and sub-operations on the same page.
In this example, specify message properties, specify options, and add payload are all expanded in separate use case diagrams.

This diagram fragment shows the use case diagram expanded. While the standard diagram has the actor as the initiator), here the use case itself is the point of departure for the sub-operation.
In this example, the expanded view of add payload represents a constituent operation of ENQUEUE a message.

This convention (a, b, c) shows that there are three different ways of creating a table that contains LOBs.

This fragment shows use of a NOTE box, here distinguishing which of the three ways of creating a table containing LOBs.

Graphic Element	Description
	Each primary use case is instigated by an actor ('stickman') that could be a human user, an application, or a sub-program. The actor is connected to the primary use case which is depicted as an oval (bubble) enclosing the use case action. The totality of primary use cases is described by means of a Use Case Model Diagram.
	Primary use cases may require other operations to complete them. In this diagram fragment: specify queue name Is one of the sub-operations, or secondary use cases, necessary to complete `ENQUEUE` a message Has the downward lines from the primary use case that lead to the other required operations (not shown)
	Secondary use cases that have drop shadows expand (they are described by means of their own use case diagrams). There are two reasons for this: (a) It makes it easier to understand the logic of the operation. (b) It would not have been possible to place all the operations and sub-operations on the same page. In this example, specify message properties, specify options, and add payload are all expanded in separate use case diagrams.
	This diagram fragment shows the use case diagram expanded. While the standard diagram has the actor as the initiator), here the use case itself is the point of departure for the sub-operation. In this example, the expanded view of add payload represents a constituent operation of `ENQUEUE` a message.
	This convention (a, b, c) shows that there are three different ways of creating a table that contains `LOBs.`
	This fragment shows use of a NOTE box, here distinguishing which of the three ways of creating a table containing `LOBs`.

Graphic Element

Description
This drawing shows two other common sees of NOTE boxes:
(a) A way of presenting an alternative name, as in this case the action SELECT propagation schedules in the user schema is represented by the view USER_QUEUE_SCHEDULES
(b) The action list attribute names is qualified by the note to the user that you must list at least one attribute if you elect not to list all the propagation schedule attributes.

Graphic Element Description

The dotted arrow in the use case diagram indicates dependency. In this example, free a temporary LOB requires that you first create a temporary LOB.
This means that you should not execute the free operation on a LOB that is not temporary.
What you need to remember is that the target of the arrow shows the operation that must be performed first.

Use cases and their sub-operations can be linked in complex relationships.
In this example of a callback, you must first REGISTER for notification in order to later receive a notification.

Graphic Element

Description
In this case, the branching paths of an OR condition are shown. In invoking the view, you may either choose to list all the attributes or to view one or more attributes. The fact that you can stipulate which of the attributes you want made visible is indicated by the grayed arrow.

Graphic Element

Description
Not all lined operations are mandatory. While the black dashed-line and arrow indicate that you must perform the targeted operation to complete the use case, actions that are optional are shown by the grey dashed-line and arrow.
In this example, executing WRITEAPPEND on a LOB requires that you first SELECT a LOB.
As a facilitating operations, you may choose to OPEN a LOB and/or GETCHUNKSIZE.
However, note that if you OPEN a LOB, you will later have to CLOSE it.

Graphic Element Description

Use Case Model Diagrams summarize all the use cases in a particular domain, such as Internal temporary LOBs. Often, these diagrams are too complex to contain within a single page.
When that happens we resort to dividing the diagram into two parts. Please note that there is no sequence implied in this division.

In some cases, we have had to split a diagram simply because it is too long for the page. In such cases, we have included this marker.

Hot Links From Use Case Diagram to Use Case Diagram

The html and pdf versions of the use case diagrams include hot link buttons.When you need the following:

To Jump Back:

To the referring use case diagram , or to the "Use Case Model Diagram" (the 'parent' of all diagrams), click on the middle or left blue buttons respectively.
To Jump Forward:

From each use case, to the 'child' diagram, typically noted as 'a', 'b', or 'c', click on the [a], [b], or [c] blue button respectively. From the Use Case Model Diagram ('parent' diagram) to specific use cases, click on the blue-circled use case of interest.

Note there is one "Use Case Model Diagram" ("parent") in each of chapters 9, 10, and 11, namely:

Your Comments Are Welcome

We value and appreciate your comment as an Oracle user and reader of our manuals. As we write, revise, and evaluate our documentation, your opinions are the most important feedback we receive.

You can send comments and suggestions about this manual to the information development department at following e-mail address:

infodev@us.oracle.com

If you prefer, you can send letters or faxes containing your comments to the following address:

ST/Oracle8i Generic Documentation

Oracle Corporation

500 Oracle Parkway

Redwood Shores, CA 94065

Fax: (650) 506-7228