Representing Structure
Structural concepts, such as class and interface, are fundamental to both Java and the UML. This section identifies how these concepts map to Java and the UML.
Class
In the UML, a Java class is represented via a compartmentalized rectangle. Three horizontal compartments are used:
Attribute compartment: Lists variables defined on the class, if any
Operations compartment: Shows methods defined on the class, if any
Figure 4-1 shows a simple Java class without any variables and methods.
Figure 4-1. A class in Java and the UML
An abstract class is identified by italicizing the class name.
A stereotype may be used alongside a class name to unambiguously identify it as a specific type of Java class, such as an applet (we discussed the concept of stereotypes in Chapter 2). You can also use stereotypes to identify specific types of classes (such as <<Business Entity>>) in your particular domain vocabulary to make the classes more meaningful wherever they appear.
A word of caution: if you are using a UML tool for Java code generation, note that the tool may use the stereotyping mechanism to affect code generation.
Figure 4-2 shows a stereotyped class.
Figure 4-2. A stereotyped class
Variable
Java variables may manifest themselves in various ways in the UML. This is one instance where modeling adds a dimension not apparent in the source code.
The simplest form of variable declaration is to list it within a class's attri bute compartment. Underlining the attribute indicates the static nature of the variable. The visibility of an attribute is indicated by preceding the attribute with + for public, # for protected, and - for private. Figure 4-3 shows a class with attributes.
Figure 4-3. A class with attributes
This form of declaration may come about for basic data that is needed for the class. Such variables do not generally have any specific significance from a broader modeling perspective. Examples include variables you require for storing basic pieces of information that make an object what it is, variables required for internal logic, and so on. Such variables are based on objects that usually cannot be decomposed further.
Variables may also manifest themselves due to an object's relationships with other objects (for example, a collection of some sort). We discuss such relationships and their usage in the “Representing Relationships” section later in this chapter.
Method
Methods are the equivalent of operations on a class in the UML. They are shown in the third compartment for a class. Visibility scope of UML operations is defined using the same convention used for class attributes, as described in the “Variables” section.
Underlining the operation's name is used to differentiate a static method. Listing the operation in italics in the operation compartment shows that the method is abstract. You can, of course, hide or show details depending on the significance of the detail. For instance, in Figure 4-4, the full operation signatures are not shown by choice.
Figure 4-4. A class with attributes and operations
Object
Although both Java and UML have the concept of an object, there is no direct mapping between a UML object and Java code. This is so because objects are dynamic entities, which are based on class definitions. Java applications are written in terms of Java classes that result in the creation of Java objects when the application is actually executed.
In the UML, objects are used to model dynamic aspects of the system via interaction diagrams. A rectangle with an object name, and/or a class name, is used as the notation for an object. Sometimes it is desirable to show the attribute values for the object in a given situation. This can be done using a rectangle with two partitions showing the attributes of the class. See Figure 4-5.
Figure 4-5. An object
Interface
In the UML, a Java interface is depicted as a class stereotyped with <<interface>>. Stereotyped classes may optionally have icons associated with them. In the case of an interface, the UML iconic representation is a small circle. This iconic representation is commonly used for representing Java interfaces when modeling in the UML.
Figure 4-6 shows the standard interface representation.
Figure 4-6. An interface
Figure 4-7 shows an alternate and more compact form of representation.
Figure 4-7. Alternate representation of an interface in the UML
Either approach is acceptable from a modeling perspective and really comes down to your individual preference. This book makes extensive use of the icon representation for diagrams presented.
Package
A Java package maps to a UML package. Packages may be logical, meaning you may only use them as a grouping mechanism. Packages can also be physical, meaning they result in a physical directory in the file system.
The UML package is represented as a folder, as shown in Figure 4-8. Packages may be stereotyped to distinguish the type of package, for example, using <<subsystem>> to identify the package as a subsystem. (A subsystem refers to a group of UML elements and represents a behavioral unit in a model. It can have interfaces as well as operations. Subsystems are typically significant from an analysis and design perspective. There is no direct mapping between a subsystem and a Java language construct.)
Figure 4-8. A package
