Last time
Boundary object responsibilities
√ 1. Handling user messages
√ 2. Handling events i.e. mouse
selections
3. Presenting the application data to
the user
Presenting the application data to the user
This occurs when the application data changes
e.g. the currently selected booking has changed, the current
bookings collection has changed, a booking has been transferred
to a different table etc the staffID object needs to update the
display to reflect this change.
how does it know when to do this?
or...
how is it informed that the application data has changed?
Presenting the application data to the user
Current sate of the design model …
<<boundary>> <<control>>
StaffUI BookingSystem
The rest of the
model
Presenting the application data to the user
how is the boundary class informed that the application data has
changed?
Possibilities
•Polling i.e StaffUI could ask, on a regular basis (called the
polling rate), the BookingSystem whether the data has changed.
Potentially this could be expensive in terms of processing time.
•The BookingSystem could tell StaffUI when the data has changed.
This requires the association to be bi-directional, thus increasing the
coupling between the two classes. It also violates the constraints of
the three layered architecture in the sense that the application layer
should be independent of the presentation layer.
Presenting the application data to the user
how is the boundary class informed that the application data has
changed?
StaffUI
violates
<<depends>>
BookingSystem
Presenting the application data to the user
how is the boundary class informed that the application data has
changed?
Fortunately this problem has been solved
before!
A suitable design pattern could be applied
Presenting the application data to the user
an aside …
Design patterns
Design patterns are generic designs for commonly occurring
design problems.
They are available in the literature and are covered in far more detail in
CSE3OAD [Object-Oriented Application Development]
e.g. See “Applying UML and Patterns --- An Introduction to Object-Oriented
Analysis and Design and the Unified Process” 2nd edition Craig Larman, Prentice-
Hall International, Inc (2002)
The Observer design pattern could be applicable here
Presenting the application data to the user
The Observer (Publish-Subscribe) design pattern can be described as
follows (from Larman p. 373)
Context/Problem
Different kinds of subscriber objects are interested in the state
changes or events of a publisher object, and want to react in their
own unique way when the publisher generates an event. We wish to
maintain low coupling between the subscribers and publishers.
In our case there is one subscriber object (StaffUI) and one publisher
object (BookingSystem). The state changes are changes in the
application data e.g. currently selected booking, the set of current
booking etc.
Presenting the application data to the user
The Observer (Publish-Subscribe) design pattern can be described as
follows (from Larman p. 373)
Solution
Define a listener (or observer) interface. Subscribers then implement this
interface. The publisher can register subscribers who are interested in
an event, and notify them when an event occurs.
In our case a BookingObserver interface will be defined which
will be implemented by StaffUI
Presenting the application data to the user
Another aside … Interface Classes
"An Interface is a specialised class declaration that can declare constants and
method declarations, but not method implementations". (Java API)
An interface is a description of behaviour. Classes that implement the interface
must provide the services (methods) described by the interface.
In UML
<<implements>>
SampleClass InterfaceClass
… a realisation
Presenting the application data to the user
Another aside … Interface Classes
"An Interface is a specialised class declaration that can declare constants and
method declarations, but not method implementations". (Java API)
An interface is a description of behaviour. Classes that implement the interface
must provide the services (methods) described by the interface.
In Java
public class SampleClass implements InterfaceClass
{
.......
.......
/* method implementations for the declarations in
InterfaceClass are defined here*/
}
Presenting the application data to the user
So how does it work in the Restaurant system ?
The BookingSystem has a list of
BookingObservers. It also has
the functionality to deal with this
list (i.e can add to it, can notify StaffUI
an observer when something
occurs)
<<implements>>
BookingSystem <<interface>>
BookingObserver
*
Presenting the application data to the user
So how does it work in the Restaurant system ?
When a StaffIU object is
instantiated it would instantiate
a BookingSystem object and
notify it (through addObserver())
that it wishes to be added to the StaffUI
list of BookingObservers. update()
This is
implemented
When the system data <<implements>> by the StaffUI
changes (e.g the current object.
bookings have changed), the
BookingSystem notifies the BookingSystem <<interface>>
BookingObserver
appropriate BookingObserver addObserver()
notfiyObserver() update()
through notifyObserver(), displayBookings() *
which involves the sending of
the update() message.
Presenting the application data to the user
Now for a simple demonstration (in Java) The BookingSystem class
The StaffUI class
import java.util.*;
import java.util.*; public class BookingSystem
public class StaffUI implements BookingObserver
{
{ public boolean updateRequired;
public BookingSystem TheBookingSystem; BookingObserver observers[] = new BookingObserver[1]; //
only want one of them
public StaffUI() // the constructor public BookingSystem() // the constructor
{ {
System.out.println(" StaffInterface object created"); System.out.println(" TheBookingSystem object created");
TheBookingSystem = new BookingSystem(); updateRequired = true;
TheBookingSystem.registerAsObserver(this);
int i; }
for(i=0;i<6;i++)
{TheBookingSystem.change();} public void registerAsObserver(StaffUI ui)
{
} observers[0] = ui;
}
public void change()
// overridding update() in the interface BookingObserver {
public void update() if(updateRequired)
{ { observers[0].update();
System.out.println(" Update method implemented by StaffUI updateRequired = false;}
called"); else
} {updateRequired = true;}
}
}
}
Presenting the application data to the user
Now for a simple demonstration (in Java)
… and finally the interface class, BookingObserver
Here is the main …
import java.util.*;
import javax.swing.*;
public interface BookingObserver
import java.awt.*;
public class InterfacePractice1
{
{
public static void main(String[] args)
{
public void update();
EventQueue.invokeLater(new Runnable()
{
public void run()
}
{
StaffUI StaffInterface = new StaffUI();
}
} ); // end of invoke trying to ensure that the events and apps are in
the same thread
} // main
} // class
Next time …
More on the design model
