1. CS 240, Prof. Sarwar Slide 1 CS 240: Software Project Fall 2003 Sections 1 & 2 Dr. Badrul M. Sarwar San Jose State University Lecture #14

2. CS 240, Prof. Sarwar Slide 2 Agenda l Software Reuse:  Design patterns  Review l User Interface Design  Principles  User Interaction  Information Presentation  User support  Interface Evaluation l Implementation: Coding Standards  Creating Data  General Issues in Using Variables

3. CS 240, Prof. Sarwar Slide 3 Design Patterns: Background l When we try to reuse executable components  we are constrained by detailed design decisions that have been made by the implementers of these components  It makes reuse of the component either impossible or introduces significant inefficiencies.  One solution is to reuse more abstract designs that do not include implementation details  Design patterns

4. CS 240, Prof. Sarwar Slide 4 Problems with Inheritance Hashtable put (key, element) get (key): object containsKey (key): boolean containsValue(element): boolean MySet put (key, element) containsValue(element): boolean class MySet extends Hashtable { //constructors void put (Object element) { if (!containsKey (element)) { put (element, this); } boolean containsValue (Object element) { return containsKey(element); } //other methods }

5. CS 240, Prof. Sarwar Slide 5 Problems:  containsKey() checks if the specified object exists as a key in the hash table  containsValue() checks if the specified object exists as an entry in the hash table l But in the previous implementation containsValue() has the same behavior as the containsKey–counterintuitive. l Even worse, it makes it difficult to change the internal representation of MySet in future. For instance, if we want to implement MySet using list instead of hash table then all invocations to containsKey() would be invalid l Problem: inheritance introduces a strong coupling along the inheritance hierarchy l It is useful when the hierarchy represents a taxonomy e.g. Image and GIFImage, but in other cases it introduces unwanted coupling.

6. CS 240, Prof. Sarwar Slide 6 Solution: use of delegation Hashtable put (key, element) get (key): object containsKey (key): boolean containsValue(element): boolean MySet put (key, element) containsValue(element): boolean class MySet { private Hashtable table; MySet() { table = HashTable(); } void put (Object element) { if (!containsValue (element)) { table.put (element, this); } boolean containsValue (Object element) { return table.containsKey(element); } //other methods } table 1 1

7. CS 240, Prof. Sarwar Slide 7 Design Patterns: Background l Delegation:  Delegation is an alternative to inheritance that should be used when reuse is desired  A class is said to delegate to another class if it implements an operation by resending a message to another class  Delegation makes it explicit the dependencies between the reused class and the new class  It’s a preferable mechanism to implement inheritance as it doesn’t interfere with existing components and leads to more robust code l However, when to use delegation or inheritance is not always clear and requires some experience and judgment of the developer l Design patterns  are template solutions that developers have refined over time to solve a range of recurring problems  These are composed of a small number of classes that, through delegation and inheritance provide a robust and modifiable solution

8. CS 240, Prof. Sarwar Slide 8 Design patterns l A design pattern is a way of reusing abstract knowledge about a problem and its solution l A pattern is a description of the problem and the essence of its solution l It should be sufficiently abstract to be reused in different settings l Patterns often rely on object characteristics such as inheritance and polymorphism

9. CS 240, Prof. Sarwar Slide 9 Design Pattern elements l Name  A meaningful and unique pattern identifier l Problem description  describes the situations in which the patter can be used l Solution description  Not a concrete design but a template for a design solution that can be instantiated in different ways. It is a set of collaboration classes and interfaces l Consequences  The results and trade-offs of applying the pattern

10. CS 240, Prof. Sarwar Slide 10 Selecting Design Patterns and Components l System design and Object design with reuse introduce a strange paradox:  system design: the goal is to build a stable structure to deal with complexity; we build strong walls between subsystems  object design: we also want to allow flexibility to deal with changes and reuse; we design our objects to be modifiable and extensible l To solve this conflict: we need to anticipate changes and design for it so that it can handle:  New vendor or new technology  New implementation  New views  New complexity of the application domain  Errors

11. CS 240, Prof. Sarwar Slide 11 Types of Design Patterns l Here are a few Design Patterns that are widely used:  Adapter Design Pattern  Bridge Design Pattern  Strategy Design Pattern  Abstract Factory Design Pattern  Command Design Pattern  Composite Design Pattern

12. CS 240, Prof. Sarwar Slide 12 Adapter Design Patterns l Anticipated changes: New vendor, new technology, new implementation l Encapsulates a piece of legacy code that was not designed to work with the system l It also limits the impact of substituting the piece of legacy code for a different component.

13. CS 240, Prof. Sarwar Slide 13 Bridge Design Patterns l Anticipated changes: New vendor, new technology, new implementation l Decouples the interface of a class from its implementation l It serves the same purpose of an Adapter pattern except that the developer is not constrained by an existing component

14. CS 240, Prof. Sarwar Slide 14 Strategy Design Patterns l Anticipated changes: New vendor, new technology, new implementation l Decouples an algorithm from its implementation l It serves the same purpose of an Adapter and bridge patterns except that the encapsulated unit is a behavior

15. CS 240, Prof. Sarwar Slide 15 Abstract Factory Design Patterns l Anticipated changes: New vendor, new technology l Encapsulates the creation of families of related objects l It shields the client from the creation process and prevents the use of objects from different (incompatible) families

16. CS 240, Prof. Sarwar Slide 16 Abstract Factory Pattern l Abstract classes and abstract (virtual) methods l The interfaces between the client and the generator are abstract l The application program is uncoupled from the specific operating system

17. CS 240, Prof. Sarwar Slide 17 Command Design Patterns l Anticipated changes: New functionality l Decouples the objects responsible for command processing from the commands themselves l It protects these objects from changes due to new functionality

18. CS 240, Prof. Sarwar Slide 18 Composite Design Patterns l Anticipated changes: New complexity o the application domain l Encapsulates hierarchies by providing a common superclass for aggregate and leaf nodes. l New types of leafs can be added without modifying existing code.

19. CS 240, Prof. Sarwar Slide 19 User interface design l Designing effective interfaces for software systems

20. CS 240, Prof. Sarwar Slide 20 Objectives l To suggest some general design principles for user interface design l To explain different interaction styles l To introduce styles of information presentation l To describe the user support which should be built-in to user interfaces l To introduce usability attributes and system approaches to system evaluation

21. CS 240, Prof. Sarwar Slide 21 The user interface l System users often judge a system by its interface rather than its functionality l A poorly designed interface can cause a user to make catastrophic errors l Poor user interface design is the reason why so many software systems are never used

22. CS 240, Prof. Sarwar Slide 22 Graphical user interfaces (GUI) l Almost all computer users now have personal computers that provide GUI, which has the following features

23. CS 240, Prof. Sarwar Slide 23 GUI advantages l They are easy to learn and use.  Users without experience can learn to use the system quickly. l The user may switch quickly from one task to another and can interact with several different applications.  Information remains visible in its own window when attention is switched. l Fast, full-screen interaction is possible with immediate access to anywhere on the screen

24. CS 240, Prof. Sarwar Slide 24 User-centred design l We’ll focus mainly on key issues underlying the end-user design rather than the implementation of user interfaces l Suggested reading Ben Shneiderman’s text “Designing the User Interface” (a must read for Software Engineers specializing in the area of UI design) l User-centred design is an approach to UI design where the needs of the user are paramount and where the user is involved in the design process l UI design always involves the development of prototype interfaces

25. CS 240, Prof. Sarwar Slide 25 User interface design process

26. CS 240, Prof. Sarwar Slide 26 UI design principles l UI design must take account of the needs, experience and capabilities of the system users l Designers should be aware of people’s physical and mental limitations (e.g. limited short-term memory Miller’s principle) and should recognise that people make mistakes l UI design is very much tied to human psychology l UI design principles underlie interface designs although not all principles are applicable to all designs

27. CS 240, Prof. Sarwar Slide 27 User interface design principles

28. CS 240, Prof. Sarwar Slide 28 Design principles l User familiarity  The interface should be based on user-oriented terms and concepts rather than computer concepts. For example, an office system should use concepts such as letters, documents, folders etc. rather than directories, file identifiers, etc. l Consistency  The system should display an appropriate level of consistency. Commands and menus should have the same format, command punctuation should be similar, etc. l Minimal surprise  If a command operates in a known way, the user should be able to predict the operation of comparable commands

29. CS 240, Prof. Sarwar Slide 29 Design principles l Recoverability  The system should provide some resilience to user errors and allow the user to recover from errors. This might include an undo facility, confirmation of destructive actions, 'soft' deletes, etc. l User guidance  Some user guidance such as help systems, on-line manuals, etc. should be supplied l User diversity  Interaction facilities for different types of user should be supported. For example, some users have seeing difficulties and so larger text should be available

30. CS 240, Prof. Sarwar Slide 30 User-system interaction l Two problems must be addressed in interactive systems design  How should information from the user be provided to the computer system?  How should information from the computer system be presented to the user? l User interaction and information presentation may be integrated through a coherent framework such as a user interface metaphor

31. CS 240, Prof. Sarwar Slide 31 Interaction styles l In his text “Designing the User Interface” Ben Shneiderman has classified different forms of interaction into five primary styles  Direct manipulation  Menu selection  Form fill-in  Command language  Natural language

32. Advantages and disadvantages

33. CS 240, Prof. Sarwar Slide 33 Direct manipulation advantages l Users feel in control of the computer and are less likely to be intimidated by it l User learning time is relatively short l Users get immediate feedback on their actions so mistakes can be quickly detected and corrected

34. CS 240, Prof. Sarwar Slide 34 Direct manipulation problems l The derivation of an appropriate information space model can be very difficult l Given that users have a large information space, what facilities for navigating around that space should be provided? l Direct manipulation interfaces can be complex to program and make heavy demands on the computer system

35. CS 240, Prof. Sarwar Slide 35 Control panel interface

36. CS 240, Prof. Sarwar Slide 36 Menu systems l Users make a selection from a list of possibilities presented to them by the system l The selection may be made by pointing and clicking with a mouse, using cursor keys or by typing the name of the selection l May make use of simple-to-use terminals such as touchscreens

37. CS 240, Prof. Sarwar Slide 37 Advantages of menu systems l Users need not remember command names as they are always presented with a list of valid commands l Typing effort is minimal l User errors are trapped by the interface l Context-dependent help can be provided. The user’s context is indicated by the current menu selection

38. CS 240, Prof. Sarwar Slide 38 Problems with menu systems l Actions which involve logical conjunction (and) or disjunction (or) are awkward to represent l Menu systems are best suited to presenting a small number of choices. If there are many choices, some menu structuring facility must be used l Experienced users find menus slower than command language

39. CS 240, Prof. Sarwar Slide 39 Form-based interface

40. CS 240, Prof. Sarwar Slide 40 Command interfaces l User types commands to give instructions to the system e.g. UNIX l May be implemented using cheap terminals. l Easy to process using compiler techniques l Commands of arbitrary complexity can be created by command combination l Concise interfaces requiring minimal typing can be created

41. CS 240, Prof. Sarwar Slide 41 Problems with command interfaces l Users have to learn and remember a command language. Command interfaces are therefore unsuitable for occasional users l Users make errors in command. An error detection and recovery system is required l System interaction is through a keyboard so typing ability is required

42. CS 240, Prof. Sarwar Slide 42 Command languages l Often preferred by experienced users because they allow for faster interaction with the system l Not suitable for casual or inexperienced users l May be provided as an alternative to menu commands (keyboard shortcuts). In some cases, a command language interface and a menu-based interface are supported at the same time

43. CS 240, Prof. Sarwar Slide 43 Natural language interfaces l The user types a command in a natural language. Generally, the vocabulary is limited and these systems are confined to specific application domains (e.g. timetable enquiries) l NL processing technology is now good enough to make these interfaces effective for casual users but experienced users find that they require too much typing

44. CS 240, Prof. Sarwar Slide 44 Multiple user interfaces

45. CS 240, Prof. Sarwar Slide 45 Information presentation l Information presentation is concerned with presenting system information to system users l The information may be presented directly (e.g. text in a word processor) or may be transformed in some way for presentation (e.g. in some graphical form) l The Model-View-Controller approach is a way of supporting multiple presentations of data

46. CS 240, Prof. Sarwar Slide 46 Information presentation

47. CS 240, Prof. Sarwar Slide 47 Model-view-controller

48. CS 240, Prof. Sarwar Slide 48 Information presentation l Static information  Initialised at the beginning of a session. It does not change during the session  May be either numeric or textual l Dynamic information  Changes during a session and the changes must be communicated to the system user  May be either numeric or textual

49. CS 240, Prof. Sarwar Slide 49 Information display factors l Is the user interested in precise information or data relationships? l How quickly do information values change? Must the change be indicated immediately? l Must the user take some action in response to a change? l Is there a direct manipulation interface? l Is the information textual or numeric? Are relative values important?

50. CS 240, Prof. Sarwar Slide 50 Alternative information presentations

51. CS 240, Prof. Sarwar Slide 51 Analogue vs. digital presentation l Digital presentation  Compact - takes up little screen space  Precise values can be communicated l Analogue presentation  Easier to get an 'at a glance' impression of a value  Possible to show relative values  Easier to see exceptional data values

52. CS 240, Prof. Sarwar Slide 52 Dynamic information display

53. CS 240, Prof. Sarwar Slide 53 Displaying relative values

54. CS 240, Prof. Sarwar Slide 54 Textual highlighting

55. CS 240, Prof. Sarwar Slide 55 Data visualisation l Concerned with techniques for displaying large amounts of information l Visualisation can reveal relationships between entities and trends in the data l Possible data visualisations are:  Weather information collected from a number of sources  The state of a telephone network as a linked set of nodes  Chemical plant visualised by showing pressures and temperatures in a linked set of tanks and pipes  A model of a molecule displayed in 3 dimensions  Web pages displayed as a hyperbolic tree

56. CS 240, Prof. Sarwar Slide 56 Colour displays l Colour adds an extra dimension to an interface and can help the user understand complex information structures l Can be used to highlight exceptional events l Common mistakes in the use of colour in interface design include:  The use of colour to communicate meaning  Over-use of colour in the display

57. CS 240, Prof. Sarwar Slide 57 Colour use guidelines l Don't use too many colours l Use colour coding to support use tasks l Allow users to control colour coding l Design for monochrome then add colour l Use colour coding consistently l Avoid colour pairings which clash l Use colour change to show status change l Be aware that colour displays are usually lower resolution

58. CS 240, Prof. Sarwar Slide 58 User support l User guidance covers all system facilities to support users including on-line help, error messages, manuals etc. l The user guidance system should be integrated with the user interface to help users when they need information about the system or when they make some kind of error l The help and message system should, if possible, be integrated

59. CS 240, Prof. Sarwar Slide 59 Help and message system

60. CS 240, Prof. Sarwar Slide 60 Error messages l Error message design is critically important. Poor error messages can mean that a user rejects rather than accepts a system l Messages should be polite, concise, consistent and constructive l The background and experience of users should be the determining factor in message design

61. CS 240, Prof. Sarwar Slide 61 Design factors in message wording

62. CS 240, Prof. Sarwar Slide 62 Help system design l Help? means ‘help I want information” l Help! means “HELP. I'm in trouble” l Both of these requirements have to be taken into account in help system design l Different facilities in the help system may be required

63. CS 240, Prof. Sarwar Slide 63 Help information l Should not simply be an on-line manual l Screens or windows don't map well onto paper pages. l The dynamic characteristics of the display can improve information presentation. l People are not so good at reading screen as they are text.

64. CS 240, Prof. Sarwar Slide 64 Help system use l Multiple entry points should be provided so that the user can get into the help system from different places. l Some indication of where the user is positioned in the help system is valuable. l Facilities should be provided to allow the user to navigate and traverse the help system.

65. CS 240, Prof. Sarwar Slide 65 User documentation l As well as on-line information, paper documentation should be supplied with a system l Documentation should be designed for a range of users from inexperienced to experienced l As well as manuals, other easy-to-use documentation such as a quick reference card may be provided

66. CS 240, Prof. Sarwar Slide 66 User document types

67. CS 240, Prof. Sarwar Slide 67 Document types l Functional description  Brief description of what the system can do l Introductory manual  Presents an informal introduction to the system l System reference manual  Describes all system facilities in detail l System installation manual  Describes how to install the system l System administrator’s manual  Describes how to manage the system when it is in use

68. CS 240, Prof. Sarwar Slide 68 User interface evaluation l Some evaluation of a user interface design should be carried out to assess its suitability l Full scale evaluation is very expensive and impractical for most systems l Ideally, an interface should be evaluated against a usability specification. However, it is rare for such specifications to be produced

69. CS 240, Prof. Sarwar Slide 69 Usability attributes

70. CS 240, Prof. Sarwar Slide 70 Simple evaluation techniques l Questionnaires for user feedback l Video recording of system use and subsequent tape evaluation. l Instrumentation of code to collect information about facility use and user errors. l The provision of a grip button for on-line user feedback.

71. CS 240, Prof. Sarwar Slide 71 Implementation Coding Standards From the text “Code Complete”

72. CS 240, Prof. Sarwar Slide 72 Creating Data l User defined data types  one of the most powerful features of programming languages  makes code more readable  Easy to make changes--suitable for evolution  we should take advantage of this feature  Ex: typedef float Coordinate_t; … Routine1(…) { Coordinate_t latitude; Coordinate_t longitude; Coordinate_t altitude; } readable changeable if you need to change everything to double that can be easily done

73. CS 240, Prof. Sarwar Slide 73 Guidelines for Data Initialization l Improper data initialization can be a potential source of errors in a program. Using a good initialization strategy can solve a lot of debugging time l Most common mistake uninitialized pointer variables l Reasons for improper initializations  the variable is never assigned a value and runs with the value that corresponds to the bits in that memory location at the creation time  the value is outdated--the variable was assigned a value at some point but is no longer valid  incomplete assignment--part of the variable is assigned a value and part is not. Happens especially with pointer variables. With objects and structures assigning pointer values is not sufficient--leads to shallow copying.

74. CS 240, Prof. Sarwar Slide 74 Guidelines for Data Initialization (2) l Here are guidelines for avoiding initialization problems  Apply defensive programming techniques (use of assertions, exceptions etc.)  Check input parameters for validity: before assigning input values to a parameter make sure the values are reasonable (boundary checking)  Initialize each variable close to where it’s used int Idx = 0, Total = 10; float sum = 0.0; … while (Total > 0) { … } int Idx, Total; float sum; … Idx = 0; //code using Idx … Total = 10; while (Total > 0) { … } bad example good example

75. CS 240, Prof. Sarwar Slide 75 Guidelines for Data Initialization (3)  The previous case demonstrates an important principle in programming called the principle of proximity: keep related actions together l Pay special attention to counters and accumulators  A common mistake is forgetting to reinitialize loop counters (I,j etc.) before using them next time l Check the need for reinitialization l Initialize variables as it’s declared  not as good as initializing close to where they are used, but it’s a good programming practice and can solve the problems of uninitialized variables l Pay attentions to the compiler warnings l Use a memory access checker to check for bad pointers

76. CS 240, Prof. Sarwar Slide 76 Choosing Good Variable Names l A variable should be named according to its function  X = X - Y; //is legal but hardly makes any sense and not readable  Balance = Balance - LastPayment //on the other hand, is fully readable //and makes perfect sense l Most important consideration in naming a variable  the name should fully and accurately describe the entity the variable represents  so an effective technique would be to state in words what the variable represents  like float CurrentInterestRate  But sometimes it can be too long  int NumberOfPeopleOnTheUSOlympicTeam

77. CS 240, Prof. Sarwar Slide 77 Choosing Good Variable Names (2) l Problem Orientation  A good mnemonic name generally speaks to the problem rather than the solution  it expresses the what more than the how.  For example, EmployeeData is a better problem oriented name than InputRec and PrinterReady is better than BitFlag l Optimum name length  No hard and fast rule, but if it’s too short it may not convey the idea properly, too long names are awkward and may obscure the visual structure of the program  Some researchers suggest names of 8 to 16 characters long  Remember the goals  should sufficiently express the function  should be long enough to be unambiguous  should be short enough to be useful in keeping the visual structure of the program

78. CS 240, Prof. Sarwar Slide 78 Choosing Good Variable Names (2) l Guidelines for good naming  Try to use postfixes to qualify operations  RevenueTotal, RevenueAvg, are better than AvgRevenue and TotalRevenue  Use opposites precisely  e.g., first/last makes more sense than first/end. Other examples of good opposites are begin/end, add/remove, min/max, start/stop, show/hide etc.

79. CS 240, Prof. Sarwar Slide 79