Smalltalk and Object Orientation: an Introduction - Free

Window
abstract
+size : Area = (10,10)
#visible : Boolean = false
+$defaultSize : Rectangle
#$maxSize : Rectangle
-grid : GraphicsContext
Key
$ Class responsibility
+ Public
# Protected
- Private
+display() {abstract}
+hide()
+$new()
-displayOn(grid)
Figure 17.4: Class with additional annotations
Attributes and operations can also have their intended scope indicated in the c lass definition. This can
be useful even for languages such as Smalltalk which do not support concepts such as Public, Private
and Protected attributes and operations. The absence of any symbol at all in front of an attribute or
operation indicates that th e element is a public instance attribute or operation for that class. The
significance of this depends on the language. The range of symbols currently supported is indicated in
Figure 17.4 and combinations of symbols ca n be used to indicate (for example) that a method is a class
side public method (such as +$new() - a class side operation intended for instance creation).
repMobile1 : Car
name = XK8
age = 1
fuel = petrol
Figure 17.5: An object (structured cloud)
An object is drawn as a hexagon with straight sides and a slight peak at the top and bottom (as
illustrated in Figure 17.5). For those familiar with the Booch clouds this can be thought of as a
structured cloud otherwise just accept that this is the object symbol 10 . The object symbol can be divided
into two sections. The top section indicates the name of the object and its class in the format
objectName : className. For example, in Figure 17.5 the object is repMobile1 and the class is Car (see
Figure 17.3 for the definition of the class Car). The object name is optional although the class name is
compulsory. The lower compartment contain s a list of attributes and their values in the format name
type = value (although the type is usually omitted). For example in Figure 17.5 the three attributes
defined in Figure 17.3 for a Car have the values XK8, 1 and petrol. The bottom compartment can be
suppressed for clarity. It is also possible to indicate how many objects of a particular class are
anticipated. This is done by indicating the maximum value, range etc. in the top compartment. The lack
of any number indicates that a single object is intended.
17.4.2 Associations
Relationships between classes and objects are represented by associations drawn as a solid line between
classes or objects (for example see Figure 17.6). An association between classes may have a name with
an optional small “direction arrow head” (which is drawn as an arrow head on the association) showing
which way it is to be read. For example in Figure 17.6 the relationship is called hasEngine and is read
from the class Car to the class Engine. In addition each end of an association is a role. Roles may have
a name illustrating how its class is viewed by the other class. In Figure 17.6 the engine sees the car as
being a name and the car sees the engine as being of a specified type (e.g. Petrol, Diesel, Electric etc.).
10
Note that as of September 1996, the 0.91 addendum to the UML states tha t objects are now drawn as rectangles with the
object name and its class name (separated by a colon) underlined. This is a major notational change which the authors of the
UML wish to make so that they do not have to invent different symbols every time the y have a type (or class) - instance
relationship. However this means that the distinction between objects and classes in diagrams is minimal and can easily lead to
confusion. In an attempt to make objects clearly distinguishable in this, and subsequent cha pters, we shall continue to use the
structured cloud symbol for objects.
141