what we mean by the presentation layer how prototyping can ... › teaching › m8748 › l17.pdfa...

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


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


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


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


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


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


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


Client selection states are nested within the Check Budget Window state

M8748 © Peter Lo 2007 54


Campaign selection states are nested within the Client Selected state

M8748 © Peter Lo 2007 55


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


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

what we mean by the presentation layer how prototyping can ... › teaching › m8748 › l17.pdfa...

Documents