Smalltalk and Object Orientation: an Introduction - Free

DrawingView
model
SmallDraw
drawingView
drawingModel
controller
defaultController
DrawingController
view
model
DrawingModel
style
nodes
anOrderedCollection
BoxWidget
origin
extent
border
CircleWidget
origin
extent
border
LineWidget
origin
extent
border
Figure 29.5: The object relationships
However, what inherits from what is only part of the story for any object oriented application.
Figure 29.5 illustrates the next part of the story: how the objects relate to one another within a working
application (note this diagram only presents the user defined objects within the application. There are
other objects such as the UIBuilder which are also involved but which are generated by
VisualWorks).
As you can see from Figure 29.5 the SmallDraw application model has instance variables which
possess links to the drawingModel and the drawingView. The presence of a link to the
drawingView object allows the window building facilities associated with the SmallDraw window to
inform the view that it needs to redisplay itself. The link to the drawingModel allows the effects of
user interaction outside the view to be passe d onto it. For example, the user selects which object to add
to the drawing by selecting one of three buttons at the top of the SmallDraw window ( Figure 29.1). The
user’s choice must be passed through to the drawingModel so that it can add the appropriate drawing
object to its list of displayed objects.
It is also worth noting that if you examine the
DrawingModel, DrawingView and
DrawingController you will see that these three classes exhibit the classic MVC structure. T he
View and the Controller have knowledge of each other and the Model, whereas the Model
knows nothing about the View or the Controller. This is because VisualWorks records the View
as a dependent of the Model when the view records the presence of the mode l (using the super
model: aModel. message expression).
Finally it is worth pointing out that in this case the DrawingModel is a relatively simple model
which merely records a set of nodes in an OrderedCollection. These nodes could be anything and
could be displayed in any way. It is the nodes themselves which determine what they should look like
when drawn.
29.4 The interactions between objects
We have now examined what the physical structure of the application is but not how the objects within
that application interact. In many situations this can be extracted from the source code of the application
(with varying degree’s of difficulty). However, in the case of a custom view within an
ApplicationModel, it is useful to explicitly describe the system interaction. There are four
different interactions in the system and each will be considered separately.
We shall adopt the following conventions for the diagrams illustrating the interactions between the
objects (these diagrams are based on the mechanism diagrams described by [Rumbaugh et al 1991]):
• a solid arrow indicates a message send,
• a dashed arrow indicates instance creation,
• a square box indicates a class,
• a round box indicates an instance,
• a name in brackets indicates the type of instance,
• numbers are used to indicate the sequence of message sends.
247