Chapter 4- Software Design

Software Design Overview

Design is the modeling activity where stakeholder requirements, business needs, and technical
considerations come together in the formulation and development of a high-quality system
or product.
Design creates a model of the software. This model can be assessed for quality and improved
before code is generated, tests are conducted, and end users become involved in large numbers.
IEEE Definition of Software Design
Software design is defined as follows:
Design is both “the process of defining the architecture, components, interfaces, and other
characteristics of a system or component” and “the result of that process”.
Software design is the last software engineering action within the modeling activity and sets
the stage for construction activity (code generation and testing).

Relationship between analysis model and design model

Each of the elements of the analysis model provides necessary information to create the design
models. Figure illustrates the relationship between analysis and design model.
The flow of information during software design phase is illustrated in above figure .
Software requirements, demonstrated by the data, functional, and behavioural models. The
design phase produces a data design, an architectural design, an interface design, and a
component design.
The data design transforms the information domain model created during analysis phase
into the data structures that will be required to implement the software.
The data objects and relationships defined in the entity relationship diagram and the
detailed data content represented in the data dictionary provide the basis for the data
design activity .
The architectural design defines the relationship between main structural elements of the
software. The design patterns can be used to achieve the requirements that have been
defined for the system. The architectural design representation can be derived from the
system specification, the analysis model, and the interaction of subsystems defined within
the analysis model.
The interface design describes how the software communicates within itself, with
systems that interoperate with it, and with humans who use it. An interface implies a
flow of information and a specific type of behavior. Therefore, a data and control flow diagram
provides the information required for interface design.
Characteristics of a good design:

Design Principles

1. The design process should not suffer from “tunnel vision.”

A good designer should consider alternative approaches, judging each based on the
requirements of the problem, the resources available to do the job.

2. The design should be traceable to the analysis model.

Because a single element of the design model often traces to multiple requirements, it
is necessary to have a means for tracking how requirements have been satisfied by the
design model.

3. The design should not reinvent the wheel.

Systems are constructed using a set of design patterns, many of which have likely been
encountered before. These patterns should always be chosen as an alternative to
reinvention. Time is short and resources are limited! Design time should be invested in
representing truly new ideas and integrating those patterns that already exist.

4. The design should minimize the intellectual distance between the software and the
problem as it exists in the real world.
That is, the structure of the software design should mimic the structure of the problem
domain.

5. The design should exhibit uniformity and integration.

A design is uniform if it appears that one person developed the entire thing. Rules of
 style and format should be defined for a design team before design work begins. A
design is integrated if care is taken in defining interfaces between design components.

6. The design should be structured to accommodate change.

The design concepts discussed in the next section enable a design to achieve this
principle.

7. The design should be structured to degrade gently, even when aberrant data,
events, or operating conditions are encountered.
Well-designed software should never “bomb.” It should be designed to accommodate
unusual circumstances, and if it must terminate processing, do so in a graceful manner.

8. Design is not coding; coding is not design.

Even when detailed procedural designs are created for program components, the level
of abstraction of the design model is higher than source code. The only design decisions
made at the coding level address the small implementation details that enable the
procedural design to be coded.

9. The design should be assessed for quality.

A variety of design concepts and design measures are available to assist the designer in
assessing quality.

10. The design should be reviewed to minimize conceptual (semantic) errors.

There is sometimes a tendency to focus on minutiae when the design is reviewed,
missing the forest for the trees. A design team should ensure that major conceptual
elements of the design (omissions, ambiguity, and inconsistency) have been addressed
before worrying about the syntax of the design model.
Design Concepts
Effective Modular Design – Cohesion and Coupling

Design process requires establishing association between modules and communication or

interaction within modules. The association between modules is necessary to reduce
complexity, to facilitate change, adaptability, maintenance and reliability. The relationships
between modules is described by cohesion and coupling.

Cohesion
Cohesion refers to the relationship among elements within a module. In this modules are
designed to perform a specific function. While designing a module high level of cohesion
should be preferred and low level of cohesion should be avoided.

Types of cohesion:
1. coincidental cohesion
2. logical cohesion
3. Temporal cohesion
4. Procedural cohesion
5. Communicational cohesion
6. Sequential cohesion
7. Functional cohesion

[Link] cohesion
In coincidental cohesion, cohesive module performs a set of tasks that relate to each other very
loosely. Different functions in a module carry out different activities.

[Link] cohesion
In logically cohesive modules there exists some logical relationship between the elements of a
module. Some interrelationships occur between logically cohesive modules.

[Link] Cohesion
In this type of cohesion modules are organised in such a way that they are processed at a
similar point of time

[Link] cohesion
A module is said to have procedural cohesive when elements of module are grouped together
and which are executed sequentially in order to perform a task, it is called procedural cohesion.

[Link] cohesion
When elements of module are grouped together, which are executed at one time and also work
on same data or information, it is called communication cohesion.

[Link] cohesion
In this type of cohesion elements of modules are grouped together and the output of one element
serves as the input to the next element.

7. Functional cohesion
It is considered to be the highest degree of cohesion, and it is highly expected. Elements
of module in functional cohesion are grouped because they all contribute to a single well-
defined function. It can also be reused

Coupling
Coupling is the interdependence of one module to another module. Modules should have low
coupling. Coupling is a property or characteristics of a collection of modules. High coupling
implies greater dependency between modules. Low coupling minimises the interdependence
between modules.
Types of coupling:
1. Data Coupling
[Link] Coupling
[Link] Coupling
[Link] Coupling
[Link] Coupling
1. Data Coupling:
If the modules communicate via passing parameters between the two then modules are
called as data coupled.

2. Stamp Coupling:
If the multiple modules share common data structure and work on different part of it then
modules are called stamp coupled.

3. Control Coupling:
In control coupling control flags are passed as parameters so that one module controls the
sequence of processing steps in another module.

4. Common Coupling:

Common coupling occurs when the same global data is shared by two modules.

5. Content Coupling:

Content coupling occurs when one of the module depends on the other modules internal
working.
Difference between Cohesion and Coupling

Cohesion Coupling

Cohesion is the indication of the relationship Coupling is the indication of the relationships
within module. between modules.

Cohesion shows the module’s relative Coupling shows the relative independence
functional strength. among the modules.

Cohesion is a degree (quality) to which a Coupling is a degree to which a component /

component / module focuses on the single module is connected to the other modules.
thing.

While designing you should strive for high While designing you should strive for low
cohesion i.e. a cohesive component/ module coupling i.e. dependency between modules
focus on a single task (i.e., single- should be less.
mindedness) with little interaction with other
modules of the system.

Cohesion is the kind of natural extension of Making private fields, private methods and
data hiding for example, class having all non public classes provides loose coupling.
members visible with a package having
default visibility.

Cohesion is Intra – Module Concept. Coupling is Inter -Module Concept.

Design models

Design model produces four types of designs-

1. a data/class design,

2. an interface design,

3. an architectural design and

4. a component-level design.

Architectural Design
Architectural design or architectural style refers to the structure of data and program
components required to build software. Software architecture design includes the process of
dividing software into subsystems, their interaction and determining interfaces between them.
The software for computer-based systems exhibits one of many architectural styles.

Each style describes a system category that includes:

• A set of components like database, computational models that perform a function required
by system.
• A set of connectors among components for communication, conversion, coordination and
cooperation
• Constraints that define how components can be integrated to form the system
• Semantic models that enable a designer to understand the overall properties of a system by
analysing the known properties of its constituent parts.

The different architectural styles are:

1. Data-centered architectures

2. Data flow architectures

3. Call and return architectures

4. Object-oriented architectures

5. Layered architectures
[Link]-centered architectures

A data –centered architectures has two main components, a data store and a collection of client
software. In this architectural style the database resides at the centre of the architecture design
and all other software components accesses data stored in the database. Other software
components can add, update, delete or modify the data in the data store. Existing components
can be changed and new components can be added without affecting the other components.
client components operate independent of one another. Figure shows the data centred
architectural style.

2. Data Flow Architectures

In data flow architectural style data is transformed through a series of computational or
manipulative components into output data. Example of this architecture is UNIX shell
programs. In these programs, UNIX processes act as filters and the file system through which
UNIX processes interact, act as pipes.
There are two types of data flow architecture:
a. Pipe and filter architecture contains set of components called filters connected by pipes
that transmit data from one component to the next. Figure shows the pipe and filter
architectural style.
b. The batch sequential format, which is the simplified version of the pipe and filter
pattern. It accepts a batch of data and then applies a series of sequential components to
transform it.
3. Call and return architectures
Call and return architecture enables you to achieve a program structure that is easy to modify
and scale. In this type of architecture, the function is decomposed into a control hierarchy where
a main program invokes a number of program components, which in turn invokes other
components.
The following figure represents call and return architectures.

4. Object-oriented architectures
The components of the system encapsulate data and the operations that must be applied to
manipulate data. Communication and coordination between components are accomplished via
message passing.
5. Layered architectures
In this architecture style a number of different layers are defined, each accomplishing
operations that progressively become closure to the machine instruction set. At the outer layer,
components service interface operations. At the inner layer, components perform operating
system interfacing. Intermediate layers provide utility services and application software
functions
Following figure illustrates layered architecture style.

Component-level design
Component -level design takes place after the architectural design has been completed. The
objective of this component-level design is to transform the design model into functional
software.

The component -level design represents the internal data structures and processing details of
all the software components which are defined during architectural design at an abstraction
level, closer to the actual code.

The component level design can be represented by using various approaches such as
programming language, using some design notation (e.g Data Flow Diagram(DFD), Flow
chart) or by using decision tables .

The following are steps to represent component-level design for software system.

1. Identify all design classes that correspond to the problem domain.

2. Identify all design classes that correspond to the infrastructure domain.
[Link] all design classes that are not acquired as reusable components.
a. Specify message details when classes or components collaborate.
b. Identify appropriate interfaces for each component.
c. Elaborate attributes and define data types and data structures required to implement
them.
d. Describe processing flow within each operation in detail.
[Link] persistent data sources (databases and files) and identify the classes required to
manage
them.
[Link] and elaborate behavioral representations for a class or component.
[Link] deployment diagrams to provide additional implementation detail.
[Link] every component-level design representation and always consider alternatives.

Component-level design using notations

1. Graphical Design Notations

2. Tabular Design Notation

For example- decision table representation for printer trouble-shooter

3. Program Design Language (PDL)/Structured English/Pseudocode

PDL incorporates the logical structure of a programming language with the free-form
expressive ability of a natural language (e.g., English).
For example, writing pseudo code for program.

User Interface Design

User interface design creates an effective communication medium between a human and a
computer. User interface design identifies interface objects and actions and then creates a
screen layout that forms the basis for a user interface prototype. Then the prototype is modified
in an iterative way based on the feedback received from users. User interface design is an
iterative process. The screen layout represents graphical design. It includes proper use of icons,
definition of descriptive screen text, titling of windows, and specification of menus.

The three golden rules for user interface design:

Theo Mandel defines three golden rules for user interface design.
1. Place the user in control.
2. Reduce the user's memory load.
3. Make the interface consistent.

1. Place the user in control.

During a requirements elicitation for a software system, a major user is asked about the
attributes of the graphical user interface.
Theo Mandel defines a number of design principles that allow user to maintain control.
i. Define interaction modes in a way that does not force a user into unnecessary or
undesired actions.
The interaction modes should defined in such a way that user should be able to enter and exit
the interaction mode with a little or no effort at all.

ii. Provide for flexible interaction.

There are various categories of user using the software so accordingly their interaction
preferences are different. Choices should be provided for all categories of users.
e.g. software might allow a user to interact via a keyboard commands, mouse click, and
digitizer pen, multi touch screen or voice recognition commands.

iii. Allow user interaction to be interruptible and undoable.

The user should be able to interrupt the sequence to do something else also be able to undo any
action.

iv. Streamline interaction as skill levels advance and allow the interaction to be
customized.
Sometime user finds that they perform the same sequence of actions repeatedly. In such cases
the design should enable an advanced user to customize the interface to facilitate interaction.
v. Hide technical internals from the casual user.
Users are not required to know the lower-level details of machines. It is not necessary to know
the details of operating system, file management functions to the user of the system.

vi. Design for direct interaction with objects that appear on the screen.

2. Reduce the user's memory load.

A well-designed user interface does not require the user’s memory. Whenever required the
system should remember the relevant information and help user with an interaction scenario
that helps user to recall.
Mandel defines design principles that enable an interface to reduce the user’s memory load.

i. Reduce demand on short-term memory.

The interface should be designed to reduce the user's requirement to remember past actions,
inputs and results by providing visual cues of such actions.

ii. Establish meaningful defaults.

The user should be able to specify individual preferences. However, the reset option should be
available for users to reset the default values.

iii. Define shortcuts those are intuitive.

Meaningful or relevant shortcuts should be defined that is easy to remember. e.g., keyboard
shortcuts with appropriate letter or highlighted letter.

iv. The visual layout of the interface should be based on a real-world metaphor.
While using an interface system user should be able to rely on visual metaphor of that process
instead of remembering the interaction sequence.

v. Disclose information in a progressive fashion.

The interface should be organized hierarchically. At the first level, the information should
be presented at a higher level of abstraction. More detail should be provided based on user’s
interests or actions.
3. Make the Interface Consistent
Interface presentation and information acquisition mechanisms should be consistent, implying:
i. Visual information displays consistently throughout all screens.
ii. Input mechanisms are limited to a limited set that is used consistently within the system.
iii. Mechanisms for navigating from task to task are consistently defined and implemented.

Mandel defines a set of design principles that help make the interface consistent:

i. Allow the user to put the current task into a meaningful context.
For a complex system there are various screen layouts. It is important to provide proper colours,
graphical icons that enable user5s to know where he has and what alternatives exists for
transition to a new task. Icons, colour coding, tiles should show where the user is.

ii. Maintain consistency across a family of applications.

Similar types of applications should implement a same design rule to maintain the consistency
for transition.
iii. If past interactive models have created user expectations, do not make changes unless
there is a compelling reason to do so.

The User Interface Process

The interface design refers how the software communicates with other systems and with
humans who use [Link] following diagram depicts user interface process.
The user interface process has four key activities:
i. Interface Analysis (user, task, and environment analysis)
ii. Interface Design
iii. Interface Construction
iv .Interface Validation
The process is a spiral process. At the end of the spiral process a prototype is developed and
validated, then iteration through the model is done to incorporate feedback.
1. Interface Analysis
Analysis focuses on the following four:
i. User analysis
ii. Task analysis
iii. Content analysis (display content)
iv. Work environment analysis
User analysis
Users are the ones who will use the system. It focuses on analysing the users and how they
will use the system. Questions include: user skills/education, user language, from which
departments, their age, consequences of making mistakes, working times, remuneration,
gender, etc.
Task analysis
1. Task analysis includes
i. The work done in all scenarios
ii. Tasks and sub-tasks of every work unit performed by the user
iii. Domain objects manipulated while performing the work
iv. Sequence of work tasks or workflow
v. Hierarchy of tasks
2. Use cases describe how an actor or users interacts with the system. It will identify
i. How end users perform tasks
ii. Exact tasks, objects manipulated, and workflow
iii. System features

Content analysis
Display content can be text, graphs, pictures, videos, audios [Link] following questions need
to be asked:
i. Are pictures, navigation tools, menus etc. properly placed on their geographical content
location?
ii. Can users customise the content location?
iii. If a lot of data is displayed, how can it be partitioned for better understanding?
iv. What summarisation can be done in case of large collection of data?
v. What colours are to be used to enhance understanding?
vi. What warning or error messages are shown for users?

Work Environment analysis

Work environment analysis includes amount of lighting in workspace, height or size of display
mechanism, workspace size, temperature and humidity conditions, keyboard size and height ,
workspace time restrictions etc.

2. Interface Design
The design process is an iterative process where refinement is done at each iteration.
The general steps are:
1. From user interface analysis information, define user interface objects and operations
2. Define events or user actions that will cause the state of the user interface to change.
Model this behaviour.
3. Depict each interface state as it will actually look to the end user.
4. Indicate how the user interprets the state of the system from information provided
through the interface
The common design issues that must be considered are usually the following:
1. System response time
System response time is the important issue for many interactive applications. In
general, system response time is measured from the point at which the user performs
some control action e.g., hits the return key or clicks a mouse until the software
responds with desired output or action.
2. User help facilities
A number of design issues must be addressed when a help facility is considered.
i. Will help be available for all system functions and at all times during system
interaction?
ii. How will the user request help? Options include a help menu, a special function key,
 or a HELP command.
iii. How will help be represented? Options include a separate window, a reference to a
printed document or a one- or two-line suggestion produced in a fixed screen location.
iv. How will the user return to normal interaction? Options include a return button
displayed on the screen, a function key, or control sequence.
3. Error handling
Error message or warning message should have the following characteristics
i. The message should describe the problem in such a way that user can understand.
[Link] message should provide constructive advice for recovering from the error.
iii. The message should be assisted by an audible or visual cue.
iv. The message should be non-judgmental.
4. Menu and command labelling
A number of design issues arise when typed commands or menu labels are provided
as a mode of interaction:
i. Will every menu option have a corresponding command?
ii. What form will commands take? Options include a control sequence , function keys,
or a typed word.
iii. Can commands be customized or abbreviated by the user?
iv. Are menu labels self-explanatory within the context of the interface?

3. Interface Construction
Based on the earlier steps, a prototype is created. Physical material like paper can be used to
model early prototypes of the user interface. Other computer-based design tools can be used.

4. Interface Validation
Once you have created operational prototype it must be evaluated to determine whether it meets
user’s requirements.
The user interface evaluation cycle takes the form as shown in following figure.

Once the design model has been created, a first-level prototype is created. This prototype is
evaluated by the user. Then user provides feedback. Feedback is evaluated by the designer.
Design modifications are made based on the user inputs and next level prototype is created.
The evaluation cycle continues until no further modifications are required to interface design.
Types of user interface
1. Text-Based User Interface or Command Line Interface
2. Graphical User Interface (GUI)

1. Text-Based User Interface or Command Line Interface

• This method relies primarily on the keyboard.
• Example – UNIX

2. Graphical User Interface (GUI)

A GUI is an interface built around visual (graphical) things.
The visual (graphical) things are-
• Windows are regions of the screen used to display information.
• Icons are small pictures that are used to represent folders, software, etc.
• Menus are lists of options the user can select from.
• A pointer is an arrow that can be moved around the screen and is used to select
things.
Example- Dia software user interface

Other forms of UI design are:

Voice-controlled interfaces-
• These are the interfaces that require voices to initiate an action.
• These are becoming more popular these days.
• Some examples are Apple’s Siri, Amazon’s Alexa or Google’s Bixby.
Gesture-based interfaces-
• These are interfaces in which a user’s gestures affect the action of a product.
• An example of this would be Virtual Reality games.

References:
Roger Pressman, “Software Engineering: A Practitioner’s Approach”, McGraw-Hill
Publications
[Link]
[Link]
[Link]
[Link]
20not,traceable%20to%20the%20analysis%20model.