CMPT 275
Software Engineering
Phase:
Design
High level design activity
1
Objectives of Design
 The design phase takes the results of the
requirements analysis phase and evolves these
results further
 The results of the design phase feeds directly
into the implementation phase
 Requirements analysis → WHAT the system
must do
 Next Goal: determine HOW the software system
is to accomplish what it must do
Janice Regan, 2008
2
Basis of System Design
 The design phase uses the analysis model
 Non-functional requirements / constraints
 Use case model: (from users point of view)

Use cases and use case diagrams

state diagrams
 Object model:

Context diagram, class diagrams
Janice Regan, 2008
3
Objectives of System Design
 The design phase produces a system model

That is based on specific design goals for the designers

That defines architecture and Subsystem design


Identifying subsystems/modules (manageable parts)

Identifying architecture (hardware/software)

Data management / mapping

Access control, flow control (sequencing operations)
That describes boundary use cases:

Initialization, termination, configuration, exception
handling
Janice Regan, 2008
4
System design activities
Functional requirements
Analysis
Non Functional requirements
Analysis dynamic model
Analysis object model
System design
Design goals
Subsystem decomposition
Object design
Janice Regan, 2008
5
Objectives of system design
 Transforms analysis model (from
requirements analysis) into a system
design model
 Identify, model system architecture
 Develop an efficient system decomposition
 Identify boundary use cases describing
configuration, startup, shutdown, exceptional
conditions.
Janice Regan, 2008
6
Design goals, System decomposition
 Identify design goals (choose aspects of the
system to be optimized) Design goals are often
derived from non-functional requirements.

Guide designers in assessing trade offs
 Develop and refine a subsystem decomposition
that satisfies the maximum number of design
goals and or the most critical design goals
 Refine the decomposition to better satisfy the
design goals
Janice Regan, 2008
7
Design goals
 When assessing design goals consider

Selection of existing components (off the shelf modules
or components )

Hardware / software mapping,

Are there multiple nodes or systems

What is each node responsible for

selecting solutions for managing persistent data

Access control policies

Control flow on a solution wide basis

Boundary conditions (startup, error, shutdown)
Janice Regan, 2008
8
Map of design phase
DESIGN
LOW LEVEL
(object) DESIGN
HIGH LEVEL
(system)DESIGN
Data
Persistence
Subsystem
Module Interfaces
Modularization
Classes
Class Interfaces
Interaction Diagrams
architecture
User Interface
Janice Regan, 2008
User Manual
Implementation
9
Why a User Interface Module?
 Making the GUI a module
 Easy replacement/expansion of
interface
 Can easily replace without changing
functionality of the system ( What if
you wanted a command line interface,
or a modified version of the GUI)
Janice Regan, 2008
10
User Interfaces
 Facilitate two-way communication with
user
 It is a good idea to keep the user
interface and the functionality of software
system separate
 Functionality of software system
determines what information is to be
communicated (content) and user
interface determines how that information
is to be communicated (form)
Janice Regan, 2008
11
Guidelines for User Interface Design
A user interface should:
 Be simple
 Speak the user’s language
 Maximize user’s prior knowledge &
minimize memorization
 Be intuitive
 Be consistent
 Provide feedback
 Give control to the user
 Prevent errors
 Accommodate multiple skill levels
Janice Regan, 2008
12
Guidelines for UI Design
 Be simple
 Reduce clutter, make UI transparent
 Minimize number of mouse clicks / keyboard
characters, levels of navigation
 Maximize user’s prior knowledge &
minimize memorization
 Use interfaces similar to those a user will be
familiar with from other applications on his/her
platform
Janice Regan, 2008
13
Guidelines for UI Design
 Speak the user’s language
 Use terms from the users application domain
where appropriate
 Be intuitive
 Combine logically related options
 Use meaningful labels, names, icons
Janice Regan, 2008
14
Guidelines for UI Design
 Be consistent
 Don’t make a labeled button do different things
in different places
 Use the same approaches throughout
 Accommodate multiple skill levels
 Have multiple ways to complete a task (e.g.
mouse click or keyboard shortcut)
Janice Regan, 2008
15
Guidelines for UI Design
 Provide feedback
 Clear error messages. Include instructions on
how to recover from the problem
 Explain what acceptable input is and if
necessary why it is acceptable
 Indicate when the system is busy, the user
should know if the system is working or has
crashed (stopped)
 Context sensitive help
Janice Regan, 2008
16
Guidelines for UI Design
 Give control to the user
 Allow the user to undo, redo, confirm, cancel,
exit … as appropriate
 Warn the user if an operation cannot be
undone
 Prevent errors
 Anticipate and disallow user actions that could
lead to errors
Janice Regan, 2008
17
What’s the Problem?
Janice Regan, 2008
18
What’s the Problem?
Janice Regan, 2008
19
What’s the Problem?
Janice Regan, 2008
20
What’s the Problem?
Janice Regan, 2008
21
What’s the Problem?
The company claims this was just a joke and never
meant to be seen by users. The programmer who did it
no longer works for the company, and many thousands
of letters of apology were sent to customers.
Janice Regan, 2008
22
What’s the Problem?
Janice Regan, 2008
23
What’s the Problem?
Outlook actually has found the Calendar
folder, it just lacks permission to read it.
Janice Regan, 2008
24
What’s the Problem?
Janice Regan, 2008
25
What’s the Problem?
Janice Regan, 2008
26
What’s the Problem?
Janice Regan, 2008
27
What’s the Problem?
Janice Regan, 2008
28
What’s the Problem?
Janice Regan, 2008
29
What is the problem?
Janice Regan, 2008
30
What is the problem?
Janice Regan, 2008
31
What is the problem?
This window appears when you attempt to disconnect the
secure file transmission tool during an file transfer
Janice Regan, 2008
32
What’s the Problem?
Janice Regan, 2008
33
What’s the Problem?
Janice Regan, 2008
34
What’s the Problem?
Janice Regan, 2008
35
User Interface Design
 The User interface is how your user interacts
with your program
 Specifying which actions it should perform
 Evaluating, viewing, and saving results
 It should not be tied to how your program
determines the results
 When designing your interface think in terms of
how the user will see the system, make the
system easy for the user (not the designer) to
use and understand.
Janice Regan, 2008
36
User-Centered Design
 1. Analyse: who are the users, how are tasks
currently performed, steps presently taken while
doing task, how user knows if task was
successful …
 2. Design: draft your user interfaces using…
 UI descriptions from your SRS
 Guidelines for User Interface Design
Janice Regan, 2008
37
User-Centered Design
 3. Evaluate: Run your user interfaces by the
users
 Do users know what to do at each step
 Do users know how to accomplish each step
 4. Iterate: Goto step 1.
 Our goal -> User satisfaction,
 To the user the interface is the system
Janice Regan, 2008
38
Users view of a system
 The users view of a system is the UI. The user
does not know or need to know or care how the
internals of the system functions.
 The users understanding of the system is based
on their interaction with the UI and their
knowledge of the application area
 Requirements analysis defines what the system
does and collects information about how those
tasks are normally done in the application area.
 Incorporate how it is done in the design of your
UI.
Janice Regan, 2008
39
UI Descriptions
 Describe the interaction between software
system and actors
 Start with UI descriptions and use cases
in requirements (remember these should
contain only enough detail to be able to
explain the behavior of the system)
 Refine use cases, add the ‘how’ to the UI
descriptions
Janice Regan, 2008
40
UI Descriptions
 Guideline: 1 interface per actor
 Each actor has their own initial screen
 That screen may lead to a series of
screens performing all required tasks
 Later screen in the sequence may be
common to multiple actors
Janice Regan, 2008
41
User Interface Design: Project
 For requirements analysis UI screens were
functional
 focused on purpose of screen, not its layout
 In Design, focus on screen layout.
 Many functions may be incorporated into one
window. Multiple screens from requirements
may be merged for simplicity
 Consider various types of widgets, select the
best for each purpose (simplest?)
Janice Regan, 2008
42