Post on 27-Jun-2020
M8748 © Peter Lo 2007 1
Designing Boundary Classes
Chapter 17
M8748 © Peter Lo 2007 2
In this Lecture you will Learn:
What we mean by the presentation layerHow prototyping can be applied to user interface designHow to add boundary classes to the class modelHow to model boundary classes in sequence diagramsHow design patterns can be applied to the user interfaceHow to model control using statecharts
M8748 © Peter Lo 2007 3
Architecture of the Presentation Layer
Aim to separate the classes that have the responsibility for the interface with the user, or with other systems (Boundary Classes) from the business classes (Entity classes) and the classes that handle the application logic (Control Classes). This is the Three-Tier Architecture.There may be more than three layers, and that the logical layers can map to physical platforms in a number of ways.
M8748 © Peter Lo 2007 4
Reasons for the 3-Tier Architecture
Logical Design Interface IndependenceReuse
M8748 © Peter Lo 2007 5
3-Tier Architecture
Different authors have used different termsBoundary, Entity, ControlModel, View, ControllerHuman Interaction Component, Problem Domain Component, Task Management Component
M8748 © Peter Lo 2007 6
Presentation Layer
Handles interface with users and other systemsFormats and presents data at the interfacePresentation can be for display as text or charts, printing on a printer, speech synthesis, or formatting in XML to transfer to another systemProvides a mechanism for data entry by the user, but the events are handled by control classes
M8748 © Peter Lo 2007 7
Presentation Layer
Does not contain business classesClients, Campaigns, Adverts, Invoices, Staff etc.
Does not contain the business logicRules like ‘A Campaign must have one and only one Campaign Manager’.
Does not handle validationBeyond perhaps simple checks on formatting
M8748 © Peter Lo 2007 8
Developing Boundary Classes
Prototype the User InterfaceDesign the ClassesModel the Interaction involved in the InterfaceModel the Control of the Interface using Statechart Diagrams (if necessary)
M8748 © Peter Lo 2007 9
Prototyping the User Interface
A prototype is a model that looks, and partly behaves, like the finished product but lacks certain featuresA Horizontal Prototype deals with only one layer of the system architecture, usually the user interface. A Vertical Prototype takes one sub-system and develops it through each layer.
M8748 © Peter Lo 2007 10
Prototyping the User Interface
Distinction between two type of prototype:Prototypes developed in an iterative process that are elaborated to become part of the eventual system andPrototypes developed to test out design ideas that are thrown away rather than being further enhanced (actually, they are not really thrown away, as they form part of the design)
M8748 © Peter Lo 2007 11
Approaches to Prototyping
Prototyping involves a repetitive sequence of analysis, design, modeling and testing.The end product of System Prototyping (or Evolutionary Prototyping) is a full-featured, working model of the information system, ready for implementation.
M8748 © Peter Lo 2007 12
Approaches to Prototyping
A Throwaway Prototyping (or Design Prototyping) is one that is developed to test out ideas about the interface design, but is not then developed to become the working system. Often it is developed in a language that allows it to be developed quickly rather than the language in which the full application will be developed.
M8748 © Peter Lo 2007 13
Alternative Approaches Example
Prototyping can be used to try out alternative approaches to the same use case.Three alternatives are possible for the following user interface:
M8748 © Peter Lo 2007 14
Alternative Approach 1
Use a separate look-up window for each class
M8748 © Peter Lo 2007 15
Alternative Approach 2
Allow the user to enter part of a name (for example of a client) and for a list of close mates to be returned.
M8748 © Peter Lo 2007 16
Alternative Approach 3
Use a tree structure which shows the instances of clients and campaigns in a tree-like hierarchy
M8748 © Peter Lo 2007 17
Designing Classes
Start with the collaborations from the analysis modelElaborate the collaborations to include necessary boundary, entity and control classesRosenberg and Scott (1999) treat control classes as placeholders: they represent some responsibility that has to be handled somewhere, but it may become an operation of another class.
M8748 © Peter Lo 2007 18
Class Design Example - Collaboration for Check campaign budget
In order to find the right Campaign, we also need to use the Client class, even though it does not participate in the real process of checking the budgetWe also add control classes for the responsibilities of listing clients and campaigns
M8748 © Peter Lo 2007 19
Class Design Example - Collaboration for Check campaign budget
Extended collaboration for the use case Check campaign budget
Check Campaign Budget UI
Check Campaign
Budget
Campaign Advert
List Campaigns
List Clients Client
M8748 © Peter Lo 2007 20
Class Design Example - Collaboration for Check campaign budget
Revised collaboration for the use case Check campaign budget
Check Campaign Budget UI
Check Campaign Budget
Campaign Advert
List Campaigns
List Clients Client
List Campaigns UI
List Clients UI
M8748 © Peter Lo 2007 21
Class Design Example - Class Diagram for CheckCampaignBudgetUI
Class diagram showing dialogue components
3
1
2
1
1
1
2
1
Dialog
CheckCampaignBudgetUI
Label Button TextField Choice
M8748 © Peter Lo 2007 22
Class Design Example - Single Class for CheckCampaignBudgetUI
Draw in your own lines to show which attribute is which element of the interface
M8748 © Peter Lo 2007 23
Class Design Example - Package Dependencies
Classes can be shown with package names
M8748 © Peter Lo 2007 24
Class Design Example - Package Dependencies
There is an «import» dependency between the two packages
import java.awt.*; // In Javausing System.Winforms; // in C#
M8748 © Peter Lo 2007 25
Design Interaction with Sequence Diagrams
The collaboration diagram showed the boundary and control classes, and we shall elaborate the interaction in more detail.
M8748 © Peter Lo 2007 26
Design Interaction Example
Sequence diagram for use case Check campaign budget only shows the entity classes
M8748 © Peter Lo 2007 27
Design Interaction Example - First Part of Sequence Diagram
By using the collaboration diagram showing the control and boundary classes, we now need to model the interaction more detail
M8748 © Peter Lo 2007 28
Design Interaction Example - First Part of Sequence Diagram
The control class Creates the instance of the boundary classCreates the instance of the ListClients control classPasses to :ListClients a reference to the boundary class:ListClients then sets the name of each client in turn into the boundary class by calling addClientname(name) repeatedly
M8748 © Peter Lo 2007 29
Design Interaction Example - Using Interfaces
We don’t mean user interfaces!Many boundary classes will need to list clients to allow the user to select a clientThe ListClients control class doesn’t need to know how the boundary class lists themThe boundary class needs to implement the ClientLister interface and provide an implementation of the operation addClientName(String)
M8748 © Peter Lo 2007 30
Design Interaction Example - Using Interfaces
Attributes can be private, only accessed through the public interface
M8748 © Peter Lo 2007 31
Design Interaction Example - Java Implementationimport java.awt.*;public class CheckCampaignBudgetUI extends
Frame implements ClientLister {private Choice clientChoice;...
public void addClientName(String name) {clientChoice.addItem(name);
}...}
M8748 © Peter Lo 2007 32
Design Interaction Example -listAllClients( ) Operation
Class diagram for listAllClients( ) Operation
M8748 © Peter Lo 2007 33
Design Interaction Example - Second Part of Sequence Diagram
Note that the :ListCampaigns object is using aCampaignLister interface to communicate with :CheckCampaignBudgetUI in the same way as :ListClients used the ClientLister interface.
M8748 © Peter Lo 2007 34
Design Interaction Example - Event-driven User Interface
Event in :clientChoice is passed through to the main boundary class
M8748 © Peter Lo 2007 35
Design Interaction Example - Revised Second Part of Sequence Diagram
clearAllCampaignNames() has been added to prevent more and more campaigns being added if a new client is selected.
M8748 © Peter Lo 2007 36
Design Interaction Example - Final Part of Sequence Diagram
Final part of interaction for use case Check campaign budget
M8748 © Peter Lo 2007 37
Design Interaction Example - Adding to the Class Diagram
From the sequence diagrams, we can see that the CheckCampaignBudgetUI class needs to implement both the ClientLister and the CampaignLister interfacesThere are also additional operations that have been introduced, some of which will apply to any class that implements these interfaces (and therefore belong to the interfaces), and some of which belong to the CheckCampaignBudgetUI class
M8748 © Peter Lo 2007 38
Design Interaction Example – Revised Class Diagram
Revised Class Diagram showing checkCampaignBudgetUI
M8748 © Peter Lo 2007 39
Using Design Patterns
More and more, libraries of classes are built around design patternsIn Smalltalk, the Model-View-Controller architecture is widely usedIn Java, an approach is used in which objects register an interest in events, then when an event occurs all the objects that have registered are notified of the event
M8748 © Peter Lo 2007 40
Model-View-Controller
Model-View-Controller responses to an external event
M8748 © Peter Lo 2007 41
Java Listener Approach
Java ItemListener response to an external event
M8748 © Peter Lo 2007 42
Java Approach
Various listeners for different kinds of user interface components
MouseListenerItemListenerActionListener
All subinterfaces of EventListener
M8748 © Peter Lo 2007 43
Java 2 Enterprise Edition (J2EE) Approach
J2EE is used for N-Tier distributed systems based on Enterprise Java Beans (EJB)J2EE Core Patterns provides a pattern catalogue that uses the Model-View-Controller architecture
M8748 © Peter Lo 2007 44
MVC vs. Java EventListenerApproaches
Java EventListener only handles changes to interface objects. MVC deals with changes to Model objects. The Java Observer and Observable interfaces provide MVC mechanisms.
M8748 © Peter Lo 2007 45
Modelling the User Interface in Statechart Diagrams
We use statechart diagrams to model the lifetime of instances of business classes.Different approaches to using statecharts
Browne (1994), which was used in the 1st
editionHorrocks (1999) used hereBoth based on the original work of Harel (1987)Recent work of Harel and Politi (1998)
M8748 © Peter Lo 2007 46
Five tasks in Horrocks’ Approach
1. Describe the high-level requirements and main user tasks
2. Describe the user interface behaviour3. Define user interface rules4. Draw the statechart (and successively refine it)5. Prepare an event action table
M8748 © Peter Lo 2007 47
Example: High-level Requirements
The requirement here is that the users must be able to check whether the budget for an advertising campaign has been exceeded or not. This is calculated by summing the cost of all the adverts in a campaign, adding a percentage for overheads and subtracting the result from the planned budget. A negative value indicates that the budget has been overspent. This information is used by a campaign manager.
M8748 © Peter Lo 2007 48
Example: User Interface Behaviour
The client dropdown displays a list of clients. When a client is selected, their campaigns will be displayed in the campaign dropdown.The campaign dropdown displays a list of campaigns belonging to the client selected in the client dropdown. When a campaign is selected the check button is enabled.The budget textfield displays the result of the calculation to check the budget.The check button causes the calculation of the budget balance to take place.The close button closes the window and exits the use case.
M8748 © Peter Lo 2007 49
Example: Define User Interface Rules
User interface objects with Constant behaviourThe client dropdown has constant behaviour. Whenever a client is selected, a list of campaigns is loaded into the campaign dropdownThe budget textfield is initially empty. It is cleared whenever a new client is selected or a new campaign is selected. It is not editableThe close button may be pressed at any time to close the window
M8748 © Peter Lo 2007 50
Example: Define User Interface Rules
User interface objects with Varying behaviourThe campaign dropdown is initially disabled. No campaign can be selected until a client has been selected. Once it has been loaded with a list of campaigns it is enabledThe check button is initially disabled. It is enabled when a campaign is selected. It is disabled whenever a new client is selected
M8748 © Peter Lo 2007 51
Example: Define User Interface Rules
Entry and exit eventsThe window is entered from the main window when the Check Campaign Budget menu item is selectedWhen the close button is clicked, an alert dialogue is displayed. This asks ‘Close window? Are you sure?’and displays two buttons labelled ‘OK’ and ‘Cancel’. If ‘OK’ is clicked the window is exited; if ‘Cancel’ is clicked then it carries on in the state it was in before the close button was clicked
M8748 © Peter Lo 2007 52
Example: Draw the Statechart
We start with the top-level statechart for movement between the windows and dialogues
M8748 © Peter Lo 2007 53
Example: Draw the Statechart
Client selection states are nested within the Check Budget Window state
M8748 © Peter Lo 2007 54
Example: Draw the Statechart
Campaign selection states are nested within the Client Selected state
M8748 © Peter Lo 2007 55
Example: Draw the Statechart
Display of result states are nested within Campaign Selected state
M8748 © Peter Lo 2007 56
Example: Combined statechart with nested states
M8748 © Peter Lo 2007 57
Example: Draw the Statechart
Non-UML features:Horrocks numbers the statesState variables can be shown in square brackets
Statechart can be simplified (as on next slide)Rather than try to add all messages associated with transitions into the diagram, an Event-Action table can be used
M8748 © Peter Lo 2007 58
Example: Simplified Statechart
M8748 © Peter Lo 2007 59
Event-Action Table
A list of states, for each state the valid events that can cause a transition from that state, the state that each transition leads to, and any operations associated with the transition into the new state.
M8748 © Peter Lo 2007 60
Revising the Sequence Diagrams and Class Diagrams
Producing the statechart diagram and the event-action table has identified some additional messages that will be sent to the user interface to control itThese will need to be added to the sequence diagrams and to the class diagram as operations of the UI class or of the listener interfaces