1. Software Engineering Lecture 13: User Interface and Component-Level Design

2. Today’s Topics l Interface Design Design Principles Design Models & Design Issues Evaluating Interface Designs l Component-Level Design Structured Programming Models (flowchart, box, table, PDL) Comparing Notations

3. Types of Interfaces l Between software components l Between software and external (non-human) entities l Between humans and software Software quality is impeded by the frustration and anxiety caused by poorly-designed interfaces

4. The “Golden Rules” [Mandel ‘97] l Place the User in Control l Reduce the User’s Memory Load l Make the Interface Consistent Three important evaluation criteria for interface design

5. Place the User in Control l Don’t force unnecessary or unwanted actions l Provide flexible interaction l Provide interactions that can be interrupted or undone l Streamline interaction for experts; allow customization l Support direct visual interaction with task-related objects

6. Reduce the User’s Memory Load l Reduce demand on short-term memory; use visual cues l Establish meaningful defaults l Define intuitive shortcuts (e.g. alt-P to invoke “Print File”) l Use visual layouts based on a real-world metaphor l Present detailed information in layers

7. Make the Interface Consistent l Clearly identify the context of the current task (icons, color codes, …) l Maintain consistency across a family of applications l Don’t change existing conventions unless absolutely necessary

8. Interface Design Models l Design Model (data, modules, etc.) l User Model (novice, expert, etc.) l User’s Model (“system perception”) l System Image (“look & feel”) The interface designed must reconcile these four views to derive a consistent representation

9. Interface Design Process [From SEPA 5/e]

10. Interface Design Activities l Establish goals, intentions for each task l Map each goal and intention to a sequence of specific actions l Create user scenarios for interface l Specify system state at each step l Define control mechanisms & how they affect system state l State how the user interprets the state of the task from the interface

11. Interface Design Issues l System Response Time average response time variability in response time l User Help Facilities integrated, context-sensitive help add-on help

12. Design Issues [2] l Error Handling avoid jargon! indicate consequences offer a remedy l Command Labeling menu vs. keystrokes key input scheme use mnemonic commands!

13. Design Evaluation [From SEPA 5/e]

14. Evaluation Criteria l Complexity of interface spec vs. learning effort required l # of tasks & steps/task vs. interaction time & overall efficiency l # of actions, tasks, states vs. memory load on user l Style, help, error handling vs. overall complexity, acceptance

15. Evaluation Criteria [2] l Collecting data: Qualitative Data e.g., via questionnaire Quantitative Data e.g. via formal user study

16. Component-Level Design l Also referred to as “detailed design” l A description of the steps performed by each module l Intermediate representation between modular design and program code l E.g. flowcharts, pseudocode, …

17. Structured Programming l A set of logical constructs which form the basis for any program: Sequence (processing steps) Condition (if/then/else statements) Repetition (for loops)

18. Flowchart Constructs [From SEPA 5/e]

19. Nesting Constructs [From SEPA 5/e]

20. Box Diagram Constructs [From SEPA 5/e]

21. Decision Tables [From SEPA 5/e]

22. Program Design Language (PDL) l Also called structured English or pseudocode l Generic programming syntax with embedded English statements l Can’t be compiled! l See example on pages 430-431 in the Pressman text l Less visual, but more detailed than flowcharts (e.g., type declarations)

23. Comparing Design Notations l Modularity Support for modules and interfaces l Simplicity Easy to learn, use, read l Ease of Editing Streamline the refinement process l Machine Readability Automatic conversion to code

24. Comparing Notations [2] l Maintainability Design updates are common l Structure Enforcement Promotes quality & robustness l Automatic Processing Immediate quality feedback l Data Representation Represent local and global data

25. Comparing Notations [3] l Logic Verification Automatic design checking l “Code-To” Ability Easy conversion to source code

26. Questions?

27. Software Engineering for Information Technology Lecture 13: User Interface and Component-Level Design

28. Today’s Topics l Interface Design Design Principles Design Models & Design Issues Evaluating Interface Designs l Component-Level Design Structured Programming Models (flowchart, box, table, PDL) Comparing Notations

29. Types of Interfaces l Between software components l Between software and external (non-human) entities l Between humans and software Software quality is impeded by the frustration and anxiety caused by poorly-designed interfaces

30. The “Golden Rules” [Mandel ‘97] l Place the User in Control l Reduce the User’s Memory Load l Make the Interface Consistent Three important evaluation criteria for interface design

31. Place the User in Control l Don’t force unnecessary or unwanted actions l Provide flexible interaction l Provide interactions that can be interrupted or undone l Streamline interaction for experts; allow customization l Support direct visual interaction with task-related objects

32. Reduce the User’s Memory Load l Reduce demand on short-term memory; use visual cues l Establish meaningful defaults l Define intuitive shortcuts (e.g. alt-P to invoke “Print File”) l Use visual layouts based on a real-world metaphor l Present detailed information in layers

33. Make the Interface Consistent l Clearly identify the context of the current task (icons, color codes, …) l Maintain consistency across a family of applications l Don’t change existing conventions unless absolutely necessary

34. Interface Design Models l Design Model (data, modules, etc.) l User Model (novice, expert, etc.) l User’s Model (“system perception”) l System Image (“look & feel”) The interface designed must reconcile these four views to derive a consistent representation

35. Interface Design Process [From SEPA 5/e]

36. Interface Design Activities l Establish goals, intentions for each task l Map each goal and intention to a sequence of specific actions l Create user scenarios for interface l Specify system state at each step l Define control mechanisms & how they affect system state l State how the user interprets the state of the task from the interface

37. Interface Design Issues l System Response Time average response time variability in response time l User Help Facilities integrated, context-sensitive help add-on help

38. Design Issues [2] l Error Handling avoid jargon! indicate consequences offer a remedy l Command Labeling menu vs. keystrokes key input scheme use mnemonic commands!

39. Design Evaluation [From SEPA 5/e]

40. Evaluation Criteria l Complexity of interface spec vs. learning effort required l # of tasks & steps/task vs. interaction time & overall efficiency l # of actions, tasks, states vs. memory load on user l Style, help, error handling vs. overall complexity, acceptance

41. Evaluation Criteria [2] l Collecting data: Qualitative Data e.g., via questionnaire Quantitative Data e.g. via formal user study

42. Component-Level Design l Also referred to as “detailed design” l A description of the steps performed by each module l Intermediate representation between modular design and program code l E.g. flowcharts, pseudocode, …

43. Structured Programming l A set of logical constructs which form the basis for any program: Sequence (processing steps) Condition (if/then/else statements) Repetition (for loops)

44. Flowchart Constructs [From SEPA 5/e]

45. Nesting Constructs [From SEPA 5/e]

46. Box Diagram Constructs [From SEPA 5/e]

47. Decision Tables [From SEPA 5/e]

48. Program Design Language (PDL) l Also called structured English or pseudocode l Generic programming syntax with embedded English statements l Can’t be compiled! l See example on pages 430-431 in the Pressman text l Less visual, but more detailed than flowcharts (e.g., type declarations)

49. Comparing Design Notations l Modularity Support for modules and interfaces l Simplicity Easy to learn, use, read l Ease of Editing Streamline the refinement process l Machine Readability Automatic conversion to code

50. Comparing Notations [2] l Maintainability Design updates are common l Structure Enforcement Promotes quality & robustness l Automatic Processing Immediate quality feedback l Data Representation Represent local and global data

51. Comparing Notations [3] l Logic Verification Automatic design checking l “Code-To” Ability Easy conversion to source code

52. Questions?

53. Software Engineering for Information Technology Lecture 12: System Design

54. Today’s Topics l Design Elements l Principles for Quality Design l Modularity & Partitioning l Effective Modular Design l Architectural Styles l Mapping Models to Modules

55. Design Elements l Data Design data structures for data objects l Architectural Design modular structure of software l Interface Design internal / external communication l Component-Level Design procedural description of modules

56. [From SEPA 5/e] Increasing Detail Design Elements Linked to Analysis Models

57. Evaluating A Design l A design must implement: explicit requirements (analysis model) customer’s implicit requirements l A design must be readable, understandable by coders & testers l A good design provides a complete view of data, function, and behavior

58. Design Principles [Davis ‘95] l Consider > 1 design alternative l Design traceable to analysis model l Use design patterns l Design structure should reflect structure of problem domain l Consistent style, well-defined interfaces

59. Design Principles [2] l Structured to accommodate change (easy to modify & update) l Structured to degrade gently l “Design is not coding, coding is not design” l Assess quality during creation l Review design for semantic errors

60. Design Process Goals l A hierarchical organization making use of the control characteristics of the software l A modular design which logically partitions software into functional elements l Useful abstractions for both data and procedures

61. Design Goals [2] l Modules should be functionally independent l Modular interfaces should have minimal complexity l Explicit linking of design elements to requirements analysis models

62. Modularity and Software Cost [From SEPA 5/e]

63. Modular Design [Meyer ‘88] l Decomposability effective decomposition reduces complexity l Composability enable reuse of existing design elements l Understandability modules that can be understood in isolation are easier to build and change

64. Modular Design [2] l Continuity changes to requirements should trigger localized changes to specific modules l Protection error conditions should be considered on a per-module basis

65. Architectural Terminology [From SEPA 5/e]

66. Partitioning l Horizontal branches for each major function l Vertical control & execution are top-down l Increase in horizontal partitioning = increased number of interfaces l Vertically partitioned structures more resilient to change

67. [From SEPA 5/e] Partitioning Examples

68. Procedural Layering [From SEPA 5/e]

69. Effective Modular Design l Functional independence maximize cohesion of modules minimize coupling between modules promote robustness in the design l Cohesion one task per procedure is optimal l Coupling minimize module interconnection

70. Types of Coupling [From SEPA 5/e]

71. Design Heuristics l Reduce coupling (implode) l Improve cohesion (explode) l Minimize fan-out & strive for fan-in l Scope of effect = scope of control l Reduce interface complexity l Predictable “black box” modules l Controlled entry (no GOTOs!)

72. Program Structures [From SEPA 5/e]

73. Architectural Styles l Data-Centered l Data-Flow l Call-and-Return main program / subprogram remote procedure call l Layered

74. Data-Centered Architecture [From SEPA 5/e]

75. Data Flow Architectures [From SEPA 5/e]

76. Layered Architecture [From SEPA 5/e]

77. Mapping Models to Modules l Goal: map DFDs to a modular architecture l Transform Mapping data flow is modeled as a series of functions with input / output l Transaction Mapping: data flow is modeled as a chain of events (transactions)

78. Level 0 DFD for SafeHome [From SEPA 5/e]

79. Level 1 DFD for SafeHome [From SEPA 5/e]

80. Level 2 DFD for SafeHome Refines “monitor sensors” process [From SEPA 5/e]

81. Level 3 DFD for SafeHome Refines “monitor sensors” process, with flow boundaries [From SEPA 5/e]

82. First-Level Factoring Flow boundaries used to determine program structure and modules Additional factoring to introduce more detail [From SEPA 5/e]

83. Questions?