UML

Although the construction industry has had its own notation system for a long time, software development, at the beginning, did not have a standard design notation. Eventually, the Rational Software Corporation hired Grady Booch, Ivar Jacobson, and Jim Rumbaugh, pioneers in the object-oriented programming (OOP) notation movement, to create a unified system. They invented what is now called UML. These pioneers, and those on the sidelines, were groping for industry guidelines and object management specifications to provide a common framework for application development. After all, OOP's goals are reusability, portability, and interoperability of object based software in distributed, heterogeneous environments. How can you achieve those goals if one engineer can't share a software description with another so that any professional in the same industry can understand it?

Booch, Jacobson, and Rumbaugh started the UML effort at Rational and were its original chief methodologists. Today, UML is an OMG standard, with hundreds of partners contributing, including the original UML author, Rational Software Corporation.

UML is the language the software blueprint is written in. Furthermore, the names of classes, fields, and methods are exactly what you use in code, so UML isn't so abstract that it is good only for large projects; it is also helpful for your certification project. UML is a language for specifying, constructing, visualizing, and documenting a software system's artifacts. Today it is used for all sorts of things, but its original motivation was software design.

The OMG standard says that an artifact "represents a physical piece of information that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files. An Artifact may constitute the implementation of a deployable component."

Fortunately, the timing of UML's adoption coincides with Java's rising prominence. UML is a great choice for designing Java, which is why I recommend you start using it if you haven't already done so. Most software development departments throughout the industry are adopting it quickly.

Standard Graphical Diagrams

UML defines the following graphical diagrams:

• Use case diagram

• Class diagram

• Package Diagrams

• Object Diagrams

• Behavior diagrams, which can be further classified into the following categories:

  • Statechart diagrams

  • Activity diagrams

  • Interaction diagrams, which have two types:

  • Sequence diagrams

  • Collaboration diagrams

• Implementation diagrams, which are divided into two categories:

  • Component diagrams

  • Deployment diagrams

You won't use all these diagrams for every project, but each has its benefits, so just be aware of how to use them. Most of the ones you can choose for your solution are briefly explained later in this appendix.

Other names are sometimes used for these graphical diagrams, but the names in the preceding list are the official or canonical ones.

The following sections describe the more common diagrams. They are the ones you will most likely use to design your project for this certification.

Class Diagram

A class diagram is a standard UML model, the blueprint from which objects are produced at runtime. As you'll remember, a class is a definition, but an object is an instance of that class.

The OMG standard defines the UML class diagrams in this way: "UML class diagrams are used to present the UML metamodel, its concepts (metaclasses), relationships, and constraints. Definitions of the concepts are included." The class diagram has three parts :

• Class name

• Class attributes (fields or variables )

• Behaviors (methods)

For a simple example of mapping class diagrams to Java code, see jGuru's bank reservation example at http://developer.java.sun.com/developer/onlineTraining/rmi/exercises/UMLDefinition.

Figure A.1 illustrates a general diagram of three classes.

Figure A.1. A typical UML class diagram.

Use Case Diagram

A use case diagram describes what a system does from the viewpoint of an external observer: It describes a discrete event. This type of diagram shows you what is happening, not how it is done. Notice in Figure A.2 that people are called actors and depicted as stick figures, and the use cases are ovals. The lines that link actors to use cases are referred to as communications .

Figure A.2. A typical UML use case diagram.

Statechart Diagram

Statechart diagrams represent the behavior of dynamic entities by specifying their responses to receiving event instances. A statechart diagram shows an object's possible states and the transitions that cause a change in state. The sample statechart diagram in Figure A.3 models the process of reserving a seat on a plane, bus, or train. A successful reservation consists of requesting a seat, having the system check for an available seat, and then reserving that seat if it is available or, if the seat is locked, reserving that seat when the lock is removed.

Figure A.3. A typical UML statechart diagram.

States are represented by rounded rectangles, and arrows from one state to another represent transitions in state. Events that trigger transitions are described by written notations next to transition arrows.

Activity Diagram

An activity diagram is just a flowchart that uses a defined notation (see Figure A.4). Notice how similar activity diagrams are to statechart diagrams. The difference is that a statechart diagram describes actual objects and the details of a process they interact with. An activity diagram is less detailed and tries to convey the flow of activities that make up a given process.

Figure A.4. A typical UML activity diagram.

Sequence Diagram

Sequence diagrams illustrate the action that takes place within a system. A sequence diagram presents an Interaction, which is defined in UML as a set of Messages between Roles. A sequence diagram has two dimensions:

• The vertical axis represents time (time elapses as you read down the diagram).

• The horizontal axis represents different instances of time and communication events.

A sequence diagram, shown in Figure A.5, details how operations are performed, which object calls another object, and when (logically) an operation is carried out. Although there is no significance to the horizontal ordering of instances, objects are listed from left to right according to when they get involved in the process (also called the "message sequence").

Figure A.5. A typical UML sequence diagram.

Component Diagram

A component is a code module, which is a physical analog of a class diagram. As database folks know, there are the logical model and the physical model for a data schema. For code, however, usually just the physical application architecture is discussed.

A component diagram (see Figure A.6) shows the dependencies among software components , including the artifacts that implement these dependencies, such as source code files, binary code files, executable files, and scripts. You can use a diagram containing component types to show static dependencies. For example, a compiler dependency between programs could be shown as dashed arrows to represent a static dependency. So if a client component is dependent on a third-party component, you would show it in a component diagram with a dashed arrow between the client and the third-party component.

Figure A.6. A typical UML component diagram.