© 2005 Prentice Hall12-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.

© 2005 Prentice Hall12-2 Learning Objectives Describe which features of the user- computer dialogue should be included in a design model for the user interface. Explain the components of a state transition diagram (statechart) and what each of them represents. Use a coordinated pair of state transition diagrams to model the user-computer interface.

© 2005 Prentice Hall12-3 Learning Objectives (continued) Explain the conventions for window navigation diagrams. Use a window navigation diagram to model the navigation through a series of windows or Web pages. Discuss the importance of testing the interface for usability. Describe the Model-View Separation pattern and discuss the advantages it provides.

© 2005 Prentice Hall12-4 Overview Applying the design principles of Chapter 11 requires modeling the design of the user-computer interaction at the automation boundary. Some of these models present the interface design to prospective users. Others specify the interaction in sufficient detail for the interface to be constructed.

© 2005 Prentice Hall12-5 Overview (continued) The external design of the user interface should be recorded in a written specification. Testing the design of the user interface throughout the development process is critical to success. There is no acceptable substitute for observing users as they interact with prototypes as well as with the completed system.

© 2005 Prentice Hall12-6 Overview (continued) State transition diagrams effectively model the details of user-computer interaction at the automation boundary. Window navigation diagrams model the navigation paths between the windows in a GUI or the pages of a Web site. Simulations and prototypes facilitate communicating the interface design to users.

© 2005 Prentice Hall12-7 Overview (continued) The Model-View Separation pattern guides the connection of the presentation layer and the business layer. It enforces the design principle that objects in the application domain should have no direct knowledge of or be directly coupled to objects in the presentation layer.

© 2005 Prentice Hall12-8 Modeling the User-Computer Dialogue The user-computer dialogue consists of messages across the automation boundary between two processors – a human and a computer.

© 2005 Prentice Hall12-9 Modeling the User-Computer Dialogue (continued) A model of this dialogue should represent: Messages containing data Messages controlling the dialogue Material inputs and outputs Operations or procedures Coordination and sequencing of the actions of the processors

© 2005 Prentice Hall12-10 State Transition Diagrams A state transition diagram (known in the UML as a statechart) is a useful model of user-computer interaction. It models the actions of a finite state machine with no state memory. This processor may be in only one state at a time. A transition to a different state is caused by the occurrence of an event or by a condition’s becoming true.

© 2005 Prentice Hall12-11 State Transition Diagrams (continued) Components of a state transition diagram are: State: where the processor waits for an occurrence to cause a transition Transition: an instantaneous change to another state

© 2005 Prentice Hall12-12 State Transition Diagrams (continued) Transitions are labeled to show: the event(s) which trigger them, and the action(s) occurring during the transition. An event may be constrained by a guard – a condition which must be true for the transition to occur.

© 2005 Prentice Hall12-13 State Transition Diagrams (continued).

© 2005 Prentice Hall12-14 State Transition Diagrams (continued) A state transition diagram may be decomposed into subdiagrams in order to reduce its complexity.

© 2005 Prentice Hall12-15 Modeling the Interface Dialogue with State Transition Diagrams Two state transition diagrams can be used to model the user-computer dialogue – one diagram for the human processor and one for the computer. The pair of diagrams shows the synchronization more clearly than a single diagram. Actions of the user are the events which trigger transitions in the computer, and vice versa.

© 2005 Prentice Hall12-16 Real Use Case Narratives Expanded real use case narratives may help in designing the interaction. They record decisions about the details of the technology, which were deliberately omitted from the essential narratives developed during analysis.

© 2005 Prentice Hall12-17 Real Use Case Narratives (continued).

© 2005 Prentice Hall12-18 An Example of a State Transition Diagram.

© 2005 Prentice Hall12-19 Navigation Navigation is the process of moving through the windows of a graphical user interface (or the pages of a Web site). A well-designed interface facilitates this navigation so that the user knows his or her current location along the navigation path.

© 2005 Prentice Hall12-20 Window Navigation Diagrams A window navigation diagram models the windows and the navigation paths between them. Figures and show one type of window navigation diagram.

© 2005 Prentice Hall12-21 Window Navigation Diagrams (continued).

© 2005 Prentice Hall12-22 Window Navigation Diagrams (continued).

© 2005 Prentice Hall12-23 Simulation of the Interface Design A simulation is often the most effective way of communicating the design of the interface to users.

© 2005 Prentice Hall12-24 Specifying the Interface Design.

© 2005 Prentice Hall12-25 Usability Testing of the Interface Design Careful testing of the interface design is critical. Usability testing evaluates users’ satisfaction with the interface. It requires a user. It observes people doing tasks with the product being tested. Interpreting the observations requires judgment and is therefore imprecise.

© 2005 Prentice Hall12-26 Methods of Observation in Usability Testing Three methods of observation are used. Cooperative observation: The designer watches. The user and the designer may ask each other questions. Observation in a controlled environ- ment: The user thinks out loud. The designer watches without interacting with the user. Observation in a natural environment: The user performs tasks where the product will be used.

© 2005 Prentice Hall12-27 The Interface to the Presentation Layer Although user-computer interaction happens at the automation boundary, user requests must reach the business layer via the presentation layer. What kind of visibility should the objects in the GUI have to the business layer? How shall we connect the application layer to the presentation layer?

© 2005 Prentice Hall12-28 The Interface to the Presentation Layer (continued).

© 2005 Prentice Hall12-29 The Model-View Separation Pattern The Model-View Separation pattern enforces the principle that the layers of the three-tier model should have minimum coupling. It permits only indirect communication from the application layer to the presentation layer.

© 2005 Prentice Hall12-30 The Model-View Separation Pattern (continued).

© 2005 Prentice Hall12-31 Advantages of Model-View Separation Minimizes the impact of interface changes on the application layer; Minimizes the impact of changes to the application logic on the user interface; Permits multiple views of the same application object, such as a spreadsheet and a chart;

© 2005 Prentice Hall12-32 Advantages of Model-View Separation (continued) Permits the application layer to be used with another kind of user interface; Allows parallel development of the user interface and the application layer; and Allows execution of the application logic apart from the normal user interface.

© 2005 Prentice Hall12-33 Model-View Separation – An Example.

© 2005 Prentice Hall12-34 Summary State transition diagrams effectively model the details of user-computer interaction at the automation boundary. Window navigation diagrams model the navigation paths between the windows in a GUI or the pages of a Web site. The Model-View Separation pattern allows only indirect communication from objects in the business layer to those in the presentation layer.