Chapter : Design Engineering

Design Engineering
 It covers the set of principles, concepts, and practices that
lead to the development of a high quality system or product.
 Goal of design engineering is to produce a model or
representation that depict:
 Firmness – program should not have any bug that inhibits its functions.
 Commodity – suitable to its intended use.
 Delight - pleasurable to use
 The design model provides detail about software data
structures, architecture, interfaces, and components that are
necessary to implement the system.
Software Design
 Software design model consists of 4
designs:
 Data/class Design
 Architectural Design
 Interface Design
 Component Design
Translating Analysis  Design
 Data/class design - Created by transforming the analysis model
class-based elements into classes and data structures required to
implement the software
 Architectural design - defines the relationships among the major
structural elements of the software, it is derived from the class-based
elements and flow-oriented elements of the analysis model
 Interface design - describes how the software elements, hardware
elements, and end-users communicate with one another, it is derived
from the analysis model scenario-based elements, flow-oriented
elements, and behavioral elements
 Component-level design - created by transforming the structural
elements defined by the software architecture into a procedural
description of the software components using information obtained
from the analysis model class-based elements, flow-oriented
elements, and behavioral elements
Why design is so important?
 It is place where quality is fostered.
 It provides us with representation of software that can be
assessed for quality.
 Only way that can accurately translate a customer’s
requirements into a finished software product.
 It serves as foundation for all software engineering
activities.
 Without design difficult to assess:
 Risk
 Test
 Quality
Design Process and Design Quality

 S/w design is an iterative process through

which requirements are translated into a
“blueprint” for constructing the s/w.
 As design iteration occur, subsequent
refinement leads to design representation
at much lower levels of abstraction.
Goal of design process
 The design must implement all of the explicit
requirements contained in the analysis model, and it
must accommodate all of the implicit requirements
desired by the customer.
 The design must be a readable, understandable guide
for those who generate code and for those who test
and subsequently support the software.
 The design should provide a complete picture of the
software, addressing the data, functional, and
behavioral domains from an implementation
perspective.
Quality Guidelines
Characteristics of good design
 A design should exhibit an architecture that
 as been created using recognizable architectural styles or
patterns,
 is composed of components that exhibit good design
characteristics and
 can be implemented in an evolutionary fashion
 A design should be modular; that is, the software should be logically
partitioned into elements or subsystems
 A design should contain distinct representations of data,
architecture, interfaces, and components.
 A design should lead to data structures that are appropriate for the
classes to be implemented and are drawn from recognizable data
patterns.
 A design should lead to components that exhibit independent
functional characteristics
Quality Guidelines (contd.)
 A design should lead to interfaces that reduce the
complexity of connections between components and with
the external environment.
 A design should be derived using a repeatable method
that is driven by information obtained during software
requirements analysis.
 A design should be represented using a notation that
effectively communicates its meaning.
Design Principles
 S/W design is both a process and a
model.
 Design process - sequence of steps that
enable the designer to describe all aspects
of the software to be built.
 Design model - created for software
provides a variety of different views of the
computer software
Design concepts
 Design concepts provide the necessary
framework for “to get the thing on right way”.
 Abstraction
 Refinement
 Modularity
 Architecture
 Control Hierarchy
 Structural Partitioning
 Data Structure
 Software Procedure
 Information Hiding
Abstraction
 At the highest level of abstraction – a solution is stated in
broad terms
 At lower level of abstraction – a more detailed description of
the solution is provided.
 Two types of abstraction:
 Procedural abstraction: Sequence of instructions that have a
specific and limited function.
Ex. Open a door
open implies long sequence of activities (e.g. walk to the door,
grasp knob, turn knob and pull the door, etc).
 Data abstraction: collection of data that describes a data
object.
Ex. Open a door. – door is data object.
 Data abstraction for door would encompass a set of attributes
that describe the door. (E.g. door type, swing direction,
opening mechanism, etc.)
Refinement
 Refinement is actually a process of elaboration.
 begin with a statement of function (or description of
information) that is defined at a high level of abstraction.
 That is, the statement describes function or information
conceptually but provides no information about the
internal workings of the function or the internal structure
of the information.
 Refinement causes the designer to elaborate on the
original statement, providing more and more detail as
each successive refinement (elaboration) occurs.
 Abstraction and refinement are complementary
concepts. Abstraction enables a designer to specify
procedure and data and yet suppress low-level details.
 Refinement helps the designer to expose low-level
details as design progresses.
Modularity
 Architecture and design pattern embody modularity.
 Software is divided into separately named and
addressable components, sometimes called modules,
which are integrated to satisfy problem requirement.
 modularity is the single attribute of software that allows a
program to be intellectually manageable
 It leads to a “divide and conquer” strategy. – it is easier
to solve a complex problem when you break into a
manageable pieces.
 Refer fig. that state that effort (cost) to develop an
individual software module does decrease if total number
of modules increase.
 However as the no. of modules grows, the effort (cost)
associated with integrating the modules also grows.
 Undermodularity and overmodularity should be
avoided.
 We modularize a design so that development can
be more easily planned.
 Software increments can be defined and delivered.
 Changes can be more easily accommodated.
 Testing and debugging can be conducted more
efficiently and long-term maintained can be
conducted without serious side effects.
Architecture
 Software architecture suggest “ the overall structure of the
software and the ways in which that structure provides
conceptual integrity for a system.
 No. of different models can use to represent architecture.
 Structural Model- represent architecture as an organized
collection of components
 Framework model – Increase level of design abstraction
by identifying repeatable architectural design framework.
 Dynamic model – address behavior of the program
architecture and indicating how system or structure
configuration may change as a function.
 Process Model – focus on design of the business or
technical process that the system must accommodate.
 Functional models – used to represent the functional
hierarchy of a system.
Control Hierarchy
 Control hierarchy, represents the organization of
program components (modules) and implies a
hierarchy of control.
 Different notations are used to represent control
hierarchy for those architectural styles that are
amenable to this representation.
 The most common is the treelike diagram that
represents hierarchical control for call and return
architectures.
Structural Partitioning
Structure partitioning
 Two types of Structure partitioning:
 Horizontal Partitioning
 Vertical Partitioning
 Horizontal partitioning defines separate branches of the
modular hierarchy for each major program function.
 Control modules, represented in a darker shade are used
to coordinate communication & execution between its
functions.
 Horizontal partitioning defines three partitions—input,
data transformation (often called processing) and output.
 Benefits of Horizontal partitioning:
 software that is easier to test
 software that is easier to maintain
 propagation of fewer side effects
 software that is easier to extend
 On the negative side (Drawback), horizontal
partitioning often causes more data to be
passed across module interfaces and can
complicate the overall control of program flow.
 Vertical partitioning, often called factoring,
suggests that control (decision making) and
work should be distributed top-down in the
program structure.
 Top-level modules should perform control
functions and do little actual processing work.
 Modules that reside low in the structure should
be the workers, performing all input,
computation, and output tasks.
 A change in a control module (high in the
structure) will have a higher probability of
propagating side effects to modules that are
subordinate to it.
 A change to a worker module, given its low level in
the structure, is less likely to cause the
propagation of side effects.
 For this reason vertically partitioned structures are
less likely to be susceptible to side effects when
changes are made and will therefore be more
maintainable.
Data Structure
 Data structure is a representation of the logical relationship among
individual elements of data
 A scalar item is the simplest of all data structures. It represents a
single element of information that may be addressed by an identifier.
 When scalar items are organized as a list or contiguous group, a
sequential vector is formed.
 When the sequential vector is extended to two, three, and ultimately,
an arbitrary number of dimensions, an n-dimensional space is
created. Most common n-dimensional space is the two-dimensional
matrix
 A linked list is a data structure that organizes contiguous scalar
items, vectors, or spaces in a manner (called nodes) that enables
them to be processed as a list.
 A hierarchical data structure is implemented using multilinked lists
that contain scalar items, vectors, and possibly, n-dimensional
spaces.
Software Procedure
 Software procedure focuses on the
processing details of each module
individually.
 Procedure must provide a precise
specification of processing, including
sequence of events, exact decision points,
repetitive operations, and even data
organization and structure.
Information Hiding
 The principle of information hiding suggests that
modules be "characterized by design decisions that
(each) hides from all others modules.“
 In other words, modules should be specified and
designed so that information (algorithm and data)
contained within a module is inaccessible to other
modules that have no need for such information.
 The intent of information hiding is to hide the details of
data structure and procedural processing behind a
module interface.
 It gives benefits when modifications are required during
testing and maintenance because data and procedure
are hiding from other parts of software, unintentional
errors introduced during modification are less.
EFFECTIVE MODULAR DESIGN

 Effective modular design consist of three

things:
 Functional Independence
 Cohesion
 Coupling
Functional Independence
 Functional independence is achieved by developing
modules with "single-minded“ function and an "aversion"
to excessive interaction with other modules.
 In other words - each module addresses a specific sub-
function of requirements and has a simple interface
when viewed from other parts of the program structure.
 Independence is important –
 Easier to develop
 Easier to Test and maintain
 Error propagation is reduced
 Reusable module.
Functional Independence
 To summarize, functional independence is a key
to good design, and design is the key to
software quality.
 To measure independence, have two qualitative
criteria: cohesion and coupling
 Cohesion is a measure of the relative functional
strength of a module.
 Coupling is a measure of the relative
interdependence among modules.
Cohesion
 Cohesion is a natural extension of the information hiding
concept
 A cohesive module performs a single task within a
software procedure, requiring little interaction with
procedures being performed in other parts of a program
 Simply state, a cohesive module should (ideally) do just
one thing.
 We always strive for high cohesion, although the mid-
range of the spectrum is often acceptable.
 Low-end cohesiveness is much "worse" than middle
range, which is nearly as "good" as high-end cohesion.
 So. designer should avoid low levels of cohesion when
modules are designed.
Cohesion
 When processing elements of a module are
related and must be executed in a specific order,
procedural cohesion exists.
 When all processing elements concentrate on
one area of a data structure, communicational
cohesion is present.
 High cohesion is characterized by a module that
performs one distinct procedural task.
Types of cohesion
 A module that performs tasks that are related
logically is logically cohesive.
 When a module contains tasks that are related
by the fact that all must be executed with the
same span of time, the module exhibits temporal
cohesion.
 At the low-end of the spectrum, a module that
performs a set of tasks that relate to each other
loosely, called coincidentally cohesive.
Coupling
 Coupling depends on the interface complexity between
modules, the point at which entry or reference is made to
a module, and what data pass across the interface
 In software design, we strive for lowest possible
coupling. Simple connectivity among modules results in
software that is easier to understand and less prone to a
"ripple effect" caused when errors occur at one location
and propagate through a system.
 It occur because of design decisions made when
structure was developed.
Coupling
Coupling
 Coupling is characterized by passage of control between
modules.
 “Control flag” (a variable that controls decisions in a
subordinate or superordinate module) is passed between
modules d and e (called control coupling).
 Relatively high levels of coupling occur when modules
are communicate with external to software.
 External coupling is essential, but should be limited to a
small number of modules with a structure.
 High coupling also occurs when a number of modules
reference a global data area.
 Common coupling, no. of modules access a data item in
a global data area
 So it does not mean “use of global data is bad”. It does
mean that a software designer must be take care of this
thing.
Evolution of Software Design
 Early design work concentrated on criteria for the
development of modular programs and methods for
refining software structures in a top-down manner.
 Later work proposed methods for the translation of data
flow or data structure into a design definition.
 Today, the emphasis in software design has been on
software architecture and the design patterns that can be
used to implement software architectures.
Characteristics are common to all
design methods
 A mechanism for the translation of analysis
model into a design representation,
 A notation for representing functional
components and their interfaces.
 Heuristics for refinement and partitioning
 Guidelines for quality assessment.
Design quality attributes
 Acronym FURPS –
 Functionality
 Usability
 Reliability
 Performance
 Supportability
 Functionality – is assessed by evaluating the feature set
and capabilities of the program.
 Functions that are delivered and security of the
overall system.
 Usability – assessed by considering human factors,
consistency & documentation.
 Reliability – evaluated by
 measuring the frequency and severity of failure.
 Accuracy of output results.
 Ability to recover from failure and predictability of the
program.
 Performance - measured by processing speed,
response time, resource consumption, efficiency.
 Supportability – combines the ability to extend the
program (extensibility), adaptability and serviceability.
Software Architecture
 “The software architecture of a program or computing system is
the structure or structures of the system, which comprise the
software components, the externally visible properties of those
components, and the relationships among them.”
 It is not operational software but it is representation that enables
software engineer to
 Analyze the effectiveness of design in meeting its stated
requirement.
 consider architectural alternatives at a stage when making
design changes is still relatively easy,
 reduce the risks associated with the construction of the
software.
Importance of Software Architecture

 Representations of software architecture are an

enabler for communication between all parties
(stakeholders) interested in the development
 Architecture highlights early design decisions
that will have a profound impact on all software
engineering work that follows.
 Architecture “constitutes a relatively small,
intellectually graspable model of how the system
is structured and how its components work
together”
Data Design
 The structure of data has always been an
important part of software design.
 Component level – the design of data
structures and the associated algorithms
required to manipulate them is essential to
the creation of high-quality applications.
 Application level – the translation of a data
model into a database design
Data Design at architectural design
 Today, business (i.e. irrespective of its size large or
small) have dozens of database serving many
applications encompassing hundreds of gigabytes of
data.
 Challenge is to extract useful information from its data
environment, particularly when the information desired is
cross-functional.
 To solve this challenge, developed technique called
 Data Mining (also called knowledge discovery in
databases (KDD)),
 Data Warehouse
 Data mining that navigate through existing databases in
an attempt to extract appropriate business-level
information
 However, the existence of multiple databases, their
different structures, the degree of detail contained with
the databases, and many other factors make data mining
difficult within an existing database environment.
 A data warehouse is a separate data environment that is
not directly integrated with day-to-day applications but
encompasses all data used by a business
 A data warehouse is a large, independent database that
encompasses some, but not all, of the data that are
stored in databases that serve the set of applications
required by a business.
Data design at the component level
 Component level focuses on the representation of data
structures that are directly accessed by one or more
software components.
Principles are applicable to data design
1. The systematic analysis principles applied to function
and behavior should also be applied to data.
2. All data structures and the operations to be performed
on each should be identified.
3. A data dictionary should be established and used to
define both data and program design (operations)
4. Low-level data design decisions should be deferred
until late in the design process.
5. The representation of data structure should be known
only to those modules that must make direct use of the
data contained within the structure.
6. A library of useful data structures and the operations
that may be applied to them should be developed.
7. A software design and programming language should
support the specification and realization of abstract
data types.
Architectural Style
 Style describes a system category that encompasses
1. A set of components (e.g., a database, computational
modules) that perform a function required by a system;
2. a set of connectors that enable “communication, co-
ordinations and cooperation” among components;
3. constraints that define how components can be integrated to
form the system
4. semantic models that enable a designer to understand the
overall properties of a system
It can be represent by
 Data-centered architecture
 Data flow architecture
 Call and return architecture
 Object oriented architecture
 Layered architecture.
Data-centered architecture
Data-centered architecture
 A data store (e.g., a file or database) resides at the center of
this architecture and is accessed frequently by other
components that update, add, delete, or otherwise modify
data within the store.
 Client software accesses a central repository which is in
passive state (in some cases).
 client software accesses the data independent of any
changes to the data or the actions of other client software.
 So, in this case transform the repository into a “Blackboard”.
 A blackboard sends notification to subscribers when data of
interest changes, and is thus active.
 Data-centered architectures promote integrability.
 Existing components can be changed and new client
components can be added to the architecture without concern
about other clients.
 Data can be passed among clients using the blackboard
mechanism. So Client components independently execute
processes
Data Flow architecture

Pipes and filters

Batch Sequential
Data Flow architecture
 This architecture is applied when input data are to be
transformed through a series of computational or
manipulative components into output data.
 A pipe and filter pattern (Fig .1) has a set of components,
called filters, connected by pipes that transmit data from
one component to the next.
 Each filter works independently (i.e. upstream,
downstream) and is designed to expect data input of a
certain form, and produces data output (to the next filter)
of a specified form.
 the filter does not require knowledge of the working of its
neighboring filters.
 If the data flow degenerates into a single line of
transforms, it is termed batch sequential.
Call and return architecture
Call and return architecture
 Architecture style enables a software designer
(system architect) to achieve a program structure
that is relatively easy to modify and scale.
 Two sub-styles exist within this category:
1. Main/sub program architecture:
 Program structure decomposes function into a
control hierarchy where a “main” program invokes
a number of program components, which in turn
may invoke still other components.
2. Remote procedure Call architecture:
 The components of a main program/subprogram
architecture are distributed across multiple
computers on a network
Object-oriented architecture
Object-oriented architecture
 The object-oriented paradigm, like the abstract data type
paradigm from which it evolved, emphasizes the
bundling of data and methods to manipulate and access
that data (Public Interface).
 Components of a system summarize data and the
operations that must be applied to manipulate the data.
 Communication and coordination between components
is accomplished via message passing.
Layered Architecture
 A number of different layers are defined,
each accomplishing operations that
progressively become closer to the
machine instruction set.
 At the outer layer, components examine
user interface operations.
 At the inner layer, components examine
operating system interfacing.
 Intermediate layers provide utility services
and application software functions.
User Interface Design
The UI design process
 UI design is an iterative process involving
close liaisons between users and
designers.
 The 3 core activities in this process are:
 User analysis. Understand what the users
will do with the system;
 System prototyping. Develop a series of
prototypes for experiment;
 Interface evaluation. Experiment with these
prototypes with users.
The design process
Interface Design Models
Four different models occur in HCI design:
1. The design model expresses the software design.

2. The user model describes the profile of the end users. (i.e.,
novices vs. experts, cultural background, etc.)

3. The user’s model is the end users’ perception of the system.

4. The system image is the external manifestation of the system (look

and feel + documentation etc.)
Roadmap
 Interface design models
 Design principles
 GUI characteristics
 User Guidance
 Usability Testing
 Examples
 ESE — User Interface Design

User Interface Design

Principles
Principle Description
Use terms and concepts familiar to the user.
User familiarity

Comparable operations should be activated in the

Consistency same way. Commands and menus should have the
same format, etc.
If a command operates in a known way, the user
Minimal surprise should be able to predict the operation of comparable
commands.
Provide the user with visual and auditory feedback,
Feedback maintaining two-way communication.
Principle Description
Reduce the amount of information that must be
Memory load remembered between actions. Minimize the memory
load.
Seek efficiency in dialogue, motion and thought.
Efficiency Minimize keystrokes and mouse movements.

Allow users to recover from their errors. Include undo

Recoverability facilities, confirmation of destructive actions, 'soft'
deletes, etc.
Incorporate some form of context-sensitive user
User guidance
guidance and assistance.
Roadmap
 Interface design models
 Design principles
 GUI characteristics
 User Guidance
 Usability Testing
 Examples
 ESE — User Interface Design

GUI Characteristics
Characteristic Description
Multiple windows allow different information to be
Windows
displayed simultaneously on the user’s screen.
Usually icons represent files (including folders and
Icons applications), but they may also stand for processes
(e.g., printer drivers).
Menus bundle and organize commands (eliminating the
Menus
need for a command language).
A pointing device such as a mouse is used for
Pointing command choices from a menu or indicating items of
interest in a window.
Graphical elements can be commands on the same
Graphics
display.
GUIs
Advantages
 They are easy to learn and use.
 Users without experience can learn to use the system quickly.
 The user may switch attention between tasks and applications.
 Fast, full-screen interaction is possible with immediate access to the
entire screen

Problems
 A GUI is not automatically a good interface
 Many software systems are never used due to poor UI design
 A poorly designed UI can cause a user to make catastrophic errors
Menu Systems
Advantages
 Users don’t need to remember
command names
 Typing effort is minimal
 User errors are trapped by the
interface
 Context-dependent help can be
provided (based on the current
menu selection)

Problems
> Actions involving logical conjunction (and) or disjunction
(or) are awkward to represent
> If there are many choices, some menu structuring facility
must be used
> Experienced users find menus slower than command
language
Menu Structuring
Scrolling menus
 The menu can be scrolled to reveal additional choices
 Not practical if there is a very large number of choices

Hierarchical menus
 Selecting a menu item causes the menu to be replaced by a sub-
menu

Walking menus
 A menu selection causes another menu to be revealed

Associated control panels

 When a menu item is selected, a control panel pops-up with further
options
Command Interfaces
With a command language, the user types commands to give
instructions to the system

 May be implemented using cheap terminals

 Easy to process using compiler techniques
 Commands of arbitrary complexity can be created by command
combination
 Concise interfaces requiring minimal typing can be created
Command Interfaces
Advantages
 Allow experienced users to interact quickly with the system
 Commands can be scripted (!)

Problems
 Users have to learn and remember a command language
 Not suitable for occasional or inexperienced users
 An error detection and recovery system is required
 Typing ability is required (!)
Analogue vs. Digital
Presentation
Digital presentation
 Compact — takes up little screen space
 Precise values can be communicated

Analogue presentation
 Easier to get an 'at a glance' impression of a value
 Possible to show relative values
 Easier to see exceptional data values

Pressure Temperature
0 100 200 300 400 0 25 50 75 100
Colour Use Guidelines
Colour can help the user understand complex information
structures.
 Don’t use (only) colour to communicate meaning!
 Open to misinterpretation (colour-blindness, cultural differences ...)
 Design for monochrome then add colour
 Use colour coding to support user tasks
 highlight exceptional events
 allow users to control colour coding
 Use colour change to show status change
 Don't use too many colours
 Avoid colour pairings which clash
which clash
 Use colour coding consistently
Roadmap
 Interface design models
 Design principles
 GUI characteristics
 User Guidance
 Usability Testing
 Examples
User Guidance
The user guidance system is integrated with
the user interface to help users when they
need information about the system or
when they make some kind of error.

Includes
 System messages, including error
messages
 Documentation provided for users
 On-line help
Help system use
 Multiple entry points should be provided
 the user should be able to get help from
different places
 The help system should indicate where the
user is positioned
 Navigation and traversal facilities must be
provided
Error Message Guidelines
 Speak the user’s language
 Give constructive advice for recovering from the error
 Indicate negative consequences of the error (e.g., possibly
corrupted files)
 Give an audible or visual cue
 Don’t make the user feel guilty!
Roadmap
 Interface design models
 Design principles
 GUI characteristics
 User Guidance
 Usability Testing
 Examples
Usability Testing
 Observe a group of test subjects
performing a pre-defined scenario

 Which test subjects?

 How many test subjects?
 Which scenarios?
 What to observe?
User interface evaluation
 Some evaluation of a user interface design
should be carried out to assess its
usability.
 Full scale evaluation is very expensive and
impractical for most systems.
 Ideally, an interface should be evaluated
against a usability specification. However,
it is rare for such specifications to be
produced.
Simple evaluation techniques
 Questionnaires for user feedback.
 Video recording of system use and
subsequent tape evaluation.
 Instrumentation of code to collect
information about facility use and user
errors.
 The provision of code in the software to
collect on-line user feedback.
Hints
 Establish concrete goals — what do you want to
achieve?
 What criteria will you use to establish “success”?
 What data will you collect?
 Choose representative test tasks.
 Carry out a pilot test first.
 Test users should truly represent the intended users.
 Use experienced experimenters. (Get trained!)
 Make the test subjects feel comfortable.
 Don’t bias the results.
 ESE — User Interface Design

Usability Attributes
Attribute Description
How long does it take a new user to
Learnability
become productive with the system?
Speed of How well does the system response
operation match the user’s work practice?
How tolerant is the system of user
Robustness
error?
How good is the system at recovering
Recoverability
from user errors?
How closely is the system tied to a
Adaptability
single model of work?
Thank You