2
Visual Modelling for Software Development

This chapter contains information on Unified Modelling Language notation and diagrams. The topics include:

Why Employ Visual Modelling?

When application developers gather together to discuss a project, it is only a matter of minutes before someone starts sketching on a white board or pad in order to describe the problems and outline solutions. They do so because they instinctively recognize that a mixture of graphics and text is the fastest way to delineate the complex relationships entailed in software development. Participants in these meetings often end up copying down these sketches as a basis for later code development.

Unified Modelling Language

One problem with this process is that whoever creates the diagrams has to invent a notation to adequately represent the issues under discussion. Fortunately, many of the types of problems are familiar, and everyone who is in the room can ask questions about what is meant by the lines and edges. But this raises further problems: What about members of a development team who are not present? Indeed, even people who were there may later lose track of the logic underlying their notes.

To counter these difficulties, this Application Developer's documentation set uses a graphic notation defined by the Unified Modelling Language (UML), an industry-wide standard specifically created for modelling software systems. Describing the UML in its entirety is beyond the scope of the book. However, we do explain the small subset of the UML notation that we employ.

Illustrations and Diagrams

Software documentation has always contained figures. What, then, is the difference between UML-based diagrams used for modelling software development and the figures that have traditionally been used to illustrate different topics? We make a distinction between two kinds of figures in this book:

Illustrations -- used to describe technology to make it more understandable.
Diagrams -- used for actual software modelling.

The two different types are always distinguished in the figure title. The term diagram is always used for the following examples:

Example of an Illustration

Figure 2-1 illustrates the macro-steps entailed in creating a multimedia application. While it may be useful in planning software development from an organizational standpoint, it does not provide any help for the actual coding.

Figure 2-1 Example of an Illustration: The Multimedia Authoring Process

Example of A Diagram

In contrast to Figure 2-1, Figure 2-2 describes what you must do to enqueue a message using Oracle Advanced Queuing: You must specify a queue name, specify the message properties, specify from among various options, and add the message payload. This diagram is then complemented by further diagrams, as indicated by the drop shadows around the latter three ellipses.

Figure 2-2 Use Case Diagram: Enqueue a Message

Use Cases

The UML contains a number of different kinds of diagrams.This release of the Application Developer's documentation set introduces the UML into documentation principally by way of use cases. Use cases are generally employed to describe the set of activities that comprise the sum of the application scenarios.

Figure 2-3 Use Cases

The following section is a selection of UML elements that are used in this book.

Use Case Diagrams

Graphic Element Description

This release of the documentation introduces and makes heavy use of the Use Case Diagram. 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 release of the documentation introduces and makes heavy use of the Use Case Diagram. 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`.