1 CMPT 275 Software Engineering Phase: Design High level design activity.

1

CMPT 275Software Engineering

Phase: Design

High level design activity

Janice Regan, 2008 2

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


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


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


System design activities

Analysis

System design

Object design

Functional requirements

Non Functional requirements

Analysis object model

Analysis dynamic model

Design goals

Subsystem decomposition


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.


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


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)


Map of design phaseDESIGN

HIGH LEVEL(system)DESIGN

Modularization

User Interface

Module Interfaces

Data PersistenceSubsystem

User Manual

architecture

LOW LEVEL(object) DESIGN

ClassesClass Interfaces

Interaction Diagrams

Implementation


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)


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)


Guidelines for User Interface DesignA 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


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


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


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)


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


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


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.



Outlook actually has found the Calendar folder, it just lacks permission to read it.


What is the problem?



This window appears when you attempt to disconnect the secure file transmission tool during an file transfer


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.


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


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


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.


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


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


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

1 CMPT 275 Software Engineering Phase: Design High level design activity.

Documents

Transcript of 1 CMPT 275 Software Engineering Phase: Design High level design activity.