08/03/2021

Software Design

Software Design -Overview

• Design is a meaningful engineering representation of
something that is to be built.

• Software design focuses on transforming the requirements

into an executable version of the software system.

• Software design concerns on following major areas.

1. Software architecture (structure of the software)
2. Interfaces
3. Components
4. Data structures

• The final design does not come immediately because it is

developed through iterations. The design process involves
adding formality & detail as the design is developed, with
constant backtracking to correct earlier designs. 2

1
 08/03/2021

Need for a software design

• When building houses, blueprints are essential. Otherwise
everything is messed. Doors & windows in wrong places, floor area is
not properly utilized etc. Since computer software is more complex
than houses, the blueprint-design is essential.

• A good design is the key for a successful software system.

• A good design allows easy maintenance of a system.

• A good design allows to achieve non-functional requirements such as

performance, reliability, reusability etc.

• A good design facilitates the development & management of a

software project.
3

Design Process
• The requirements are transformed into four major
areas of design details; System architecture,
interface representation, component level details &
data structures.

• Work product of the design process is a design

specification. This design specification is composed
of design models which describe above four areas.

• Therefore design process involves developing

several models of the system at different levels of
abstraction.
4

2
 08/03/2021

Illustration of a generic design process

(Design activities & design products are indicated)

Requirements
specification

Design Activities

Architectural Abstract Interface Component Data structure Algorithm

design specification design design design design

System Software Interface Component Data structure Algorithm

architecture specification specification specification specification specification

Design Products
This diagram suggests that stages of the design process are sequential. But in fact,
design process activities are mixed. Feed back from one stage to another and design
5
rework is inevitable in design process.

Design products of the generic design process

• In each design activity, the output is a specification

for the next stage.
• This specification may be an abstract specification
that is produced to clarify the requirements or it may
be a specification of how part of the system is to be
realized.
• As the design process continues, these specifications
become more detailed.

3
 08/03/2021

Design activities of generic design process

• Architectural design
• The sub-systems making up the system and their relationships are identified &
documented.
• Abstract specification
• For each sub-system, an abstract specification of it’s services & constraints under which
it must operate is produced.
• Interface design
• For each sub-system, it’s interface used to communicate with other sub-systems is
designed & documented. This interface specification must be unambiguous as it allows
the sub-system to be used without knowledge of the sub-system operation.
(Encapsulation)
• Component design
• Services are allocated to different components and the interfaces of these components
are designed.
• Data structure design
• The data structures used in the system implementation are designed in detail and
specified.
• Algorithm design
• The algorithms used to provide services are designed in detail and specified.

Architectural design
• A system is always divided into sub-systems that
provide some related set of services.

• The initial design process of identifying these sub-

systems and establishing a framework for sub-system
control & communication is called ‘architectural
design’.

• The output of this design process is a ‘description of

the software architecture’.
8

4
 08/03/2021

Sub-systems and Modules

• Sub-system
• A sub-system is a system, in it’s own right whose operation
does not depend on the services provided by other
systems. Sub-systems are composed of modules and have
defined interfaces which are used for communication with
other sub-systems.

• Module
• A module is normally a system component, that provides
one or more services to other modules. It makes use of
services provided by other modules. It is not normally
considered to be an independent system. Modules are
usually composed of a number of other simpler system
components.
9

Architectural design document

• The output of the architectural design process is an
architectural design document.

• This consists of a number of graphical system models

and associated descriptive text. It should describe
how the system is structured into sub-systems and
how each sub-system is structured into modules.

10

5
 08/03/2021

Architectural graphical models

• Architectural models which are in the architectural
design document may include followings.
1. A static structural model that shows the sub-systems or
components that are to be developed as separate units.
2. A dynamic process model that shows how the system is
organized into processes at run time. This may be
different from the static model.
3. An interface model that defines the services offered by
each sub-system through their interfaces.
4. Relationship models that show relationships such as data
flow between the sub-systems.

11

Architectural design
• There are different structural models, control models &
decomposition models, but the architecture of large systems
do not conform to a single structural/ control or decomposition
model.
• Different parts of the system may be designed using different
architectural models. Usually a system architecture is created
by combining different architectural models.
• Designers must find the most relevant model & modify it
according to the problem requirements.
• The system architecture affects the non-functional
requirements such as performance, robustness, distributability,
maintainability etc. Therefore the particular structure chosen
for an application depends on non-functional system
requirements.
12

6
 08/03/2021

Architecture & system characteristics

• Performance
• If this is a critical requirement, architecture should be designed to restrict
critical operations within a small number of sub-systems with little
communication between these sub-systems.
• Security
• If this is a critical requirement, a layered structure for the architecture should
be used with the most critical assets protected in the innermost layers & high
level of security validation is applied to these layers.
• Safety
• If this is a critical requirement, safety-related operations should be located in a
single sub-system or in a small number of sub-systems. This reduces the
problems of safety validation.
• Availability
• If this is a critical requirement, extra components should be included so that it
is possible to update & replace the components without stopping the system.
• Maintainability
• If this is a critical requirement, self-contained components that may be readily
changed should be included and shared data structures should be avoided.
If there are conflicts between these non-functional requirements, some compromise solution is needed.
Sometimes this can be achieved by using different architectural styles for different parts of the system.
13

Principal dependability properties

• Availability
• The probability that the system will be up and running and
able to deliver useful services to users.
• Reliability
• The probability that the system will correctly deliver
services as expected by users.
• Safety
• A judgment of how likely it is that the system will cause
damage to people or its environment.

14

7
 08/03/2021

Principal dependability properties

• Security
• A judgment of how likely it is that the system can resist accidental or
deliberate intrusions.
• Resilience
• A judgment of how well a system can maintain the continuity of its critical
services in the presence of disruptive events such as equipment failure and
cyberattacks.

15

The principal dependability properties

16

8
 08/03/2021

Architectural design-System structuring

(Refer slide no.11)
• First phase of architectural design activity is system
structuring, which means dividing a system into a set
of interacting sub-systems.
• A block diagram where each box represents a sub-
system & arrows to show the direction of passing the
data/ control. Boxes within boxes indicate that the
sub-system has itself been decomposed into sub-
systems.
• An architectural block diagram presents an overview
of the system structure, which is understandable to
the various engineers who may be involved in the
system development process.
17

Example: Block diagram of a

Pick out
objects on a
packing robot control system
conveyor

Vision
system

Object Arm Gripper

identification controller controller
system

Identifies the
type of Moves the
Packaging objects
object
selection
system

Selects the Packing Conveyor

relevant system controller
packaging 18

9
 08/03/2021

Comments on block diagram

• These box & line diagrams are effective for
communication with system stakeholders.
• Stakeholders can understand such an abstract view of
the system. It identifies the key sub-systems that are
independently developed.
• More specific models of the structure may be
developed to show how sub-systems share data, how
they are distributed and how they interface with each
other.

19

Repository model
• Sub-systems making up a system must exchange information so that they can
work together effectively. There are two fundamental ways to do this,
1. All shared data is held in a central database that can be accessed by all sub-systems. A
system model based on a shared database is called a ‘Repository model’.
2. Each sub-system maintains it’s own database. Data is interchanged with other sub-systems
by passing messages to them.
• The majority of systems which use large amounts of data are organized around
a shared database. This model is suited for applications where data is
generated by one sub-system and used by another. Eg: MIS, Command &
control systems, CASE tool sets

20

10
 08/03/2021

Repository model
(Eg: A CASE tool set)

Design
editor
Code
Design generator
translator

Project
repository

Design Program
analyzer editor
Report
generator

21

Repository model- Comments

Advantages Disadvantages

An efficient way to share large amounts of data. No Sub-systems must agree on the repository data
need to transmit data explicitly from one sub-system model. This is a compromise between the specific
to another. needs of each tool. It may be difficult to integrate
new sub-systems if their data models do not fit the
agreed schema.
Sub-systems which produce data need not be Maintenance may be difficult as a large volume of
concerned with how that data is used by other sub- information is generated according to an agreed
systems. data model. Translating this to a new model may
be expensive or difficult.
Backup, security, access control and recovery from Different sub-systems may have different
errors are centralized. They are the responsibility of requirements for security, recovery & backup
the repository manager. Tools can focus on their policies. The repository model forces the same
principal function rather than be concerned with these policy on all sub-systems.
issues.
It is straightforward to integrate new tools, given that Although it is possible to distribute a logically
they are compatible with the agreed data model. centralized repository, there may be problems with
data redundancy & inconsistency.

22

11
 08/03/2021

Client-server model
• This is a distributed system model which shows how data &
processing are distributed across a range of processors. The
major components of this model are
1. A set of stand-alone servers which offer services to other sub-systems.
Eg: print servers which offer printing services, file servers which offer file
management services, compile servers which offer program language
compiling services
2. A set of clients that call on the services offered by servers. These are
sub-systems in their own right. There may be several instances of a
client program executing concurrently.
3. A network which allows the clients to access these services. (when both
the client & servers run on a single machine, this is not needed)
• Clients should know the names of available servers &
services that they provide. But, servers need not to know
either the identity of clients or how many clients there are.
Clients access the services provided by a server through
remote procedure calls.

23

Client-server model
(Eg: A multi-user hypertext system for a film & photograph library)

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network

Catalogue Video Picture Hypertext

server server server server

Film clip Digitized Hypertext

Catalogue
files photographs Web

24

12
 08/03/2021

Client-server model - Comments

• The client-server approach can be used to implement
a repository based system where the repository is
provided by the system server.
• Sub-systems accessing the repository are clients. But
each sub-system manages it’s own data.
• Servers & clients exchange data for processing. This
can result in performance problems when large
amounts of data are exchanged, but due to faster
networks this problem becomes less significant.

25

Architectural design-Control models

(Refer slide no.11)
• Above system structuring models discussed how a system is divided
into sub-systems. To work as a system, sub-systems must be
controlled so that their services are delivered to the right place at the
right time.
• Structured models do not include control information. The architect
should organize the sub-systems according to some control model.
• Control models at the architectural level are concerned with the
control flow between sub-systems.

26

13
 08/03/2021

Architectural design-Control models

• Two general approaches to control can be
identified.
1. Centralized control
• One sub-system has overall responsibility for control and starts
& stops other sub-systems. It may also transfer control to
another sub-system but will expect to have this control
responsibility returned to it.
2. Event-based control
• Rather than control information being embedded in a sub-
system, each sub-system can respond to externally generated
events. These events might come from other sub-systems or
from the environment of the system.
• Control models enhance structural models. All the
previously discussed structural models may be
realized using centralized or event-based control.
27

Centralized control
• In this model, one sub-system is designated as the
system controller and has responsibility for
managing the execution of other sub-systems.
• This model falls into two classes depending on
whether the controlled sub-system execute
sequentially or in parallel.
1. The call-return model
• This is the top down subroutine model where control starts at
the top of a subroutine hierarchy and through subroutine calls,
passes to lower levels in the tree. The subroutine model is only
applicable to sequential systems.
2. The manager model
• This is applicable to parallel systems. One system component is
designated as a system manager and controls the starting,
stopping & coordination of other system processes. A process is
a sub-system or a module which can execute in parallel with
other processes.
28

14
 08/03/2021

The call-return model

Main
program

Routine 1 Routine 2 Routine 3

Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2

The main program can call Routines1,2 & 3. Routine 1 can call Routine 1.1 or 1.2. Routine 3 can call Routines 3.1 or
3.2 etc. This is a model of the program dynamics. It is not a structural model. There is no need for Routine 1.1 to be
part of Routine 1.
Control passes from a higher-level routine to in the hierarchy to a lower-level routine. It then returns to the point
where the routine was called. The currently executing subroutine has responsibility for control and can either call
other routines or return control to it’s parent. This model may be used at the module level to control functions or
29
objects.

The manager model

Client 1 Client 1
Client 1
Sensor Client 1
Actuator
processes processes

System
controller

Computation User Fault

processes interface handler

The central controller manages the execution of a set of processes associated with sensors and
actuators. It decides when processes should be started or stopped depending on system state 30
variables.

15
 08/03/2021

Architectural design-Modular decomposition

(Refer slide no.11)
• After a structural architecture has been designed, the next stage of the
architectural design process is the decomposition of sub-systems into modules.
• Sub-system
• A sub-system is a system, in it’s own right whose operation does not depend on the
services provided by other systems. Sub-systems are composed of modules and have
defined interfaces which are used for communication with other sub-systems.

• Module
• A module is normally a system component, that provides one or more services to
other modules. It makes use of services provided by other modules. It is not normally
considered to be an independent system. Modules are usually composed of a
number of other simpler system components.

31

Modularity

32

16
 08/03/2021

Modules
• Software is divided into separately named & addressable components, called as
modules, that are integrated to satisfy problem requirements.

• Complexity of combination of problems, is greater than the complexity, when each

problem is handled separately.

• Effort needed to handle a combination of problems, is greater than the effort, when each
problem is handled separately.

• This leads to ‘Divide & Handle’ rule.

• It is easier to solve a complex problem, when it is broken into manageable pieces. This is
the argument for modularity.

33

Modularity
• Modularity facilitates
• The development process
• The maintenance process
• The project management process
• Reusability
• Two qualitative criteria are used to measure the goodness of a
module.
• Module Coupling
• Module Cohesion

34

17
 08/03/2021

Module Coupling and Cohesion

• Coupling between two modules is a measure of the degree of
interaction (or interdependence) between the two modules. It tells at
what level the modules interfere and interact with each other. The
lower the coupling, the better the program.

• Cohesion is a measure of the functional strength of a module.

Cohesion is a measure that defines the degree of intra-dependability
within elements of a module. High cohesion is desired.

Module Coupling (combination)

• A measure of the strength of the interconnections
between system modules.
• High coupling means component changes are likely to
affect other components.
• Errors occur at one location & broadcast through the
system when there is high coupling.
• Shared variables between modules or control
information exchange lead to tight coupling.
• Loose coupling can be achieved by component
communication through ‘parameter passing’.
• Coupling should be minimized for facilitating
• Maintenance
• Development
• Reusability
36

18
 08/03/2021

Module Cohesion (unity)

• A measure of the strength of the component
interconnections within a module. How well
components fit together.
• Cohesion is a desirable design characteristic as when
a change has to be made, it should be localized in a
single component.
• 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, a cohesive module should ideally do just one
thing.
• Designers should avoid low levels of cohesion (which
is undesirable) when modules are designed.
37

Interface Design

38

19
 08/03/2021

User interface design

• Good user interface design is critical to the success of
the system.
• Users see the software through the user interfaces.
This appearance of the software, affects to the first
impression of the user, which is very influential for
the usability.
• An interface that is difficult to use, will at best, result in a
high level of errors.
• At worst, users will refuse to use the software system
irrespective of it’s valuable functionality.

39

User interface design

• If information is presented in a confusing or
misleading way, users may misunderstand the
meaning of information. They may initiate a set of
actions that might corrupt data or even cause system
failures.
• The system should assist the user providing help
facilities and should guide the user in the case of
occurrence of an error.

40

20
 08/03/2021

Graphical user interfaces

• Although text based interfaces are still widely used,
especially in legacy systems (software systems which
are in use today, but developed many years ago)
computer users now expect application systems to
have some form of graphical user interface.
• The advantages of GUI are
• Easy to learn & use. Users with no computing experience
can learn to use the interface after a brief training.
• Users have multiple screens (windows) for system
interaction. Switching from one task to another is possible
without losing sight of information generated during the
first task.
• Fast, full screen interaction is possible with immediate
access to anywhere on the screen.

41

Characteristics of graphical user interfaces

Characteristic Description
Windows Multiple windows allow different information to be
displayed simultaneously on the user’s screen.

Icons Represent different types of information. On some

systems, icons represent files; on others icons
represent processes.
Menus Commands are selected, from a menu rather than
typed in a command language.

Pointing A pointing device such as a mouse is used for

selecting choices from a menu or indicating items of
interest in a window.
Graphics Graphical elements can be mixed with text on the
same display.

42

21
 08/03/2021

User interface design process

Analyze and Produce

Evaluate deign
understand paper-based
With end users
user activities Design prototype

Produce
Design Evaluate deign
Dynamic design
prototype With end users
prototype

Implement
Executable Final user
prototype interface

43

User interface design process

• The diagram illustrates the iterative, exploratory development
process of user interface design.
• The prototyping process may start with a simple paper-based
interface replicate, before going on to develop screen-based
designs that simulate user interaction.
• A user-centered approach should be used with end-users of the
system playing an active part in the design process. In some
cases, user’s role is an evaluation one; in others they participate
as full members of the design team.
• A critical user interface design activity is the analysis of the user
activities supported by the computer system (activity 1 of
diagram). Without an understanding of what the user wants to
do with the computer system, there is no realistic view of
designing an effective user interface.
44

22
 08/03/2021

User interface design principles

• Human behavior & capabilities are the basis for
user interface design principles.
• People have a limited short-term memory & they
make mistakes, when they are under stress.
• They have a diverse range of physical capabilities.
• Followings are the general principles which are
applicable to all user interface design.

45

Colors in interface design

• Colors can improve user interfaces, by helping
users for understanding & managing complexity.

• But it is easy to misuse colors & to create user

interfaces visually unattractive or crowded.

• Followings are some guidelines for effective use of

color.

46

23
 08/03/2021

Guideline for color utilization

• Limit the number of colors used
• More then 4 or 5 separate colors should not be used in a window and
not more than 7 in a system interface. Colors should be used
selectively & consistently not just to brighten up an interface.
• Use color change to show a change in system status
• If the display changes color this should mean that a significant event
has occurred.
• Use color coding in a thoughtful & consistent way
• If one part of a system displays error messages in red, all other parts
should do like that. Red should not be used for anything else.
• Be careful about color pairing
• Because of the physiology of the eye, some color combinations are not
good. Eg: Red on blue display results eyestrain.
If too many colors are used or if the colors are too bright, the
display may be confusing. The mass of color may disturb the
user & cause visual fatigue. User confusion is also possible, if
colors are used inconsistently.
47

User support
• User interfaces should always provide some form of
user help. Help systems are a general part of user
interface design.
• User guidance should be provided in following areas.
• The messages produced by the system in response to user
action.
• The online help system
• The documentation provided with the system
• Design of useful information for users should be taken
seriously. Sufficient time & effort should be allocated
for this, and it may be appropriate to involve
professional writers & graphic artists in the process.

48

24
 08/03/2021

Error messages
• When designing error messages, background & experience of users
should be anticipated.
• Error messages should be polite, brief, consistent and positive.
• Whenever possible, the message should suggest how the error might
be corrected. The error message should be linked to an online help
system.

49

Good & bad error messages

• The nurse enters the name of a patient to the
computer based patient monitoring system. If the
entered name is wrong, an error message appears.

System-oriented error message User-oriented error message

Patient [Link] is not registered

? Error #27
Invalid patient id entered
Click on Patients for a list of registered patients
Click on Retry to re-input a patient name
Click on Help for more information
OK Cancel
Patients Help Retry Cancel

50

25
 08/03/2021

Good & bad error messages

• The first error message is badly designed.
• It accuses the user of making an error.
• It does not suggest how the situation might be
rectified.
• It uses system specific terms (patient-id) rather than
user-oriented language.
• Second error message is positive.
• Identifies the problem in the nurse’s terms and offers
an easy way to correct the mistake by pressing a
single button. The Help system is available if required.

51

Help system design

• When users are presented with an error message they do not
understand, they turn to the help system for information.
• Eg:
• Help!
• ‘help, I am in trouble’
• Help?
• ‘help, I want information’
• Different system facilities & message structures may be
needed to provide these different types of help.
• Help systems should provide number of different user entry
points.
• These should allow the user to enter the help system
• At the top of the message hierarchy & browse for information
• To request an explanation of a particular application command
• To get an explanation of an error message
52

26
 08/03/2021

Entry points to a help system

Help frame network
Top level entry

Entry from application

Entry from error

message system

53

User documentation
• User documentation is not strictly part of user interface design, but it
is good practice to design the online help support in combination with
paper documentation.
• The system manuals should provide more detailed information than
the online help. They should be designed, so that it can be used by
different categories of system end-users.
• To cater for these end-users & user-expertise, at least 5 documents
(or chapters in a single document) should be delivered with the
software system.

54

27
 08/03/2021

Reader
User documentation-Illustration
Name of
document

System System Beginner level Experienced System

evaluators administrators users users administrators

Functional Installation Introductory Reference Administrator’s

description document manual manual guide

Description of How to install Getting Facility Operation &

services The system started description maintenance

Content 55

56

28