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

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

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

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

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

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

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

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

Interface Design Process [From SEPA 5/e]

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

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

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!

Design Evaluation [From SEPA 5/e]

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

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

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, …

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)

Flowchart Constructs [From SEPA 5/e]

Nesting Constructs [From SEPA 5/e]

Box Diagram Constructs [From SEPA 5/e]

Decision Tables [From SEPA 5/e]

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 in the Pressman text l Less visual, but more detailed than flowcharts (e.g., type declarations)

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

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

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

Questions?

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

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

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

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

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

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

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

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

Interface Design Process [From SEPA 5/e]

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

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

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!

Design Evaluation [From SEPA 5/e]

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

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

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, …

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)

Flowchart Constructs [From SEPA 5/e]

Nesting Constructs [From SEPA 5/e]

Box Diagram Constructs [From SEPA 5/e]

Decision Tables [From SEPA 5/e]

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 in the Pressman text l Less visual, but more detailed than flowcharts (e.g., type declarations)

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

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

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

Questions?

Software Engineering for Information Technology Lecture 12: System Design

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

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

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

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

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

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

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

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

Modularity and Software Cost [From SEPA 5/e]

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

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

Architectural Terminology [From SEPA 5/e]

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

[From SEPA 5/e] Partitioning Examples

Procedural Layering [From SEPA 5/e]

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

Types of Coupling [From SEPA 5/e]

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!)

Program Structures [From SEPA 5/e]

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

Data-Centered Architecture [From SEPA 5/e]

Data Flow Architectures [From SEPA 5/e]

Layered Architecture [From SEPA 5/e]

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)

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

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

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

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

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

Questions?