Unit 3

Software Design
Design Concept
• The software design concept simply means the idea or principle behind the design.

• It describes how you plan to solve the problem of designing software, the logic, or
thinking behind how you will design software.

• It allows the software engineer to create the model of the system or software or
product that is to be developed or built.

• The software design concept provides a supporting and essential structure or model
for developing the right software.
There are many concepts of software design and some of them are
given below:
Abstraction
• Abstraction simply means to hide the details to reduce complexity and increases
efficiency or quality.

• Different levels of Abstraction are necessary and must be applied at each stage of the
design process so that any error that is present can be removed to increase the
efficiency of the software solution and to refine the software solution.

• The lower level of abstraction provides a more detail description of the solution.

• A sequence of instruction that contain a specific and limited function refers in a

procedural abstraction.

• A collection of data that describes a data object is a data abstraction.

Architecture
• The complete structure of the software is known as software architecture.

• Structure provides conceptual integrity for a system in a number of ways.

• The architecture is the structure of program modules where they interact with each
other in a specialized way.

• The components use the structure of data.

• The aim of the software design is to obtain an architectural framework of a system.

• The more detailed design activities are conducted from the framework.
Pattern- a repeated form
• The pattern simply means a repeated form or design in which the same shape is
repeated several times to form a pattern.

• The pattern in the design process means the repetition of a solution to a common
recurring problem within a certain context.
Modularity- subdivide the system
• Modularity simply means dividing the system or project into smaller parts to reduce
the complexity of the system or project.
• In the same way, modularity in design means subdividing a system into smaller parts
so that these parts can be created independently and then use these parts in different
systems to perform different functions.
• It is necessary to divide the software into components known as modules because
nowadays there are different software available like Monolithic software that is hard
to grasp for software engineers.
• So, modularity in design has now become a trend and is also important.
• If the system contains fewer components then it would mean the system is complex
which requires a lot of effort (cost) but if we are able to divide the system into
components then the cost would be small.
Information Hiding- hide the information
• Information hiding simply means to hide the information so that it cannot be accessed
by an unwanted party.

• In software design, information hiding is achieved by designing the modules in a

manner that the information gathered or contained in one module is hidden and can’t
be accessed by any other modules.
Functional independence
• The functional independence is the concept of separation and related to the concept of
modularity, abstraction and information hiding.
• The functional independence is accessed using two criteria i.e Cohesion and coupling.

1. Cohesion
• Cohesion is an extension of the information hiding concept.
• A cohesive module performs a single task and it requires a small interaction with the
other components in other parts of the program.

2. Coupling
• Coupling is an indication of interconnection between modules in a structure of
software.
Refinement- removes impurities
• Refinement simply means to refine something to remove any impurities if present and
increase the quality.
• The refinement concept of software design is actually a process of developing or
presenting the software or system in a detailed manner that means to elaborate a system
or software.
• Refinement is very necessary to find out any error if present and then to reduce it.
Refactoring- reconstruct something
• Refactoring simply means reconstructing something in such a way that it does not
affect the behavior of any other features.

• Refactoring in software design means reconstructing the design to reduce

complexity and simplify it without affecting the behavior or its functions.

• Fowler has defined refactoring as “the process of changing a software system in a

way that it won’t affect the behavior of the design and improves the internal
structure”.
Design Heuristics
• The main goal of heuristic evaluations is to identify any problems associated with the
design of user interfaces.
• Usability consultant Jakob Nielsen developed this method on the basis of several years
of experience in teaching and consulting about usability engineering.
• Heuristic evaluations are one of the most informal methods of usability inspection in the
field of human-computer interaction.
• There are many sets of usability design heuristics; they are not mutually exclusive and
cover many of the same aspects of user interface design.
• The simplicity of heuristic evaluation is beneficial at the early stages of design.
• Heuristic evaluation requires only one expert, reducing the complexity and expended
time for evaluation.
NIELSEN'S HEURISTICS
• Jakob Nielsen's heuristics are probably the most-used usability heuristics for user
interface design. Nielsen developed the heuristics based on work together with Rolf
Molich in 1990.
• The final set of heuristics that are still used today were released by Nielsen in 1994.
• The heuristics as published in Nielsen's book Usability Engineering are as follow.

1.Visibility of system status:

• The system should always keep users informed about what is going on, through
appropriate feedback within reasonable time.
Cont...
2. Match between system and the real world.
• The system should speak the user's language, with words, phrases and concepts familiar to
the user, rather than system-oriented terms.
• Follow real-world conventions, making information appear in a natural and logical order.

3. User control and freedom:

• Users often choose system functions by mistake and will need a clearly marked "emergency
exit" to leave the unwanted state without having to go through an extended dialogue. Support
undo and redo.

4. Consistency and standards:

• Users should not have to wonder whether different words, situations, or actions mean the
same thing. Follow platform conventions.
Cont...
5. Error prevention:
• Even better than good error messages is a careful design which prevents a problem from
occurring in the first place. Either eliminate error-prone conditions or check for them and
present users with a confirmation option before they commit to the action.

6. Recognition rather than recall:

• Minimize the user's memory load by making objects, actions, and options visible. The
user should not have to remember information from one part of the dialogue to another.
Instructions for use of the system should be visible or easily retrievable whenever
appropriate.

7. Flexibility and efficiency of use:

• Accelerators—unseen by the novice user—may often speed up the interaction for the
expert user such that the system can cater to both inexperienced and experienced users.
Allow users to tailor frequent actions.
Cont...

8. Aesthetic and minimalist design:

• Dialogues should not contain information which is irrelevant or rarely needed.
Every extra unit of information in a dialogue competes with the relevant units of
information and diminishes their relative visibility.
Architectural Design
• The software needs the architectural design to represents the design of software.
• IEEE defines architectural design as “the process of defining a collection of hardware and
software components and their interfaces to establish the framework for the development
of a computer system.
• Each style will describe a system category that consists of :

1. A set of components(eg: a database, computational modules) that will perform a

function required by the system.
2. The set of connectors will help in coordination, communication, and cooperation
between the components.
3. Conditions that how components can be integrated to form the system.
4. Semantic models that help the designer to understand the overall properties of the
system.
5. The use of architectural styles is to establish a structure for all the components of the
system.
Cont...
• We can segregate Software Architecture and Design into two distinct phases: Software
Architecture and Software Design.
• In Architecture, nonfunctional decisions are cast and separated by the functional
requirements.
• In Design, functional requirements are accomplished.
Taxonomy of Architectural styles:
1] Data centered architectures:
A data store will reside at the center of this architecture and is accessed frequently by the
other components that update, add, delete or modify the data present within the store.
The main purpose of this style is to achieve integrality of data.
Data-centered architecture consists of different components that communicate through
shared data repositories.
The components access a shared data structure and are relatively independent, in that, they
interact only through the data store.
The most well-known examples of the data-centered architecture is a database architecture,
in which the common database schema is created with data definition protocol – for
example, a set of related tables with fields and data types in an RDBMS.
Example of Data centered architectures:
Advantage of Data centered architecture
• Repository of data is independent of clients
• Client work independent of each other
• It may be simple to add additional clients.
• Modification can be very easy

Uses
• Data-Centered Architecture is also commonly used in other domains such as
healthcare (patient records and monitoring), e-commerce (customer data and
product information), Stock Trading System(The system needs to handle a
massive amount of real-time data, including stock prices, trade orders, and market
news)
2. Data Flow Architecture

• Data Flow Architecture is a software architectural style that emphasizes the flow of data
within a system.
• It is often used in the design of systems that need to process and transform data as it moves
through different components or modules.
• In Data Flow Architecture, the system is modeled as a series of data transformations, and the
focus is on how data is input, processed, and output.
• The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has
a set of components called filters connected by lines.
• Pipes are used to transmitting data from one component to the next.
• Each filter will work independently and is designed to take data input of a certain form and
produces data output to the next filter of a specified form.
• The filters don’t require any knowledge of the working of neighboring filters.
Eg: Data Flow Architecture
3] Call and Return architectures:

• It is used to create a program that is easy to scale and modify.

• Many sub-styles exist within this category.
• Two of them are explained below.

I. Remote procedure call architecture: This components is used to present in a main

program or sub program architecture distributed among multiple computers on a
network.

II. Main program or Subprogram architectures: The main program structure decomposes
into number of subprograms or function into a control hierarchy. Main program
contains number of subprograms that can invoke other components.
Eg: Call And Return Architecture
4] Object Oriented architecture:
• The components of a system encapsulate data and the operations that must
be applied to manipulate the data.
• The coordination and communication between the components are
established via the message passing.
• An architecture in which everything (processes, files, I/O operations, etc.) is
represented as an object.
Layered architectures
• A number of different layers are defined with each layer performing a well-defined set of
operations.
• Each layer will do some operations that becomes closer to machine instruction set
progressively.
• At the outer layer, components will receive the user interface operations and at the inner
layers, components will perform the operating system interfacing(communication and
coordination with OS).
• It consists of outer and inner layer.
• The components of outer layer manage the user interface operations.
• Components execute the operating system interfacing at the inner layer.
• The inner layers are application layer, utility layer and the core layer.
Diagram: Layered Architecture
Architectural design
• The architectural design starts then the developed software is put into
the context.
• The information is obtained from the requirement model and other
information collect during the requirement engineering.
Representing the system in context
All the following entities communicates with the target system through the interface that is small rectangles
shown in above figure

Superordinate system
• These system use the target system like a part of some higher-level processing scheme.

Subordinate system
• This systems is used by the target system and provide the data mandatory to complete target
system functionality.

Peer-level system
• These system interact on peer-to-peer basis means the information is consumed by the target
system and the peers.

Actors
• These are the entities like people, device which interact with the target system by consuming
information that is mandatory for requisite processing.
Defining Archetype
• An archetype is a class or pattern which represents a core abstraction i.e critical to
implement or design for the target system.

• A small set of archetype is needed to design even the systems are relatively complex.

• The target system consists of archetype that represent the stable elements of the
architecture.

• Archetype is instantiated in many different forms based on the behavior of the system.

• In many cases, the archetype is obtained by examining the analysis of classes defined as a
part of the requirement model.
Scenario based Modeling
 Writing use cases:
Use case captures the interactions that occur between producers
and consumers of information and the system itself.

The safeHome home surveillance

 Select camera to view.

 Request thumbnails from all cameras.
 Display camera views in a PC window.
 Control pan and zoom for a specific camera.
 Selectively record camera output.
 Replay camera output.
 Access camera surveillance via the Internet
 Developing an Activity Diagram:
The UML activity diagram supplements the use case by providing
a graphical representation of the flow of interaction within a
specific scenario.

Rounded rectangles to imply a specific system function,

Arrows to represent flow through the system,

Decision diamonds to depict a branching decision (each arrow

emanating from the diamond is labelled), and

Solid horizontal lines to indicate that parallel activities are

occurring.
Activity diagram for access camera surveillance
display camera views function
 Swimlane Diagram:

The UML swimlane diagram is a useful variation of the activity

diagram and allows you to represent the flow of activities
described by the use case and at the same time indicate which
actor has responsibility for the action described by an activity
rectangle.

Responsibilities are represented as parallel segments that divide

the diagram vertically, like the lanes in a swimming pool.
Class based Modeling
Specifying Attributes

Defining Operations:
 Class Responsibility Collaborator (CRC)
Modeling
The cards are divided into three sections. Along the top of the card
you write the name of the class. In the body of the card you list the
class responsibilities on the left and the collaborators on the right.
Dependencies: In many instances, a client-server relationship
exists between two analysis classes.

In such cases, a client class depends on the server class in some

way and a dependency relationship is established.
 Analysis Packages:

An important part of analysis modeling is categorization. That is,

various elements of the analysis model (e.g., use cases, analysis
classes) are categorized in a manner that packages them as a
grouping-called an analysis package that is given a representative
name.
Flow Oriented Modeling
The DFD takes an input-process-output view of a
system.

Data objects flow into the software, are transformed

by processing elements, and resultant data objects
flow out of the software.

Data objects are represented by labelled arrows, and

transformations are represented by circles.
Context-level DFD/ 0-level DFD for the Safe Home
security function
Creating Data Flow Model
• The level 0 data flow diagram should depict the
software/system as a single bubble.
• Primary input and output should be carefully noted.
• Refinement should begin by isolating candidate
processes, data objects, and data stores to be
represented at the next level.
• All arrows and bubbles should be labelled with
meaningful names.
• Information flow continuity must be maintained from
level to Level .
• One bubble at a time should be refined.
Level 1 DFD
Level 2 DFD
 Control Specification

•Represents the behavior of the system.

•Control Specification contains a state diagram that is a

sequential specification of behavior.

•The diagram indicates how the system responds to

events.
State diagram for Safe Home security Function
Design Concept
 A set of fundamental software design concepts has
evolved over the history of software engineering.

Helps you answer the following questions:

• What criteria can be used to partition software into

individual components?

• How is function or data structure detail separated from

a conceptual representation of the software?

• What uniform criteria define the technical quality of a

software design?
 1. Abstraction
At the highest level of abstraction, a solution is stated in broad
terms using the language of the problem environment.

At lower levels of abstraction, a more detailed description of the

solution is provided.

Procedural abstraction: refers to a sequence of instructions that

have a specific and limited function.
Ex: word open for a door.

Open implies a long sequence of procedural steps (e.g., walk to

the door, reach out and grasp knob, turn knob and pull door, step
away from moving door, etc.)
 2. Architecture
Architecture is the structure or organization of program
components, the manner in which these components interact,
and the structure of data that are used by the components.

Structural properties: Defines the components of a system(e.g.

modules, objects, filter) and manner in which they are packaged
and interact with one another.

Extra-functional properties: How the design architecture achieves

requirements for performance, capacity, reliability, security,
adaptability, and other system characteristics.

Families of related systems: Design should have the ability to

reuse architectural building blocks
Modularity
Software is divided into separately named and addressable
components, sometimes called “modules”.

Modularity is the single attribute of software that allows a

program to be intellectually manageable.

If you subdivide software indefinitely the effort required to

develop it will become negligibly small.
 Information Hiding
Modules should be specified and designed so that information
(algorithms and data) contained within a module is in-accessible
to other modules that have no need for such information.

Functional Independence

You should design software so that each module addresses a

specific subset of requirements and has a simple interface when
viewed from other parts of the program structure.
 Refinement
A hierarchy is developed by decomposing a macroscopic
statement of function in a stepwise fashion until programming
language statements are reached.

Refinement is actually a process of elaboration.

Begins with high level of abstraction and move towards internal

details of functions.

Abstraction and refinement are complementary concepts

 Refactoring
Refactoring is the process of changing a software system in such a
way that it does not alter the external behavior of the code design
yet improves its internal structure.

When software is refactored, the existing design is examined for:

•Redundancy.
•Unused design elements.
•Inefficient or unnecessary algorithms.
•Poorly constructed or inappropriate data structures.
•Or any other design failure.
Design Model
The process dimension indicates the evolution of the design
model as design tasks are executed as part of the software
process.

The abstraction dimension represents the level of detail as

each element of the analysis model is transformed into a design
equivalent and then refined iteratively.

Dashed line indicates the boundary between the analysis and

design models.
 Data Design Elements
Data design creates a model of data and/or information that is
represented at a high level of abstraction.

This data model is then refined into progressively more

implementation specific representation.

Program component level: Data structure and associated

algorithms.

Application Level: Translation of data model into databases.

Business level: The collection of information stored in disparate

databases and reorganized into a "data warehouse”.
 Architectural Design
Elements
The architectural design for software is the equivalent to the floor
plan of a house. The floor plan depicts the overall layout of the
rooms ; their size, shape, and relationship to one another.

The architectural model is derived from three sources:

(1) Information about the application domain for the software to

be built.

(2) Specific requirements model elements such as data flow

diagrams or analysis classes, their relationships and
collaborations for the problem at hand.

(3) The availability of architectural styles and patterns.

 Interface Design Elements
The interface design for software is analogous to a set of detailed
drawings for the doors, windows, and external utilities of a
house. These drawings depict the size and shape of doors and
windows.

The interface design elements for software depict information

flows into and out of the system and how it is communicated
among the components.

(1) The user interface.

(2) External interfaces to other systems, devices, networks, or
other producers or consumers of information.
(3) Internal interfaces between various design components.
 Component level Design
Elements
The component-level design for software is the equivalent to a
set of detailed drawings for each room in a house.

These drawings depict wiring and plumbing within each room, the
location of electrical receptacles and wall switches, sinks,
showers, tubs, drains, cabinets, and closets.

The component-level design for software fully describes the

internal detail of each software component.
Pattern Based
Software Design
 Describing Design Pattern

Software engineer should look for every opportunity to reuse

existing design patterns rather than creating new ones.

Mechanical Engineer: uses keyed shaft.

Electrical Engineer: uses integrated circuits.

Pattern characteristics indicates attributes of design.

 Using Patterns in Design
The problem description is examined at various levels of abstraction.

Architectural Patterns:
Define overall structure of software.
Indicate relationship among subsystems and software components.
Defines rules for specifying relationships among elements.

Design Patterns:
Specify aggregation of components to solve.
Relationship among components.
Component to component communication mechanism.

Idioms:
Language specific pattern implemented as algorithms.
Interface protocols.
Mechanism for communication among components.
Framework
•A framework is skeleton with collection of “plug
points”

•Plug points enable a designer to integrate problem

specific classes or functionality within skeleton.

•It is reusable mini architecture.