Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
5.3 Styles of human–computer interface 55 responses to system-generated queries. If we take as an example the instruction to delete a file, the command to do it typically looks like this: del c:\file.txt where the user has to key in this text (accurately), following a prompt from the system. This type of command is associated with such operating systems as Unix. This kind of interaction is error prone, very unforgiving if an error occurs, and relatively difficult to learn. Clearly, command line interfaces are not suitable for casual and inexperienced users. On the other hand, experienced users often prefer a command line interface. A development of the command line is the menu interface. The user is offered a choice of commands, like this: To delete the file, key D To display the file, key L To open a file, key O To save the file, key S after which the user makes their selection by pressing the appropriate key. Menu-based systems have several advantages over a command line interface: ■ users do not need to remember what is on offer ■ users do not need to know command names ■ typing effort is minimal ■ some kinds of user error are avoided (e.g. invalid menu options can be disabled) ■ syntax errors are prevented ■ context-dependent help can be provided. The ATM, specified in Appendix A and designed later in this chapter uses a menu interface. The user uses buttons to select options. Use of a mouse is inappropriate since it is not sufficiently robust for use in open-air, public situations. Developments in user interfaces have been largely enabled by more sophisticated technology – early computers only had facilities for text input and output, whereas modern computers have high-resolution bit mapped displays and pointing devices. As hardware became more sophisticated, and software engineers learned more about human factors and their impact on interface design, the modern window-oriented, point and pick interface evolved – with a GUI or WIMP (windows, icons, menus and pointing devices). Such an interface presents the user with a set of controls or widgets (window gadgets), such as buttons, scroll bars and text boxes. Instead of typing an option the user makes a selection using the mouse and mouse button. The advantages of GUIs include: ■ they are relatively easy to learn and use ■ the user can use multiple windows for system interaction ■ fast, full-screen interaction is possible with immediate access to anywhere on the screen
56 Chapter 5 ■ User interface design ■ different types of information can be displayed simultaneously, enabling the user to switch contexts ■ the use of graphical icons, pull-down menus, buttons and scrolling techniques reduce the amount of typing. One way of helping to achieve interface consistency is to define a consistent model or metaphor for user–computer interaction, which is analogous to some real world domain that the user understands. A direct manipulation interface presents users with a visual model of their information space. The best known of these is the desktop metaphor, familiar to users of Microsoft and Apple Macintosh operating systems. Another example is a WYSIWYG (what you see is what you get) word processor. While there is a massive trend towards multitasking, window-oriented, point and pick interfaces which can make HCI easier, this only happens if careful design of the interface is conducted. Using a GUI is, in itself, no guarantee of a good interface. 5.4 ● Different perspectives on user interface design In designing a user interface it is as well to realize that there are several potentially different viewpoints. The perspectives are: ■ the end-user who will eventually get to use the software ■ different end-users with different personalities ■ the novice or occasional user ■ the experienced or power user ■ users with different types of skill ■ the software developer who designs and implements the system. Most people do not apply any formal reasoning when confronted with a problem, such as understanding what a computer is displaying. Rather, they apply a set of guidelines, rules and strategies based on their understanding of similar problems. These are called heuristics. These heuristics tend to be domain specific – an identical problem, encountered in entirely different contexts, might be solved by applying different heuristics. A user interface should be developed in a manner that enables the human to develop heuristics for interaction. The problem is that different people often have different perspectives of the user interface; they also have different skills, culture and personalities. Each person has some model of how the system works and what it does. These different perspectives are sometimes called mental models. An interface used by two individuals with the same education and background but entirely different personalities may seem friendly to one and unfriendly to the other. Therefore, the ideal user interface would be designed to accommodate differences in personality, or, alternatively, would be designed to accommodate a typical personality among a class of end users. A third possibility is to create an interface that is flexible and can be used in different ways according to personality differences.
- Page 28 and 29: 1.3 The cost of software production
- Page 30 and 31: 100% 10% 1970 SELF-TEST QUESTION Ha
- Page 32 and 33: Analysis and design 1 /3 Coding 1 /
- Page 34 and 35: SELF-TEST QUESTION 1.7 Maintenance
- Page 36 and 37: 1.8 Reliability 13 in the first pla
- Page 38 and 39: 1.8 Reliability 15 contain a comma
- Page 40 and 41: Ease of maintenance Reliability Con
- Page 42 and 43: Exercises 19 • Exercises These ex
- Page 44 and 45: Further reading 21 Analyses of the
- Page 46 and 47: ■ documentation ■ maintenance
- Page 48 and 49: 2.2 The tasks 25 An important examp
- Page 50 and 51: 2.4 Methodology 27 reality. Like an
- Page 52 and 53: ■ error free ■ fault ■ tested
- Page 54 and 55: 3.2 ● Technical feasibility 3.3 C
- Page 56 and 57: 3.5 Case study 33 The hardware cost
- Page 58 and 59: Answers to self-test questions 3.1
- Page 60 and 61: 4.2 The concept of a requirement 37
- Page 62 and 63: 4.3 The qualities of a specificatio
- Page 64 and 65: 4.5 The requirements specification
- Page 66 and 67: 4.6 The structure of a specificatio
- Page 68 and 69: 4.7 ● Use cases 4.7 Use cases 45
- Page 70 and 71: Summary The ideal characteristics o
- Page 72: Further reading 49 Further reading
- Page 76 and 77: CHAPTER 5 This chapter explains: 5.
- Page 80 and 81: 5.5 Design principles and guideline
- Page 82 and 83: 5.5 Design principles and guideline
- Page 84 and 85: SELF-TEST QUESTION 5.2 What problem
- Page 86 and 87: 5.8 Help systems 63 Our plan is to
- Page 88 and 89: Further reading 65 5.5 Design a use
- Page 90 and 91: CHAPTER 6 Modularity This chapter e
- Page 92 and 93: 6.2 Why modularity? 69 observed fau
- Page 94 and 95: Figure 6.1 Two alternative software
- Page 96 and 97: ■ a simple program is more likely
- Page 98 and 99: 6.6 Information hiding 75 The class
- Page 100 and 101: 6.8 ● Coupling 6.8 Coupling 77 We
- Page 102 and 103: 6. Method calls with parameters tha
- Page 104 and 105: 3. Temporal cohesion 6.9 Cohesion 8
- Page 106 and 107: > } public void setY(int newY) { y
- Page 108 and 109: • Exercises 6.1 What is modularit
- Page 110 and 111: CHAPTER 7 Structured programming Th
- Page 112 and 113: 7.2 Arguments against goto 89 If we
- Page 114 and 115: ■ if-then-else ■ while-do or re
- Page 116 and 117: 7.3 Arguments in favor of goto 93 l
- Page 118 and 119: 7.4 Selecting control structures 95
- Page 120 and 121: while do if endif then else endWhil
- Page 122 and 123: • Exercises 7.1 Review the argume
- Page 124 and 125: count = 0 loop: count = count + 1 i
- Page 126 and 127: > 8.2 Case study 103 A statement th
56 Chapter 5 ■ User interface design<br />
■ different types of in<strong>for</strong>mation can be displayed simultaneously, enabling the user to<br />
switch contexts<br />
■ the use of graphical icons, pull-down menus, buttons and scrolling techniques<br />
reduce the amount of typing.<br />
One way of helping to achieve interface consistency is to define a consistent model<br />
or metaphor <strong>for</strong> user–computer interaction, which is analogous to some real world<br />
domain that the user understands. A direct manipulation interface presents users with<br />
a visual model of their in<strong>for</strong>mation space. The best known of these is the desktop<br />
metaphor, familiar to users of Microsoft and Apple Macintosh operating systems.<br />
Another example is a WYSIWYG (what you see is what you get) word processor.<br />
While there is a massive trend towards multitasking, window-oriented, point and<br />
pick interfaces which can make HCI easier, this only happens if careful design of the<br />
interface is conducted. Using a GUI is, in itself, no guarantee of a good interface.<br />
5.4 ● Different perspectives on user interface design<br />
In designing a user interface it is as well to realize that there are several potentially different<br />
viewpoints. The perspectives are:<br />
■ the end-user who will eventually get to use the software<br />
■ different end-users with different personalities<br />
■ the novice or occasional user<br />
■ the experienced or power user<br />
■ users with different types of skill<br />
■ the software developer who designs and implements the system.<br />
Most people do not apply any <strong>for</strong>mal reasoning when confronted with a problem,<br />
such as understanding what a computer is displaying. Rather, they apply a set of guidelines,<br />
rules and strategies based on their understanding of similar problems. These are<br />
called heuristics. These heuristics tend to be domain specific – an identical problem,<br />
encountered in entirely different contexts, might be solved by applying different heuristics.<br />
A user interface should be developed in a manner that enables the human to develop<br />
heuristics <strong>for</strong> interaction.<br />
The problem is that different people often have different perspectives of the user<br />
interface; they also have different skills, culture and personalities. Each person has some<br />
model of how the system works and what it does. These different perspectives are sometimes<br />
called mental models.<br />
An interface used by two individuals with the same education and background but<br />
entirely different personalities may seem friendly to one and unfriendly to the other.<br />
There<strong>for</strong>e, the ideal user interface would be designed to accommodate differences in<br />
personality, or, alternatively, would be designed to accommodate a typical personality<br />
among a class of end users. A third possibility is to create an interface that is flexible and<br />
can be used in different ways according to personality differences.
Change language