SADP_21CS741-M4

Maharaja Institute of Technology Mysore Department of Information Science & Engineering
Module 4
Interactive Systems and the MVC Architecture
Introduction
When we have a complex problem, we need a framework or structure within which to
operate. For the problem of creating software systems, such a structure is provided by
choosing software architecture. In this Module, we start by describing a well-known
software architecture (sometimes referred to as an architectural pattern) called the
Model–View– Controller or MVC pattern.
The MVC Architectural Pattern
ud
 The model view controller is a relatively old pattern that was originally
introduced in the Smalltalk programming language. As one might suspect, the
pattern divides the application into three subsystems: model, view, and
controller.
 The architecture is shown in Fig. 11.1. The pattern separates the application
object or the data, which is termed the Model, from the manner in which it is
lo
rendered to the end-user (View) and from the way in which the end-user
manipulates it (Controller).
 In contrast to a system where all of these three functionalities are lumped
together (resulting in a low degree of cohesion), the MVC pattern helps
produce highly cohesive modules with a low degree of coupling. This facilitates
greater flexibility and reuse. MVC also provides a powerful way to organise
systems that support multiple presentations of the same information.
C
 The model, which is a relatively passive object, stores the data. Any object can
play the role of model. The view renders the model into a specified format,
typically something that is suitable for interaction with the end user.
 For example, if the model stores information about bank accounts, a certain
tu
view may display only the number of accounts and the total of the account
balances. The controller captures user input and when necessary, issues method
calls on the model to modify the stored data. When the model changes, the
view responds by appropriately modifying the display
 In a typical application, the model changes only when user input causes the
controller to inform the model of the changes. The view must be notified when
the model changes. Both the controller and the view communicate with the user
V
through the UI.

 This means that some components of the UI are used by the controller to
receive input; others are used by the view to appropriately display the model
and some can serve both purposes (e.g., a panel can display a figure and also
accept points as input through mouseclicks)
Software Architecture & Design Pattern (15IS72), 4.Interactive System & MVC Architecture Page | 96
ud
 When we talk of MVC in the abstract sense, we are dealing with the
architecture of the system that lies behind the UI; both the view and the
controller are subsystems at the same level of abstraction that employ
components of the UI to accomplish their tasks.
 From a practical standpoint, however, we have a situation where the view and
the UI are contained in a common subsystem. For the purpose of designing our
lo
system, we shall refer to this common subsystem as the view.
 The view subsystem is therefore responsible for all the look and feel issues,
whether they arise from a human–computer interaction perspective (e.g., kinds
of buttons being used) or from issues relating to how we render the model.
 Figure 11.2 shows how we might present the MVC architecture while
accounting for these practical considerations. User-generated events may cause
C
a controller to change the model, or view, or both.
 For example, suppose that the model stored the text that is being edited by the
end- user. When the user deletes or adds text, the controller captures the
changes and notifies the model. The view, which observes the model, then
refreshes its display, with the result that the end-user sees the changes he/she
tu
made to the data. In this case, user-input caused a change to both the model and
the view.
V
The view–model relationship is that of a subject–observer. The model, as the subject,

maintains references to all of the views that are interested in observing it. Whenever an
action that changes the model occurs, the model automatically notifies all of these
views. The views then refresh their displays. The guiding principle here is that each
view is a faithful rendering of the model.
Examples
Suppose that in the library system we have a GUI screen using which users can place
holds on books. Another GUI screen allows a library staff member to add copies of
books. Suppose that a user views the number of copies, number of holds on a book and
is about to place a hold on the book. At the same time, a library staff member views the
book record and adds a copy. Information from the same model (book) is now
displayed in different formats in the two screens.
ud
Implementation
As with any software architecture, the designer needs to have a clear idea about how
the responsibilities are to be shared between the subsystems. This task can be
simplified if the role of each subsystem is clearly defined.
• The view is responsible for all the presentation issues.

lo
• The model holds the application object.
• The controller takes care of the response strategy.
The definition for the model will be as follows:
public class Model extends Observable {

C
// code
public void changeData() {
// code to update data
setChanged();
notifyObservers(chan
tu
geInfo);
}
}
.
The definition for the view will be as
follows public class View implements
V
Observer {
// code
public void update(Observable model, Object data) {
// refresh view using data
}
}
Benefits of the MVC Pattern
1. Cohesive modules: Instead of putting unrelated code (display and data) in the same
module, we separate the functionality so that each module is cohesive.
2. Flexibility: The model is unaware of the exact nature of the view or controller it is
working with. It is simply an observable. This adds flexibility.

3. Low coupling: Modularity of the design improves the chances that components can
be swapped in and out as the user or programmer desires. This also promotes parallel
development, easier debugging, and maintenance.
4. Adaptable modules: Components can be changed with less interference to the rest of
the system.
5. Distributed systems: Since the modules are separated, it is possible that the three
subsystems are geographically separated.
Analyzing a Simple Drawing Program

We now apply the MVC architectural pattern to the process of designing a simple
ud
program that allows us to create and label figures. The purpose behind this exercise is
twofold:
 To demonstrate how to design with an architecture in mind
 To understand how the MVC architecture is employed
Specifying the Requirements

lo
Our initial wish-list calls for software that can do the following.
• Draw lines and circles.

• Place labels at various points on the figure; the labels are strings. A separate
command allows the user to select the font and font size.
• Save the completed figure to a file. We can open a file containing a figure and edit it.
C
• Back track our drawing process by undoing recent operations.
Defining the Use Cases

tu
We can now write the detailed use cases for each operation. The first one, for drawing a
line, is shown in Table 11.1.
V
ud
To give the system better usability, we allow for multiple labels to be added with the same
command. To start the process of adding labels, the user clicks on the command button. This
is followed by a mouse-click on the drawing panel, following which the user types in the
desired label. After typing in a label, a user can either click on another point to create another
lo
label, or type a carriage return, which returns the system to the default state. These details are
spelled out in the use case in Table 11.2.
The system will ignore almost all non-printable characters. The exceptions are the Enter
(terminate the operation) and Backspace (delete the most-recently entered character) keys. A
label may contain zero or more characters
C
We also have use cases for operations that do not change the displayed object. An example of
this would be when the user changes the font, shown in Table 11.3.
tu
V
The requirements call for the ability to save the drawing and open and edit the saved
drawings. The use cases for saving, closing and opening files are left as exercises. In order to
allow for editing we need at least the following two basic operations: selection and deletion.
The use case Select an Item is detailed in Table 11.4.
ud
Designing the System
Defining the Model
Our next step is to define what kind of an object we are creating. This is relatively
simple for our problem; we keep a collection of line, circle, and label objects. Each line
is represented by the end points, and each circle is represented by the X-coordinates of
the leftmost and rightmost points and the Y -coordinates of the top and bottom points
on the perimeter (see Fig. 11.3)
lo
C
tu
Defining the Controller
The controller is the subsystem that orchestrates the whole show and the definition of
its role is thus critical. When the user attempts to execute an operation, the input is
received by the view. The view then communicates this to the controller. This
V
communication can be effected by invoking the public methods of the controller.
Drawing a Line
• The user starts by clicking the Draw line button, and in response, the system
changes the cursor. The click indicates that the user has initiated an
operation that would change the model. Since such operations have to be
orchestrated through the controller, it is appropriate that the controller be
informed. The controller creates a line object (with both endpoints
unspecified).
• The user clicks on the display panel to indicate the first end point of the line.
We now need to designate a listener for the mouse clicks. This listener will
extract the coordinates from the event and take the necessary action. Both the
view and the controller are aware of the fact that a line drawing operation has
been initiated
• The user clicks on the second point. Once again, the view listens to the click
and communicates this to the controller. On receiving these coordinates, the
controller recognizes that the line drawing is complete and updates the line
object.
• Finally, the model notifies the view that it has changed. The view then redraws
the display panel to show the modified figure.
ud
lo
C
This sequence of operations across the three subsystems can be captured by a highlevel
sequence diagram as shown in Fig. 11.4.
tu
Drawing a Circle
The actions for drawing a circle are similar. However, we now have some additional
processing to be done, i.e., the given points on the diameter must be converted to the the
four integer values, as explained in Fig. 11.3.
Adding a Label
V
This operation is somewhat different due to the fact that the amount of data is not fixed.
The steps are as follows:
1. The user starts by clicking the Add Label button. In response, the system
changes the mouse-cursor, which, as before is the responsibility of the view.
2. The user clicks the mouse, and the system acknowledges the receipt of the mouse
click by placing a_ at the location.
3. The user types in a character. Once again, the view listens to and gets the input
from the keyboard, which is communicated to the controller. Once again the
controller changes the model, which notifies the view.
4. The user clicks the mouse or enters a carriage-return. This is appropriately

interpreted by the view. In both cases, the view informs the controller that the
addition of the label is complete. In case of a mouse click, the controller is also
notified that a new operation for adding a label has been initiated.
This sequence of steps is explained in Fig. 11.5. Note that the view interprets the
keystrokes: as per our specifications ordinary text is passed on directly to the controller,
control characters are ignored; carriage-return is translated into a command, etc. All
this is part of the way in which the system interacts with the user, and therefore belongs
ud
to the view.
lo
C
tu
V
Selection and Deletion
 The software allows us to delete lines, circles, or labels by selecting the item
and then invoking the delete operation. These shall be treated as independent
operations since selection can also serve other purposes. Also, we can invoke
selection repeatedly so that multiple items can be selected at any given time.
 When an item is selected, it is displayed in red, as opposed to black. The

selection is done by clicking with the arrow (default) cursor. Lines are selected
by clicking on one end point, circles are selected by clicking on the center, and
labels are selected by clicking on the label.
The steps involved in implementing this are as follows:
ud
 The user gives the command through a button click. This is followed by a
mouse click to specify the item. Both of these are detected in the view and
communicated to the controller.
 In order to decide what action the controller must take, we need to figure out
how the system will keep track of the selected items. Since the view is
responsible for how these will be displayed (in red, for instance) the view must
be able to recognize these as selected when updating the display.
 The next step is to iterate through the (unselected) items in the model to find
lo
the item (if any) that contains the point. Since the model is to be used strictly as
a repository for the data, the task of iterating through the items is done in the
controller, which then invokes the methods of the model to mark the item as
selected
 Model notifies view, which renders the unselected items in the default color
(black) and the selected items in red. View gets an enumeration of the two lists
C
separately and uses the appropriate color for each.
Saving and Retrieving the Drawing

tu
The use cases for the processes of saving and retrieving are simply described: the user
requests a save/retrieve operation, the system asks for a file name which the user
provides and the system completes the task. This activity can be partitioned between
our subsystems as follows:
V
1. The view receives the initial request from the user and then prompts the user to input
a file name.
2. The view then invokes the appropriate method of the controller, passing the file
name as a parameter.
3. The controller first takes care of any clean-up operation that may be required. For
instance, if our specifications require that all items be unselected before the drawing is
saved, or some default values of environment variables be restored, this must be done
at the stage. The controller then invokes the appropriate method in the model, passing
the file name as a parameter.
4. The model serializes the relevant objects to the specified file.
Design of the Subsystems
In this stage, the classes and their responsibilities are identified and we get a more
detailed picture of how the required functionality is to be achieved.
Design of the Model Subsystem
We know that the model should have methods for supporting the following operations:
1. Adding an item
2. Removing an item
3. Marking an item as selected
4. Unselecting an item
5. Getting an enumeration of selected items
ud
6. Getting an enumeration of unselected items
7. Deleting selected items
8. Saving the drawing
9. Retrieving the drawing
Based on the above list, it is straightforward to identify the methods. The class diagram
is shown in Fig. 11.6. The class Item represents a shape such as line or label and
lo
enables uniform treatment of all shapes within a drawing.
C
tu
V
 Since the methods, getItems() and getSelectedItems() return an enumeration of

a set of items, we need polymorphic containers in the model. The view uses
these methods to get the objects from the model as an enumeration of the items
stored and draws each one on the display panel. The model must also keep
track of the view, so it needs a field for that purpose.
 The method updateView is used by the controller to alert the model that the
display must be refreshed. It is also invoked by methods within the model
whenever the model realises that its data has changed. This method invokes a
method in the view to refresh the display.
Design of Item and Its Subclasses
Rendering the items

Rendering is the process by which the data stored in the model is displayed by the
view. Regardless of how we implement this, the actual details of how the drawing is
done are dependent on the following two parameters:
 The technology and tools that are used in creating the UI For instance, we are
using the Java‘s Swing package, which means that our drawing panel is a
JPanel and the drawing methods will have to be invoked on the associated
Graphics object.
 The item that is stored If a line is stored by its equation, the code for drawing it
would be very different from the line that is stored as two end points.
 The technology and tools are known to the author of the view, whereas the
ud
structure of the item is known to the author of the items. Since the needed
information is in two different classes, we need to decide which class will have
the responsibility for implementing the rendering. We have the following
options:
Option 1 Let us say that the view is responsible for rendering, i.e., there is code in the
view that accesses the fields of each item and then draws them. Since the model is
storing these items in a polymorphic container, the view would have to query the type
of each item returned by the enumeration in order to choose the appropriate method(s).
lo
Option 2 If the item were responsible, each item would have a render method that
accesses the fields and draws the item. The problem with this is that the way an object
is to be rendered often depends on the tools that we have at our disposal.
 At this point it appears that we are stuck between two bad choices! However, a
closer look at the first option reveals a fairly serious problem: we are querying
C
each object in the collection to apply the right methods. This is very much at
odds with the object- oriented philosophy, i.e., the methods should be packed
with the data that is being queried.
 This really means that the render method for each item should be stored in the
item itself, which is in fact the approach of the second option. This simplifies
tu
our task somewhat, so we can focus on the task of fixing the shortcomings of
the second option. The structure of the abstract Item class and its subclasses are
shown in Fig. 11.7
V
Catering to Multiple UI Technologies
 Let us assume that we have available two new toolkits, which are called, for
want of better names, HardUI and EasyUI. Essentially, what we want is that
each item has to be customised for each kind of UI, which boils down to the
task of having a different render method for each UI. One way to accomplish
this is to use inheritance.
 To adapt the design to take care of the new situation, we have the Circle class
implement most of the functionality for circle, except those that depend on the
UI technology. We extend Circle to implement the SwingCircle class. Similar
extensions are now needed for handling the new technologies, HardUI and
EasyUI. Each of the three classes has code to draw a circle using the
appropriate UI technology. The idea is shown in Fig. 11.8
 In each case, the render method will decompose the circle into smaller
ud
components as needed, and invoke the methods available in the UI to render
each component. For instance, with the Swing package, the render method
would get the graphics object from the view and invoke the drawOval method.
The code for this could look something like this:
lo
C
tu
V
 Clearly, we need abstract classes for implementing the technology-independent

parts of lines (Line) and labels (Label). They are extended by classes such as
SwingLabel, SwingLine, EasyLabel, etc. This extension adds another six
classes. Each abstract class ends up with as many subclasses as the number of
UIs that we have to accommodate.
This solution has some drawbacks. The number of classes needed to accommodate such a
solution is given by:
Number of types of items × Number of UI packages
As is evident from the pictorial view of the resulting hierarchy (see Fig. 11.9), this causes an
unacceptable explosion in the number of classes.
ud
 Since the Item subclasses are being created in the model, the types of items are
an internal variation. On the other hand, the subclasses of Circle, Line,
andLabel(such asHardCircle) areanexternal variation.The standard approach
for this is to factor out the external variations and keep them as a separate
hierarchy, and then set up a bridge between the two hierarchies. This standard
lo
approach is therefore called the bridge pattern.
 The hierarchy of the UIs has an interface UIContext and as many concrete
implementations as the number of different UIs we need. Figure 11.10
describes the interaction diagram between the classes and visually represents
the bridge between the two hierarchies.
C
 Since the only variation introduced in the items due to the different UIs is the
manner in which the items were drawn, this behaviour is captured in the
UIContext interface as shown in Fig. 11.11
tu
V
Note that the total number of classes is now reduced to

Number of types of items + Number of UI packages
ud
 Since we have only one concrete class for each item, the creation process is
simple. Finally, by factoring out the render method, we are no longer concerned
with what kind of UI is being used to create the figure, or what UI will be used
to edit it at a later stage. Our software for the model is thus ‗completely‘
reusable.
Design of the Controller Subsystem

lo
We structure the controller so that it is not tied to a specific view and is unique
to them drawing program. The view receives details of a shape (type, location,
content, etc.) via mouse clicks and key strokes. As it receives the input, the
view communicates that to the controller through method calls. This is
accomplished by having the fields for the following purposes.
C
1. For remembering the model;
2. To store the current line, label, or circle being created. Since we have three
shapes, this would mean having three fields
tu
 When the view receives a button click to create a line, it calls the controller
method makeLine. To reduce coupling between the controller and the view, we
should allow the view to invoke this method at any time: before receiving any
points, after receiving the first point, or after receiving both points.
 For this, the controller has three versions of the makeLine method and keeps
track of the number of points independently of the view. The rest of the
methods are for deleting selected items and for storing and retrieving the
V
drawing and are fairly obvious. The class diagram is shown in Fig. 11.12
ud
Design of the View Subsystem
lo
 The separation of concerns inherent in the MVC pattern makes the view largely
independent of the other subsystems. Nonetheless, its design is affected by the
controller and the model in two important ways:
C
1. Whenever the model changes, the view must refresh the display, for which the
view must provide a mechanism.
2. The view employs a specific technology for constructing the UI. The
corresponding implementation of UIContext must be made available to Item.
tu
 The first requirement is easily met by making the view implement the Observer
interface; the update method in the View class, shown in the class diagram in
Fig. 11.13, can be invoked for this purpose.
V
 Commands to create labels, circles, and lines all require mouse listeners. Since
the behaviour of the mouse listener is dependent on the command, we know

from previous examples in the book that a truly object-oriented design warrants
a separate class for capturing the mouse clicks for each command. Since there
is a one-to-one correspondence between the mouse listeners and the drawing
commands, we have the following structure:
1. For each drawing command, we create a separate class that

extends JButton. For creating labels, for instance, we have a class
called LabelButton. Every button is its own listener.
2. For each class in (1) above, we create a mouse listener. These

listeners invoke methods in the controller to initiate operations.
ud
3. Each mouse listener (in (2) above) is declared as an inner class of
the corresponding button class. This is because the different
mouse listeners are independent and need not be known to each
other.
The idea is captured in Fig. 11.14. The class MouseHandler extends the Java class
MouseAdapter and is responsible for keeping track of mouse movements and clicks
lo
and invoking the appropriate controller methods to set up the label.
C
tu
V
 If the user abandons a particular drawing operation, we could be in a tricky

situation where there is more than one MouseHandler object receiving mouse
clicks and performing conflicting operations such as one object attempting to
create a line and another trying to add a label. To prevent this, we have two
mechanisms in place.
1. The KeyAdapter class also implements FocusListener to know
when key strokes cease to be directed to this class.
2. The drawing panel ensures that there is at most one listener

listening to mouse clicks, key strokes, etc. This is accomplished
by overriding methods such as addMouseListener and
addKeyListener.
Getting into the Implementation
Item and Its Subclasses
This class Item is abstract and its implementation is as follows:
ud
lo
The includes method is used to check if a given point selects the item.
The Line class looks something like this:

C
tu
V
Implementation of the Model Class
The class maintains itemList and selectedList, which respectively store the items
created but not selected, and the items selected. The constructor initialises these
containers.
The setUIContext method in the model in turn invokes the setUIContext on Item
Implementation of the Controller Class
The class must keep track of the current shape being created, and this is accomplished
by having the following fields within the class.
ud
When the view receives a button click to create a line, it calls one of the following
controller methods. The controller supplies three versions of the makeLine method and
keeps track of the number of points independently of the view.
lo
C
Implementation of the View Class
The view maintains two panels: one for the buttons and the other for drawing the
items.
tu
V
The code to set up the panels and buttons is quite straightforward, so we do not dwell
upon that.
The DrawingPanel class overrides the paintComponent method, which is called by the
system whenever the screen is to be updated. The method displays all unselected items
by first obtaining an enumeration of unselected items from the model and calling the
render method on each. Then it changes the colour to red and draws the selected items.
The Driver Program
ud
The driver program sets up the model. In our implementation the controller is
independent of the UI technology, so it can work with any view. The view itself uses
the Swing package and is an observer of the model.
lo
Implementing the Undo Operation
C
In the context of implementing the undo operation, a few issues need to be highlighted.
 Single-level undo versus multiple-level undo A simple form of undo is when

only one operation (i.e., the most recent one) can be undone. This is relatively
tu
easy, since we can afford to simply clone the model before each operation and
restore the clone to undo.
 Undo and redo are unlike the other operations If an undo operation is treated
the same as any other operation, then two successive undo operations cancel
each other out, since the second undo reverses the effect of the first undo and is
thus a redo. The undo (and redo) operations must therefore have a special status
as meta-operations if several operations must be undone.
V
 Not all things are undoable This can happen for two reasons. Some operations
like ‗print file‘ are irreversible, and hence undoable. Other operations like ‗save
to disk‘ may not be worth the trouble to undo, due to the overheads involved.
 Blocking further undo/redo operations It is easy to see that uncontrolled undo
and redo can result in meaningless requests. In general, it is safer to block redo
whenever a new command is executed.
 Solution should be efficient This constraint rules out naive solutions like saving
the model to disk after each operation.
Keeping these issues in mind, a simple scheme for implementing undo could be
something like this:
1. Create a stack for storing the history of the operations.

2. For each operation, define a data class that will store the information necessary to
undo the operation.
3. Implement code so that whenever any operation is carried out, the relevant
information is packed into the associated data object and pushed onto the stack.
4. Implement an undo method in the controller that simply pops the stack, decodes the
popped data object and invokes the appropriate method to extract the information and
perform the task of undoing the operation.
One obvious approach for implementing this is to define a class StackObject that stores
each object with an identifying String.
ud
lo
Each command has an associated object that stores the data needed to undo it. The class
corresponding to the operation of adding a line is shown below.
C
tu
When the operation for adding a line is completed, the appropriate StackObject instance
is created and pushed onto the stack.
V
Decoding is simply a matter of popping the stack reading the String.
Finally, undoing is simply a matter of retrieving the reference to and removing the line
form the model.
ud
There are two obvious drawbacks with this approach:
lo
1. The long conditional statement in the undo method of the controller.
2. The need to rewrite the controller whenever we make changes such as adding or
modifying the implementation of an operation.
Employing the Command Pattern

C
 In undo method, the controller passes itself as a reference to the undo method
of the StackObject. In turn, each subclass of the StackObject (e.g., LineObject)
passes itself as reference when invoking the appropriate undo method of the
tu
controller.
 This is an implementation of double dispatch that we used when employing the
visitor pattern and was wholly appropriate when introducing new functionality
into an existing hierarchy.
 In this context, however, we find that this results in unnecessarily moving a lot
of data around. One of the lasting lessons of the object-oriented experience is
the supremacy of data over process (The Law of Inversion), which we can
V
utilise in this problem by using the command pattern.
The intent of the command pattern is as follows:
Encapsulate a request as an object, thereby letting you parametrise clients with different
requests, queue or log requests, and support undoable operations.
The command pattern provides us with a template to address this. The abstract
Command class has abstract methods to execute, undo and redo. See Fig. 11.16
The default undo and redo methods in Command return false, and these need to be
overridden as needed by the concrete command classes.
The mechanism is best explained via an example, for which we develop a somewhat
ud
simplified sequence diagram for the command to add a line (Fig. 11.17).
lo
C
tu
Adding a line Since every command is represented by a Command object, the first
V
order of task when the Draw Line command is issued is to instantiate aLineCommand
object. We assume that we do this after the user clicks the first endpoint although there
is no reason why it could not have been created immediately after receiving the
command. In its constructor, LineCommand creates a Line object with one of its
endpoints specified
Assume that the user issues the sequence of commands:
At this time, there are four Command objects, one for each of the above commands, and
they are on the history stack as in Fig. 11.18. The redo stack is empty: since no
commands have been undone, there is nothing to redo. The picture also shows the
collection object in the model storing the two Label objects, the Circle object, and the
Line object.
ud
lo
C
Undoing an operation
tu
Continuing with the above example, we now look at the sequence of actions when the
undo request is issued immediately after the line (Line 1) has been completely drawn in
the above sequence of commands. Obviously, the user views the command as undone if
the line disappears from the screen: for this, the Line object must be removed from the
collection. To be consistent with this action and to allow redoing the operation, the
LineCommand object must be popped from the history stack and pushed onto the redo
V
stack. The resulting configuration is shown in Fig. 11.19
ud
Implementation
Subclasses of Command The concrete command classes (such as LineCommand) store

the associated data needed to undo and redo these operations. Just as the makeLine
lo
method in the previous implementation had three versions, the LineCommand class has
three constructors, allowing some flexibility in the design of the view
The implementation of methods specific to the Command class are shown below. The
execute method simply adds the command to the model so the line will be drawn. To
undo the command, the Line object is removed from the model‘s collection. Finally,
C
redo calls execute
tu
V
As explained earlier, the class has a method called end, which attempts to complete an
unfinished command. The situation is considered hopeless if both endpoints are missing,
so the object removes the line from the model (undoes the command) and returns a false
value. Otherwise, if the line is incomplete (has at least one endpoint unspecified), the
start and end points are considered the same. The implementation is:
UndoManager It declares two stacks for keeping track of the undo and redo operations:
(history) and (redoStack). The current command is stored in a field aptly named
currentCommand.
Handling the input The view declares one button class for each command (add label,
draw line, etc.). The class for handling line drawing is implemented as below.
ud
lo
Drawing Incomplete Items
C
There are a couple of reasons why in the drawing program we might wish to distinguish
between these two types of items.
1. Incomplete items might be rendered differently from complete items. For instance, for
tu
a line, after the first click, the UI could track the mouse movement and draw a line
between the first click point and the current mouse location; this line keeps shifting as
the user moves the mouse. Likewise, if we were to extend the program to include
triangles, which need three clicks, one side may be displayed after two clicks. Labels in
construction must show the insertion point for the next character.
2. Some fields in an incomplete item might not have ‗proper‘ values. Consequently,
V
rendering an incomplete item could be more tricky. An incomplete line, for instance,
might have one of the endpoints null. In such cases, it is inefficient to use the same
render method for both incomplete items and complete items because that method will
need to check whether the fields are valid and take appropriate actions to handle these
special cases. Since we ensure that there is at most one incomplete item, this is not a
sound approach.
We can easily distinguish between incomplete items and complete items by having a
field that identifies the type. The render method will behave differently based on this
field. The approach would be along the following lines.
ud
We create classes for incomplete items (such as IncompleteLabel) that are subclasses of
items (such as Label). Since the class IncompleteLabel is a subclass of Label, the model
is unaware of its existence. Once the object is created, the incomplete object can be
removed from the model. lo
The details are as follows.
C
tu
One problem we face with the above approach is that UIContext must include the
method(s) for drawing the incomplete items (draw (IncompleteLabel label), in our
example). This suggests that UIContext needs to be modified.
In general, we would like a solution that allows for a customised presentation which
may require subclassing the behaviour of some concrete items. This can be
accomplished through RTTI. In particular, the situation where the NewSwingUI wants
V
its own method for drawing an incomplete line is implemented as follows:
Adding a New Feature

 Most interactive systems that are used to create graphical objects, allow users to
define new kinds of objects on the fly. A system for writing sheet music may
allow a user to define a sequence of notes as a group.
 In a system for drawing electrical circuits, a set of components interconnected

in a particular way could be clustered together as a ‗sub-circuit‘ that can then
be treated as a single unit.
 Let us examine how our system needs to be modified to accommodate this. The
process for creating such a ‗compound‘ object would be as follows: The user
ud
would select the items that have to be combined by clicking on them. The
system would then highlight the selected items. The user then requests the
operation of combing the selected items into a compound object, and the system
combines them into one.
 Once a compound object has been created, it can be treated as a any other
object. This process can be iterated, i.e., a compound object can be combined
with other objects to create another compound object. The compound item is
lo
created by combining two compound items, and then decomposing it will give
us back the two original compound items. Finally, the system must have the
ability to undo and redo these operations.
 We have to store a collection of items to create a new kind of item that

maintains a collection of the constituent items. This would be a concrete class
and would look like this:
C
tu
• Since items consist of both simple items and compound items, it seems logical
that all entities stored in items are designated as belonging to the class Object.
The model would also have to be modified so that the container classes would
V
hold collections of type Object

• Our standard approach in such situations is to create an inheritance hierarchy and
use dynamic binding. The dilemma here is that we have a two fundamentally
different kinds of entities: a simple item is a single item, whereas a compound
item is a collection of items. The composite pattern gives us an elegant solution
to this problem.
The intent of the composite pattern is as follows
Compose objects into tree structures to represent part-whole hierarchies. Composite lets
clients treat individual objects and compositions of objects uniformly.
A compound item is clearly a composition of simple items. Since each compound item
could itself consist of other compound items, we have the requisite tree structure (see
Fig. 11.20).
ud
lo
The class interaction diagram for the composite pattern is shown in Fig. 11.21. Note that
the definition of the compound item is recursive and may remind readers of the recursive
definition of a tree. Following this diagram, the class CompoundItem is redefined as
follows:
C
tu
V
Pattern-Based Solutions
ud
A pattern is a solution template that addresses a recurring problem in specific
situations. In a general , these could apply to any domain E.g.: A standard
opening in chess, for instance, can be looked at as a ‗chess pattern‘. In the
context of creating software, three kinds of patterns have been identified:
 At the highest level, we have the architectural patterns. These typically

partition a system into subsystems and broadly define the role that each
subsystem plays and how they all fit together. Architectural patterns have the
following characteristics:

lo
They have evolved over time In the early years of software development, it was
not very clear to the designers how systems should be laid out. Over time, some
kind of categorisation emerged, of the kinds software systems that are needed.
In due course, it became clearer as to how these systems and the demands on
them change over their lifetime. This enabled practitioner to figure out what
C
kind of layout could improve some of the commonly encountered problems.
 A given pattern is usually applicable for a certain class of software system The
MVC pattern for instance, is well-suited for interactive systems, but might be a
tu
poor fit for designing a payroll program that prints paychecks.
 The need for these is not obvious to the untrained eye When a designer first
encounters a new class of software; it is not very obvious what the architecture
should be. The designer is not aware of how the requirements might change
over time, or what kinds of modifications are likely to be needed. This is
somewhat different from design patterns, which we are able to ‗derive‘ by
V
applying some of the well- established ‗axioms‘ of object-oriented analysis and

design
 At the next level, we have the design patterns. These solve problems that could
appear in many kinds of software systems. Once the principles of object-
oriented analysis and design have been established it is easier to derive these.
 At the lowest level we have the patterns that are called idioms. Idioms are the
patterns of programming and are usually associated with specific languages. As
programmers, we often find ourselves using the same code snippet every time
we have to accomplish a certain task.
 Idioms are something like these, but they are usually carefully designed to take
the language features (and quirks!) into account to make sure that the code is
safe and efficient. The following code, for instance, is commonly used to swap:
 This is an example of an idiom for Perl. In addition to safety and efficiency, the
familiarity of the code snippet makes the code more readable and reduces the
need for comments. Not all idioms are without conflict. There are two possible
idioms for an infinite loop:
ud
lo
C
tu
V

SADP_21CS741-M4

Uploaded by

Copyright:

Available Formats

SADP_21CS741-M4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SADP_21CS741-M4

Uploaded by

Copyright:

Available Formats

Maharaja Institute of Technology Mysore Department of Information Science & Engineering

The MVC Architectural Pattern

through the UI.

The view–model relationship is that of a subject–observer. The model, as the subject,

• The view is responsible for all the presentation issues.

The definition for the model will be as follows:

public class Model extends Observable {

Benefits of the MVC Pattern

working with. It is simply an observable. This adds flexibility.

Analyzing a Simple Drawing Program

Specifying the Requirements

• Draw lines and circles.

Defining the Use Cases

Defining the Controller

communication can be effected by invoking the public methods of the controller.

4. The user clicks the mouse or enters a carriage-return. This is appropriately

Selection and Deletion

 When an item is selected, it is displayed in red, as opposed to black. The

The steps involved in implementing this are as follows:

Saving and Retrieving the Drawing

detailed picture of how the required functionality is to be achieved.

Design of the Model Subsystem

 Since the methods, getItems() and getSelectedItems() return an enumeration of

Design of Item and Its Subclasses

Rendering the items

Catering to Multiple UI Technologies

 Clearly, we need abstract classes for implementing the technology-independent

Number of types of items × Number of UI packages

Note that the total number of classes is now reduced to

Design of the Controller Subsystem

the behaviour of the mouse listener is dependent on the command, we know

1. For each drawing command, we create a separate class that

2. For each class in (1) above, we create a mouse listener. These

 If the user abandons a particular drawing operation, we could be in a tricky

2. The drawing panel ensures that there is at most one listener

Getting into the Implementation

Item and Its Subclasses

This class Item is abstract and its implementation is as follows:

The Line class looks something like this:

Implementation of the Model Class

Implementation of the Controller Class

The Driver Program

 Single-level undo versus multiple-level undo A simple form of undo is when

1. Create a stack for storing the history of the operations.

Decoding is simply a matter of popping the stack reading the String.

Employing the Command Pattern

utilise in this problem by using the command pattern.

The intent of the command pattern is as follows:

Assume that the user issues the sequence of commands:

stack. The resulting configuration is shown in Fig. 11.19

Subclasses of Command The concrete command classes (such as LineCommand) store

its own method for drawing an incomplete line is implemented as follows:

Adding a New Feature

 In a system for drawing electrical circuits, a set of components interconnected

 We have to store a collection of items to create a new kind of item that

hold collections of type Object

The intent of the composite pattern is as follows

 At the highest level, we have the architectural patterns. These typically

poor fit for designing a payroll program that prints paychecks.

applying some of the well- established ‗axioms‘ of object-oriented analysis and