HCI Designing Interface Objects

The presentation layer How prototyping can be used to try out different interface designs How to model boundary classes using sequence diagrams How to model the dynamic behaviour of the user interface using statechart diagrams

Presentation Layer A three-tier architecture is commonly used to separate the user interface classes from the business and application logic classes and from the classes that handle data storage – presentation layer, application logic layer, storage layer – boundary, control and entity classes – Model-View-Controller These approaches keep the behaviour of the interface separate from the behaviour of the classes that provide the main functionality of the system

Reasons for separating business and user interface classes Refer to figure 17.1 pg 411, Bennet

Prototyping the user interface A prototype is a model that looks like the finished product but is lacking in certain features – horizontal prototype – prototypes one layer of the system – vertical prototype – takes a subsystem and prototypes all of the layers – some prototypes are developed iteratively and become part of the finished system – others are used to test design ideas and are then thrown away – known as a throwaway prototype ● throwaway prototypes can be built using a visual programming environment

Prototype of the Check Camping Budget Interface

Prototyping the User Interface Visual programming environments – there is a danger of developing applications from the outside in ● the distinction between the presentation layer and business classes may become blurred ● interface objects may have a large amount of associated code – it is important to keep application logic components separate from the visual components Prototyping can be used to try out alternative interface styles and aid in developing style guidelines

Dialogue Window for the Use Case Check Camping Budget

Collaboration for the Use Case Check Campaign Budget During analysis the class Client does not participate in the main functionality of the use case However, in order to find the right campaign we need the client Further control classes can be added to the collaboration

Extended Collaboration for the Use case Check Campaign Budget

Alternative Collaboration for the Use Case Check Campaign Budget

Class Diagram Showing Dialogue Components

Class for Dialogue Window Showing Dialogue Components as Attributes

Class Diagram Showing Components from other Packages

Sequence Diagram Produced during Analysis for the Use Case Check Campaign Budget

First Part of Detailed Interaction for the Use Case Check Campaign Budget

A new instance of the control class CheckCampaignBudget is created which – creates a new instance of the boundary class CheckCampaignBudgetUI – creates an instance of the control class ListClients – passes to :ListClients a reference to the boundary class (ccbUI) – :ListClients then sets the name of each client in the boundary class by sending addClientName(name) repeatedly – :ListClients then destroys itself

Using Interface Many boundary classes will need to list clients – we therefore need to reuse the control class ListClients ListClients does not need to know how the boundary class lists clients Solution: define the interface ClientLister

Revised Second Part of Detailed Interaction for the Use Case Check Campaign Budget

Final Part of Detailed Interaction for the Use Case Check Campaign Budget

Class Diagram Showing CheckCampaignBudgetUI

Modelling the Interface Using Statecharts Statecharts – model the way that events affect instances of a class over its lifetime – model the short-term effects of events in the user interface Modelling the state of the user interface involves – describing the high-level requirements and main user tasks – describing the user interface behaviour – defining the user interface rules – drawing the statechart – preparing an event-action table

Revised First Part of Detailed Interaction for the Use Case Check Campaign Budget

Summary Prototyping may be used to build models of the interface and test how it will work Designing the interface objects involves modelling three important aspects – the classes that will participate in the interaction with the user (this may involve reusing interface classes) – the interaction with the user in sequence and collaboration diagrams – the state of the interface References – chapter 17, Bennett, McRobb and Farmer