Weisfeld. The object-oriented thought process
Подождите немного. Документ загружается.
194
Chapter 10 Creating Object Models with UML
Cabbie
–companyName: String
+Cabbie:
+Cabbie:
+setName: void
+getName: String
+giveDirections: void
–turnRight: void
–turnLeft: void
+getCompanyName: String
–name: String
Attributes
Class Name
Constructors
Methods
Figure 10.1 A UML diagram of the Cabbie class.
blueprints. In a nutshell, UML offers a way to graphically represent and manipulate an ob-
ject-oriented (OO) software system. It is not only the representation of the design of a
system, but a tool to assist in this design.
UML is actually a synthesis of different modeling languages developed independently
by Grady Booch, James Rumbaugh, and Ivar Jacobson, affectionately called the Three
Amigos.The software company Rational brought the three modeling languages together
under one roof—thus the name Unified Modeling Language.As stated above, object
modeling is simply one part of UML.
However, it is important not to link UML and OO development too closely. In his ar-
ticle “What the UML Is—and Isn’t,” Craig Larman states:
Yet unfortunately, in the context of software engineering and the UML diagramming language,
acquiring the skills to read and write UML notation seems to sometimes be equated with skill
in object-oriented analysis and design. Of course, this is not so, and the latter is much more
important than the former. Therefore, I recommend seeking education and educational materi-
als in which intellectual skill in object-oriented analysis and design is paramount rather than
UML notation or the use of a case tool.
Although UML is very important, it is much more important to learn the OO skills first.
Learning UML before learning OO concepts is similar to learning how to read an elec-
trical diagram without first knowing anything about electricity.
The Structure of a Class Diagram
A class diagram is constructed of three different parts: the class name, the attributes, and
the methods (constructors are considered methods).The class diagram is essentially a
rectangle that separates these three parts with horizontal lines.This book often uses a
cabbie metaphor as an illustration. Figure 10.1 shows the UML class diagram represent-
ing this class.
195
The Structure of a Class Diagram
This UML diagram corresponds exactly to the following Java code:
/*
This class defines a cabbie and assigns a cab
*/
public class Cabbie {
// Place the name of the company here
private static String companyName = “Blue Cab Company”;
// Name of the cabbie
private String name;
// Car assigned to cabbie
// Default constructor for the cabbie
public Cabbie() {
name = null;
myCab = null;
}
// Initializing the constructor for the cabbie
public Cabbie(String iName, String serialNumber) {
Name = iName;
myCab = new Cab(serialNumber);
}
// Set the name of the cabbie
public void setName(String iName) {
name = iName;
}
// Get the name of the cabbie
public String getName() {
return name;
}
// Give the cabbie directions
public void giveDirections(){
}
// Cabbie turns right
private void turnRight(){
}
// Cabbie turns left
private void turnLeft() {
}
// Get the name of the company
public static String getCompanyName() {
return companyName;
}
}
Take a moment to look at the code and compare it to the UML class diagram. Notice
how the class name, attributes, and methods in the code relate to the designation in the
class diagram. Really, that is all there is to the class diagram as far as the structure goes.
However, there is a lot more information to be gleaned from the diagram.This informa-
tion is discussed in the following sections.
Attributes and Methods
Besides presenting the structure of the class, the class diagram also presents information
about the attributes and methods.
Attributes
Normally, attributes are not thought of as having signatures; methods get all the credit.
However, an attribute has a type, and this type is represented in the class diagram. Con-
sider the two attributes that are in the Cabbie example:
-companyName:String
-name:String
Both of these attributes are defined as strings.This is represented by the name of the
attribute followed by the type (in these cases, String).There could have been attributes
that were defined as int and float as well, as in this example:
-companyNumber:float
-companyAge:int
By looking at the class diagram, you can tell the data type of the parameter.You can
also tell that the attributes are declared as private because of the minus sign (-) that pre-
cedes them.A plus sign (+) would denote that they were public, which should evoke a
gag reflex. Based on all discussion in the previous chapters, we know that all attributes
should be declared as private. Every now and then someone makes a case for the use of
public attributes, but the approach taken in this book is to always make attributes private.
196
Chapter 10 Creating Object Models with UML
197
Access Designations
Methods
The same logic used with attributes works for methods. Rather than express the type, the
diagram shows the return type of the method.
If you look at the following snippet from the Cabbie example, you can see that the
name of the method is presented, along with the return type and the access modifier (for
example, public, private):
+Cabbie:
+giveDirections:void
+getCompanyName:String
As you can see here, in all three cases the access modifier is public (designated by the
plus sign). If a method were private, there would be a minus sign. Each method name is
followed by a colon that separates the method name from the return type.
It is possible to include a parameter list, in the following manner:
+getCompanyName(parameter-list):String
Commas separate the parameters in the parameter list.
+getCompanyName(parameter1, parameter2, parameter3):String
I like keeping the object models as simple as possible.Thus, I normally include only
the class name, attributes, and methods in the class diagrams.This allows us to concentrate
on the big-picture of the design and does not place focus on details. Including too much
information (like parameters) in the class diagrams makes the object-model difficult to
read.This is one of those issues that depends on your specific tastes.
Access Designations
As mentioned previously, the plus signs (+) and minus signs (-) to the left of the attributes
and methods signify whether the attributes and methods are public or private.The attrib-
ute or method is considered private if there is a minus sign.This means that no other class
can access the attribute or method; only methods in the class can inspect or change it.
If the attribute or method has a plus sign to the left, the attribute or method is public,
and any class can inspect or modify it. For example, consider the following:
-companyNumber:float
+companyAge:int
In this example, companyNumber is private, and only methods of its class can do any-
thing with it. However, companyAge is public, and thus it is fair game for any class to ac-
cess and modify it.
If no access designation is present in the code, the system considers the access to be the
default, and no plus or minus is used:
companyNumber:float
companyAge:int
In Java, the default type of access is protected. Protected access means that only
classes in the package can access the attribute or method.A Java package is a collection
of related classes that are intentionally grouped together by the developer (see http://
msdn2.microsoft.com/en-us/library/ms173121.aspx).
In .NET the access modifiers, per Microsoft’s MSDN, are as follows:
n
public—The type or member can be accessed by any other code in the same as-
sembly or another assembly that references it.
n
private—The type or member can only be accessed by code in the same class or
struct.
n
protected—The type or member can only be accessed by code in the same class
or struct, or in a derived class.
n
internal—The type or member can be accessed by any code in the same assem-
bly, but not from another assembly.
Inheritance
To understand how inheritance is represented, consider the Dog example presented in
Chapter 7,“Mastering Inheritance and Composition.” In this example, the class
GoldenRetriever inherits from the class Dog as shown in Figure 10.2.This relationship is
represented in UML by a line with an arrowhead pointing in the direction of the parent
or superclass.
The notation is straightforward, and when the line with the arrowhead is encountered, an
inheritance relationship is indicated.
198
Chapter 10 Creating Object Models with UML
Dog
barkFrequency: int
pantRate: int
bark: void
pant: void
GoldenRetriever
retrievalSpeed: int
retrieves: void
Figure 10.2 UML diagram of
the Dog hierarchy.
199
Interfaces
Indicating Interface Inheritance
A dashed line with an arrowhead indicates an interface, which is discussed in the next
section.
Because Java is used for the examples in this book, we do not have to worry about multi-
ple inheritance.
However, several subclasses can inherit from the same superclass.Again, we can use the
Dog example from Chapter 7 (see Figure 10.3).
This example illustrates two concepts when modeling an inheritance tree. First, a super-
class can have more than one subclass. Second, the inheritance tree can extend for more
than one level.The example in Figure 10.3 shows three levels.We could add further levels
by adding specific types of retrievers, or even by adding a higher level by creating a
Canine class (see Figure 10.4).
Multiple Inheritance
If you are designing in languages such as Eiffel and C++, multiple inheritance is incorpo-
rated into the language and is in play as part of the overall design.
GoldenRetriever
retrievalSpeed: int
retrieves: void
Basenji
huntEfficiency: int
hunts: void
LhasaApso
guardEfficiency: int
guards: void
YodelingDog
yodelFrequency: int
yodels: void
BarkingDog
barkFrequency: int
bark: void
Dog
pantRate: int
pant: void
Figure 10.3 UML diagram of the expanded
Dog hierarchy.
200
Chapter 10 Creating Object Models with UML
GoldenRetriever
retrievalSpeed: int
retrieves: void
Basenji
huntEfficiency: int
hunts: void
LhasaApso
guardEfficiency: int
guards: void
YodelingDog
yodelFrequency: int
yodels: void
BarkingDog
barkFrequency: int
bark: void
Hyena
pantRate: int
pant: void
Fox
pantRate: int
pant: void
Dog
pantRate: int
pant: void
Canine
Figure 10.4 UML diagram of the Canine hierarchy.
Interfaces
Because interfaces are a special type of inheritance, the notations are similar and can cause
some confusion. Earlier we said that a line with an arrowhead represents inheritance.An
interface is also represented by a line with an arrowhead—but the arrowhead is connected
to a dashed line.This notation indicates the relationship between inheritance and inter-
faces, but also differentiates them.Take a look at Figure 10.5, which is an abbreviated ver-
sion of an example in Chapter 8,“Frameworks and Reuse: Designing with Interfaces and
Abstract Classes.”The Dog class inherits from the class Mammal and implements the inter-
face Nameable.
+getName:String
+setName:void
interface
Nameable
type: String
+getType:String
+setType:void
Mammal
name: String
+getName: String
+setName: void
Dog
size: String
+getSize: String
+setSize: void
Head
Figure 10.5 UML diagram of an interface relationship.
201
Composition
Composition
Composition indicates that a has-a relationship is being used.When inheritance is not the
proper design choice (because the is-a relationship is not appropriate), composition is nor-
mally used.
Chapter 9,“Building Objects,” discusses two different types of composition: aggregations
and associations. Composition is used when classes are built with other classes.This can
happen with aggregation when a class is actually a component of another class (as a tire is
to a car). Or it can happen with association when a class needs the services of another class
(for example, when a client needs the services of a server).
Aggregations
An aggregation is represented by a line with a diamond at the head. In the car example of
Chapter 9, to represent that a steering wheel is part of a car, you use the notation shown
in Figure 10.6.
As with the inheritance tree, there is no limit (theoretically) to the number of levels of ag-
gregation you can represent. In the example seen in Figure 10.7, there are four levels. No-
tice that the various levels can represent various aggregations. For example, although a
stereo is part of the car, the radio is part of the stereo, and the tuner is part of the radio.
Associations
Although aggregations represent parts of a whole, meaning that one class is logically built
with parts of another, associations are simply services provided between classes.
As mentioned earlier, a client/server relationship fits this model.Although it is obvious
that a client is not part of a server, and likewise a server is not part of a client, they both
depend on each other. In most cases, you can say that a server provides the client a service.
Car
SteeringWheel
Figure 10.6 UML diagram
representing composition.
202
Chapter 10 Creating Object Models with UML
Car
StereoEngine
Pistons SparkPlugs Radio
Tuner
Cassette Handle
Door
Figure 10.7 An expanded composition UML diagram.
In UML notation, a plain line represents this service, with no shape on either end (see
Figure 10.8).
Note that because there is no shape on either end of the line, there is no indication
about which way the service flows.The figure shows only that there is an association be-
tween the two classes.
To illustrate, consider the example of the computer system from Chapter 9. In this case,
there are multiple components, such as a computer, monitor, scanner, keyboard, and
mouse. Each is a totally separate component that interacts, to some degree, with the com-
puter itself (see Figure 10.9).
The important thing to note here is that the monitor is technically part of the com-
puter. If you were to create a class for a computer system, you could model it by using
aggregation. However, the computer represents some form of aggregation, as it is made
up of a motherboard, RAM, and so on (see Figure 10.10).
203
Composition
Client
Server
Figure 10.8 UML diagram representing an association.
Computer
Monitor Scanner
Keyboard
Mouse Printer
Figure 10.9 An expanded UML diagram representing association.
Computer
Motherboard RAM
Figure 10.10 UML representation of aggregation.