Smalltalk and Object Orientation: an Introduction - Free

classes, while object diagrams contain objects, but that it is possible to mix the two. However, they
discuss both under the title class diagrams. Therefore, to avoid confusion, we adopt the term Object
Model to cover both sets of diagrams (followi ng the approach adopted in both the Booch and OMT
methods).
17.4.1 Classes and objects
A class is drawn as a solid -outline rectangle with three components. The class name (in bold type) is in
the top part, a list of attributes (with optional types and initial val ues) in the middle part and a list of
operations (with argument types and return values) in the bottom part. Figure 17.3 illustrates two
classes, one for a class Car and one for a class File. The Car class possesses thr ee attributes called
name, age and fuel. Their types are string, integer and string respectively. The class also possesses four
operations start(), lock() and brake(), plus accelerate which takes a single parameter “to” which is an
integer and represents the new speed.
Car
name: string
age: integer
fuel: string
start()
lock()
accelerate(to:integer)
brake()
File
fileName: string
size: integer
lastUpdate: string
print()
Figure 17.3: Class with attributes and operations
An attribute has a name and a type specified in the format name: type = initialValue. The name and
type are strings tha t are ultimately language dependent. The initial value is a string representing an
expression in the target language. Operations have a name and may take one or more parameters and
return a value. The format of an operation is name (parameter : type = defa ultValue, ...): resultType .
The operation’s constituent parts are strings that are language dependent.
The attribute and operation compartments can be hidden from view to reduce the detail shown in a
diagram. Omitting a compartment says nothing about that part of the class definition. However, leaving
a compartment blank implies that there are no definitions for that part of the class. Additional language
dependent and user-defined information can also be included in each compartment in a textual format.
The intention of such additions is to clarify any element of the design in a similar manner to a comment
in source code.
The class stereotype can be shown as a normal -font text string in between > centered above the
class name (see Figure 17.4). A stereotype tells the reader what “kind” of class it is. Examples of
stereotypes are exceptions, controllers, interfaces etc. However, UML makes no assumptions about the
range of stereotypes which exist and the designer is therefore free to develop their own. Other (language
specific) class properties can also be indicated in the class name compartment. For example in Figure
17.4 the Window class is an abstract class, thus the label abstract is printed below (and to the left) of the
class name.
140