Unit-3: Software Design

3.1Software design
• Design is the highly significant phase in the software development where the
designer plans “how” a software system should be produced in order to make it
functional, reliable and reasonably easy to understand, modify and maintain.
• SRS tell us what a system does and becomes input to design process, which tells us
“how” a software system works.
• Software design involves identifying the component of software design, their inner
workings, and their interface from the SRS. The principle work of this activity is
the software design document (SDD) which is also referred as software design
description
• Software design deals with transforming the customer requirements, as described in
the SRS document, into a form (a set of documents) called software design
document that is suitable for implementation in a programming language.

Difference between Conceptual and Technical design

• Conceptual design describe the system in language understandable to the customer.
it does not contain any technical jargons and is independent of implementation
• By contrast the technical design describe the hardware configuration, software
needs, communication interface, input and output of system, network architecture
that translate the requirement in to the solution to the customer's problem

28
Characteristics and objectives of a good software design
Good design is the key of successful product.
• Correctness: A good design should correctly implement all the functionalities
identified in the SRS document.
• Understandability: A good design is easily understandable.
• Efficiency: It should be efficient.
• Maintainability: It should be easily amenable to change.

Features of a design document

• It should use consistent and meaningful names for various design components.
• The design should be modular. The term modularity means that it should use a
cleanly decomposed set of modules.
• It should neatly arrange the modules in a hierarchy, e.g. in a tree-like diagram.

Software Design process

• Architectural Design (Top Level design):- Describe how software is decomposed
and organized into components
• Detailed Design (Low level design):-describe the specific behavior of these
components. The output of this process is a set of models that records the major
decision that has been taken.

3.2 Software Design principle

Abstraction
It is a tool that permits a designer to consider a component at abstract level; without
worrying about the detail of the implementation of the component.
Encapsulation/Information hiding
the concept of information hiding is to hide the implementation details of shared
information and processing items by specifying modules called information hiding
modules. Design decisions that are likely to change in the future should be identified and
modules should be designed in such a way that those design decisions are hidden from
other modules
Coupling and cohesion
Cohesion
It is a measure of the degree to which the elements of a module are functionally related.
Cohesion is weak if elements are bundled simply because the perform similar or related
functions. Cohesion is weak if elements are bundled simply because they perform similar

29
or related functions . Cohesion is strong if al parts are needed for the functioning of other
parts (e..Important design objective is to maximize module cohesion and minimize module
coupling.
Coupling
It is the measure of the degree of interdependence between modules. Coupling is highly
between components if they depend heavily on one another, (e.g., there is a lot of
communication between them).
Decomposition and modularization
Decomposition and modularization large software in to small independent once, usually
with the goal of placing different functionality or responsibility in different component

Design Complexity
Complexity is another design criteria used in the process of decomposition and refinement.
A module should be simple enough to be regarded as a single unit for purposes of
verification and modification
a measure of complexity for a given module is proportional to the number of other
modules calling this module (termed as fan-in), and the number of modules called by the
given module (termed as fan-out).
Top-down approach (is also known as step-wise design) is essentially the breaking down
of a system to gain insight into its compositional sub-systems. In a top-down approach an
overview of the system is formulated, specifying but not detailing any first-level
subsystems. Each subsystem is then refined in yet greater detail, sometimes in many
additional subsystem levels, until the entire specification is reduced to base elements. A
top-down model is often specified with the assistance of "black boxes", these make it
easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms
or be detailed enough to realistically validate the model.
Bottom-up approach is the piecing together of systems to give rise to grander systems,
thus making the original systems sub-systems of the emergent system. In a bottom-up
approach the individual base elements of the system are first specified in great detail.
These elements are then linked together to form larger subsystems, which then in turn are
linked, sometimes in many levels, until a complete top-level system is formed. This
strategy often resembles a "seed" model, whereby the beginnings are small but eventually
grow in complexity and completeness. However, "organic strategies" may result in a tangle
of elements and subsystems, developed in isolation and subject to local optimization as
opposed to meeting a global purpose. Mechanisms or be detailed enough to realistically
validate the model.

3.3 Architectural design

• Architectural design represents the structure of data and program components that
are required to build a computer-based system.
• It considers the architectural style that the system will take, the structure and
properties of the components that constitute the system, and the interrelationships
that occur among all architectural components of a system.
• Architectural design begins with data design and then proceeds to the derivation of
one or more representations of the architectural structure of the system.

30
 • Alternative architectural styles or patterns are analyzed to derive the structure that
is best suited to customer requirements and quality attributes.
• Once an alternative has been selected, the architecture is elaborated using an
architectural design method.

Types of Architectural design

Object-oriented architectures: - The components of a system encapsulate data and the
operations that must be applied to manipulate the data. Communication and coordination
between components is accomplished via message passing.

Layered architectures

Data-centered architectures: - 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. In
some cases the data repository is passive. That is, client software accesses the data
independent of any changes to the data or the actions of other client software. A variation
on this approach transforms the repository into a “blackboard” that sends notifications to
client software when data of interest to the client change.

31
3.4 Coupling and cohesion Measures
Coupling: - It is the measure of the degree of interdependence between modules. Coupling
is highly between components if they depend heavily on one another, (e.g., there is a lot of
communication between them).
Types of Coupling:-
1. Data coupling: communication between modules is accomplished through well-defined
parameter lists consisting of data information items
2. Stamp coupling: Stamp coupling occurs between module A and B when complete data
structure is passed from one module to another.
3. Control coupling: a module controls the flow of control or the logic of another module.
This is accomplished by passing control information items as arguments in the argument
list.
4. Common coupling: modules share common or global data or file structures. This is the
strongest form of coupling both modules depend on the details of the common structure
5. Content coupling: A module is allowed to access or modify the contents of another,
e.g. modify its local or private data items. This the strongest form of coupling
Cohesion :- It is a measure of the degree to which the elements of a module are
functionally related. Cohesion is weak if elements are bundled simply because the perform
similar or related functions. Cohesion is weak if elements are bundled simply because they
perform similar or related functions. Cohesion is strong if al parts are needed for the
functioning of other parts (e..Important design objective is to maximize module cohesion
and minimize module coupling.
Types of Cohesion:-
1.Functional cohesion: A and B are part of a single functional task. This is very good
reason for them to be contained in the same procedure or achieved when the components
of a module cooperate in performing exactly one function, e.g., POLL_SENSORS,
GENERATE_ALARM, etc.
2.Sequential Cohesion: Module A outputs some data which forms the input to B. This is
the reason for them to be contained in the same procedure.
3.Communicational cohesion: is achieved when software units or components of a
module sharing a common information or data structure are grouped in one module

32
4.Procedural cohesion: is the form of cohesion obtained when software components are
grouped in a module to perform a series of functions following a certain procedure
specified by the application requirements
5. Temporal cohesion: Module exhibits temporal cohesion when it contains tasks that are
related by the fact that all tasks must be executed in the same time-span. Examples are
functions required to be activated for a particular input event, or during the same state of
operation
6.Logical cohesion: refers to modules designed using functions who are logically related,
such as input/output functions, communication type functions (such as send and receive),
7.Coincidental cohesion: Coincidental cohesion exists in modules that contain
instructions that have little or no relationship to one another.

3.5 Function oriented design

Function Oriented design is an approach to software design where the design is
decomposed into a set of interacting units where each unit has a clearly defined function.
Thus, system is designed from a functional view point.
Design Notations of function oriented design
Design notations are largely meant to be used during the process of design and are used to
represent design or design decisions. For a function oriented design, the design can be
represented graphically or mathematically by the following:
• Data flow diagrams
• Data Dictionaries
• Structure Charts: - function-oriented design, the design can be represented
graphically by structure charts. Structure of a program is made up of the modules of
that program together with the interconnections between modules. structure chart of
a program is a graphic representation of its structure. In a structure chart a module
is represented by a box with the module name written in the box. An arrow from
module A to module B represents that module A invokes module B. B is called the
subordinate of A, and A is called the superordinate of B.

• Pseudocode: - Is a tool for planning or documenting the content of the program

routine or module as name implies is same as real code. Pseudocode notation can

33
 be used in both the preliminary and detailed design phases. Using pseudocode, the
designer describes system characteristics using short, concise, English language
phrases that are structured by key words such as It-Then-Else, While-Do, and End.
Example:-
COUNT=0
STOCK=STOCK+QUANTITY
OR
READ THE DATA FROM SOURCE
WRITETHE DATA TO DESTINATION

3.6 Object Oriented Design

• The object-oriented design approach is fundamentally different from the function-
oriented design approaches primarily due to the different abstraction that is used.
• It requires a different way of thinking and partitioning. It can be said that thinking
in object-oriented terms is most important for producing truly object-oriented
designs.
• Object oriented design is the result of focusing attention not on the function
performed by the program, but instead on the data that are to do manipulate by the
program. Thus, it is orthogonal to function oriented design.
• Object Oriented Design begins with an examination of the real world “things” that
are part of the problem to be solved. These things (which we will call objects) are
characterized individually in terms of their attributes and behavior.
• Object Oriented Design is not dependent on any specific implementation language.
Problems are modeled using objects.
Objects have:
• Behavior (they do things)
• State (which changes when they do things)
3.7 Software measurement and metric
• Pressman explained as “A measure provides a quantitative indication of the extent,
amount, dimension, capacity, or size of some attribute of the product or process”.
• Fenton defined measurement as “ it is the process by which numbers or symbols are
assigned to attributes of entities in the real world in such a way as to describe them
according to clearly defined rules”.
• Measurement is the act of determine a measure
Software metrics
• Pressman explained as “ The metric is a quantitative measure of the degree to which
a system, component, or process possesses a given attribute”.
• Software metrics can be defined as “The continuous application of measurement
based techniques to the software development process and its products to supply
meaningful and timely management information, together with the use of those
techniques to improve that process and its products.

34
Categories of Metrics
i. Product metrics: describe the characteristics of the product such as size,
complexity, design features, performance, efficiency, reliability, portability,
etc.
ii. Process metrics: describe the effectiveness and quality of the processes that
produce the software product. Examples are:
• effort required in the process
• time to produce the product
• effectiveness of defect removal during development
• number of defects found during testing
• maturity of the process
iii. Project metrics: describe the project characteristics and execution.
Examples are:-
• number of software developers
• staffing pattern over the life cycle of the software
• cost and schedule
• productivity

3.7.1 Halstead’s Software science

• Halstead has proposed metrics for length and volume of a program based of the
number of operation and operands.
• Tokens are classified as either operators or operands all software science measures
are function of the count of these tokens
• Any symbol or keyboard in a program that specify an algorithmic action is
considered an operator ,while a symbol used to represent the data is considered an
operand.
• Variable, constants and even labels are operands
• Operators consists of arithmetic symbols such as +,-,/,*and command names such as
while ,for, printf, special character such as :=,braces, parentheses etc.
• In a program we define following measurable quantities
N = N1+N2
N : program length
where
N1 : total occurrences of operators
N2 : total occurrences of operands

Volume
• The unit of measurement of volume is the common unit for size “bits”. It is the actual
size of a program if uniform binary encoding for the vocabulary is used.
V= N* log2 ή
Program Level
• The value of L ranges between zero and one, with L=1 representing a program
written at the highest possible level (i.e., with minimum size) and v is the potential
volume

35
 L=V*/V
Estimated program Length

Ñ= ή1log2 ή2+ ή2log2 ή2

3.7.2 Function points Analysis
• Alan Albrecht while working for IBM, recognized the problem in size measurement
in the 1970s, and developed a technique (which he called Function Point Analysis),
which appeared to be a solution to the size measurement problem.
• It measure functionality from user point of view i.e on the basis of what the user
request and receive in return.
• Therefore it deals with the functionality being delivered , and not with LOC, source
code, files etc.
• Measuring size in this way has the advantage that size measure is independent of the
technology used to deliver the function

• Advantages
– Users point of view: what user requests & receives from the system
– Independent of tech.,lang,tool,methods

36
 – Can be estimated from SRS or Design specification Doc.
– Since directly from first phase doc. So easy re-estimation on expansion or
modification.
• Disadvantages
– Difficult to estimate
– Experienced based/subjective

3.8 Coding styles- Coding guidelines provide only general suggestions regarding the
coding style to be followed.
1) Do not use a coding style that is too clever or too difficult to understand- Code
should be easy to understand. Clever coding can obscure meaning of the code and
hamper understanding. It also makes maintenance difficult.
2) Avoid obscure side effects- The side effects of a function call include modification
of parameters passed by reference, modification of global variables, and I/O
operations. An obscure side effect is one that is not obvious from a casual
examination of the code. Obscure side effects make it difficult to understand a
piece of code.
3) Does not use an identifier for multiple purposes- Programmers often use the
same identifier to denote several temporary entities? There are several things which
are wrong with this approach and hence should be avoided. Some of the problems
caused by use of variables for multiple purposes are as follows:
Ø Each variable should be given a descriptive name indicating its purpose.
This is not possible if an identifier is used for multiple purposes. Use of a
variable for multiple purposes can lead to confusion and make it difficult to
read and understand the code.
Ø Use of variables for multiple purposes usually makes future enhancements
more difficult.
4) The code should be well-documented- As a rule of thumb, there must be at least
one comment line on the average for every three source lines.
5) Do not use goto statements- Use of goto statements makes a program unstructured
and very difficult to understand.

37