UNIT 3
http://meenasclassprints.blogspot.com/p/unit-4-software-engineering.html
https://slideplayer.com/slide/8569131/
Define Software Design:
 Software Design is a mechanism to transform the customer requirements as
described in the Software Requirement Specification (SRS) documents into a
form implementable using a programming language.
 It deals with representing the client's requirement, as described in SRS (Software
Requirement Specification) document, into a form, i.e., easily implementable
using programming language.
Goal of Software Design / Objective of Software Design:
The fundamental goal of software design is to structure the software product so that the
number and complexity of interconnections between modules is minimized.
List out and explain the different types activities in Software Design Phase.
Or
What are the three Levels of Software Design?
There are 3 distinct types of activities in software design:
1.External design
2.Architectural design
3.Detailed design
Architectural and detailed design are called as Internal design.
1. External design

External design involves conceiving, planning out, and specifying the externally
observable characteristics of a software product.

It includes user displays, and report formats, external data sources and data links
and the functional characteristics, performance requirements and high level process
structure for the product.
1
2. Internal design (combine activity of Architectural Design and Detailed Design)
 Internal design involves conceiving, planning out, and specifying the internal
structure and processing details of the software product.
 Internal design include a specification of architectural structure, the details of
algorithms and data structures and the test plan.
i. Architectural design
 Architectural design is concerned with the following activities:
 Refining the conceptual view of the system
 Identifying internal processing functions and decomposing high level
functions into sub functions
 Defining internal data streams and data stores
 Establishing relationships and interconnections among functions ,data
streams and data stores.
ii. Detailed design
 It concerned with the following activities:
 Specification of algorithms that implement the functions,
 Define data structures
 Actual interconnections among functions and data structures, and
 The packaging scheme for the system
2
What are the approaches used in software design?
(OR)
Discuss about Fundamental Design Concepts in Software Engineering.
Fundamental concepts of software design includes the following techniques,
1. Abstraction
2. Structure
3. Information Hiding
4. Modularity
5. Concurrency
6. Verification
7. Design Aesthetics
1. Abstraction
During software design, Abstraction allows us to organize and channel our thought and
3
processes by postponing structural considerations and detailed algorithmic
considerations.
ie. Abstraction permits separation of the conceptual aspects of a system from the
implementation details.
ie: to retain only information which is relevant
Three widely used abstract mechanisms in software design
i.
Functional abstraction
ii.
Data abstraction
iii.
Control abstraction
i. Functional abstraction
Functional abstraction is a collection of subroutines called groups. They have visible
property and hidden property. Through visible property one group communicate with
another group.
ii. Abstract data
Abstract data types are representation details of the data and manipulation details of
the data are hidden.
iii. Control abstraction
Control abstraction is used to state a desired effect without stating the exact mechanism
of control.
2. Structure
 The use of structuring permits decomposition of a large system into smaller.
 More manageable units with well-defined relationships to the other units in
the system.
 The most general form of system structure is the network.
4
 It consists of nodes and arcs.
 The nodes can represent processing elements that transform data
 The arcs can be used to represent data links between nodes.
 Alternatively, the nodes can represent data stores and the arcs data
transformation.
Figure : Structure
3. Information Hiding
 Information hiding is a fundamental design concept for software.
 Each module in the system hides the internal details of its processing activities
and modules communicate only through well-defined interfaces.
Other candidates for information hiding include:
1. A data structure and its internal linkage
2. The format of control blocks such as those for queues in an operating system
3. Character codes
4.Shifting, masking and other machine dependent details
4. Modularity
 The software is divided into various components that work together to form a
single functioning item.
 This process of creating software modules is known as Modularity in software
5
engineering.
Desirable properties of a modular system include:
1. Each processing abstraction is are well-defined subsystem that is potentially useful in
other applications.
2. Each function in each abstraction has a single, well defined purpose.
3. Each function manipulates no more than one major data structure.
4. Functions share global data selectively. It is easy to identify all routine that share a
major data structure.
5. Functions that manipulate instances of abstract data types are encapsulated with the
data structures being manipulated.
Modularity enhances design clarity, which in turn eases, implementation, debugging,
testing, documenting and maintenance of the software product.
Modularity enhance the design clarity and following activities:
 Implementation
 Debugging
 Testing
 Document
 Maintenance
5. Concurrency
 Software systems can be categorized as sequential or concurrent.
 In a sequential system only one portion of the system is active at any given time.
Concurrent systems have independent process that can be activated
simultaneously if multiple processors are available.
 Problems unique to concurrent systems include deadlock, mutual exclusion and
synchronization processes.
 Deadlock is an undesirable situation that occur when all processes in a computing
systems are waiting for other processes to complete some actions so that each
can proceed.
 Mutual exclusion is necessary to ensure that multiple processors do not attempt to
update the same components of the shared processing state at the same time
synchronization is required so that concurrent processes operating at differing
execution speeds can communicate at the appropriate points in their execution
6
histories.
 SYNCHRONIZATION: Concurrent process at different execution speed should be
synchronized.
6. Verification.
A Design is verifiable if it can be demonstrated that the design will result in an
implementation that satisfies the customer’s requirements.
1. Verification that the software requirements definition satisfies the customer’s needs
(verification of the requirements).
2. Verification that the design satisfies the requirements definition (verification of the
design).
7. Aesthetics
Aesthetic considerations are fundamental to design, whether in art or technology.
Simplicity, elegance and clarity of purpose distinguish products of outstanding quality from
mediocre products. When we speak of mathematical elegance or structural beauty, we are
speaking of those properties that go beyond more satisfaction of the requirements.
Discuss Modules and Modularization Criteria
Architectural design has the goal of producing well structured modular software systems.
A software module to be a named entity having the following characteristics.
1. modules contain instructions, processing logic and data structures
2. modules can be separately, compiled and stored in a library
3. modules can be included in a program.
4. module segments can be used by invoking a name and some parameter.
5. modules can use other modules.
Advantage of Modularization
 Modularization allows the designs to decompose a system in to functional units to
impose hierarchical ordering on function usage, to implement data abstractions,
and to develop independently useful subsystems.
7
 In addition modularization can be used to isolate machine dependencies to improve
the performance of a software product, or to ease debugging, testing, integration,
tuning and modification of the system.
MODULARIZATION CRITERIA
There are numerous criteria that can be used to guide the modularization of a system.
Modularization criteria include the conventional criterion, in which each module and its
sub-modules correspond to a processing step in the execution sequence; the information
hiding criterion, in which each module hides a difficult or changeable design decision from
the other modules; the data abstraction criterion, in which each module hides the
representation details of a major data structure behind functions that access and modify
the data structure; levels of abstraction, in which modules and collections of modules
provide a hierarchical set of increasingly complex services; coupling cohesion, in which
a system is structures to maximize the cohesion of elements in each module and to
minimize the coupling between modules; and problem modeling, in which the modular
structure of the problem modules; and problem modeling, in which the modular structure
of the system matches the structure of the problem being solved. There are two versions
of problem modeling: either the data strictures match the problem structure and the visible
functions manipulate the data structures, or the modules form a network of
communicating processes where each process corresponds to a problem entity.
OTHER MODULARIZATION CRITERIA
Additional criteria for deciding which functions to place in which modules of a software
system include:
testability
pendencies to a few routines
8
calls.
Discuss Coupling.
 Coupling is a measure the level of inter-dependability among modules.
 It tells at what level the modules interact with each other.
 The lower the coupling, the better the program.
 Two modules with high coupling are strongly interconnected and dependent on
each other.
Types of Coupling:
1. Content coupling
2. Common coupling
3. Control coupling
4. Stamp coupling
5. Data coupling
1. Content Coupling:
When a module can directly access or modify or refer to the content of another module, it
is called content level coupling.
2. Common Coupling:
When multiple modules have read and write access to some global data, it is called
common or global coupling.
3. Control Coupling:
Two modules are called control-coupled if one of them decides the function of the other
module or changes its flow of execution.
4. Stamp Coupling:
When multiple modules share common data structure and work on different part of it, it is
called stamp coupling.
5. Data Coupling:
9
Data coupling is when two modules interact with each other by means of passing data (as
parameter).
Discuss Cohesion.
 Cohesion is a measure the degree of intra-dependability within elements of a
module.
 Basically, cohesion is the internal glue that keeps the module together.
 The greater the cohesion, the better is the program design.
Types of Cohesion
1. Logical cohesion
2. Functional cohesion
3. Temporal cohesion
4. Sequential cohesion
5. Communication cohesion
6. Informational cohesion
7. Coincidental cohesion
1. Logical cohesion
When logically categorized elements are put together into a module, it is called logical
cohesion.
2. 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 welldefined function. It can also be reused.
3. Temporal cohesion
When elements of module are organized such that they are processed at a similar point in
time, it is called temporal cohesion.
10
4. Sequential cohesion
When elements of module are grouped because the output of one element serves as input
to another and so on, it is called sequential cohesion.
5. Communication cohesion
When elements of module are grouped together, which are executed sequentially and
work on same data (information), it is called communicational cohesion.
6. Informational cohesion
Elements in a module occur when the module contains a complex data structure and
several routines to manipulate the data structure
7. Coincidental cohesion
It is unplanned and random cohesion, which might be the result of breaking the program
into smaller modules for the sake of modularization. Because it is unplanned, it may serve
confusion to the programmers and is generally not-accepted.
Discuss about Design Notation.
Or
What are the notations used to specify external characteristics of a software?.
Notation used to specify the external characteristic, architectural structure and processing
details of a software system.
Good notation can clarify the interrelationships and
interaction of interest.
1. Dataflow diagram
2. Structure charts
3. HIPO diagrams
4. Procedure specification
5. Pseudo code
6. Structured flow charts
11
DATA-FLOW DIAGRAMS
o Data flow diagram is graphical representation of flow of data in an
information system.
o It is capable of showing incoming data flow, outgoing data flow and stored
data ie. Dataflow diagrams are Graphs in which the nodes specify
processing activities and the arcs specify the data items transmitted between
processing nodes.
Figure : Data Flow Diagram
2. STRUCTURED CHARTS
 Structure chart is a chart derived from Data Flow Diagram.
 It represents the system in more detail than DFD.
 It breaks down the entire system into lowest functional modules, describes functions
and sub-functions of each module of the system to a greater detail than DFD.
12
HIPO DIAGRAMS
 HIPO diagram(Hierarchy-process-input-output) were developed at IBM as design
representation schemes for top down software development.
 HIPO diagram represents the hierarchy of modules in the software system.
 Analyst uses HIPO diagram in order to obtain high-level view of system functions.
 It decomposes functions into sub-functions in a hierarchical manner. It depicts the
functions performed by system.
 HIPO diagrams are good for documentation purpose.
PROCEDURE TEMPLATE
It provides initial architectural design , specification of side effects , exception handling ,
processing algorithms and data representation.
PSEUDO CODE NOTATION
Pseudo code notation can be used in both the architectural and detailed design phases.
• The designer describes system characteristics using short , concise , that are
structured by keywords such as If-Then- Else , While-Do and End.
13
• Pseudo code can replace flowcharts and reduce the amount of external
documentations required to describe system.
STRUCTURED FLOWCHARTS
• Flowcharts means are specifying and documenting algorithmic detailed in a software
system.
• Flowchart interoperate rectangular boxes for actions , diamond shaped boxes for
decisions , directed arcs for interconnections for boxes.
• Single entry , single exit allows hierarchical nesting of structured flowchart to design in
top-down fashion.
Figure : Structured Flow Charts
DECISION TABLES
• Decision tables can be used to specify complex decision logic in a high level software
specification.
• There are useful for specifying algorithmic logic during detailed design.
14
Explain various Design Techniques in Software Engineering.
 The design process involves developing a conceptual view of the system,
establishing system structure ,identifying data streams and data stores,
decomposing high-level function into sun functions, establishing relationships and
interconnections among components, developing concrete data representations,
and specifying algorithm details.
 Design techniques are typically based on the “Top Down Approach” and/or “Bottom-up
Approach” Design strategies.
Top down Approach
 Using the top-down approach, attention is first focused on global aspects of the overall
system.
 As the design progresses, the system is decomposed into subsystems and more
consideration is given to specific issues.
 Backtracking is fundamental to top-down design.
 In top down approach, a high – level decision may have to be reconsidered and the
system restructured accordingly.
 The disadvantage of top-down design and implementation permits early demonstration of
functional capabilities at the user level; dummy routines (program stubs) can be used to
simulate the lower, unimplemented levels of the system.
 The primary advantage of the top-down strategy is that attention is first directed to the
customer's needs, user interfaces, and the overall nature of the problem being solved.
Bottom up Approach
 In the bottom-up approach software design, the Designer first attempts to identify a set of
primitive objects, actions, and relationships that will provide a basis for problem solution.
 Higher-level concepts are than formulated in terms of the primitives.
 The bottom-up strategy requires the designer to combine features provided by the
implementation language into more sophisticated entities.
 Bottom-up design may also require redesign and design backtracking. The success of
bottom-up design depends on identifying the “proper” set of primitive ideas sufficient to
implement the system.
15
 The primary advantage bottom-up design and implementation permits assessment of
subsystem performance during system evolution.
 When using top-down methods, performance evaluation must be deferred until the entire
system is assembled.
Types of Design Techniques:
1. Stepwise refinement
2. Levels of abstraction
3. Structure design
4. Integrated top- down development
5. Jackson design methods
1. STEPWISE REFINEMENT:
Stepwise refinement is a top-down technique for decomposing a system from high –level
specification in to more elementary levels.
Stepwise refinement is also know as “stepwise program development ” and “Successive
refinement”.
Stepwise refinement involves the following activities:
i.
Decomposing design decisions to elementary levels.
ii.
Isolating design aspects that are not truly interdependent.
iii.
Posting decision concerning representation details as long as possible.
iv.
Carefully demonstrating that each successive step in the refinement is a faithful
expansion of previous steps.
The major benefits of stepwise refinement as a design techniques are:
1.Top-down decomposition
2.Incremental addition of detail
3.Postponement of design decision
4.Continual verification of consistency(formally or informally)
16
Successive refinement can be used to preform details design of the individual modules in
a software product.
LEVELS OF ABSTRACTION:
 Levels of abstraction was originally described as a bottom-up design technique in
which an a layering of hierarchical levels staring at level 0(processor allocation,
real-time clock interrupts)and building up to the level of processing independent
user program.
 Each level of abstraction perform a set of services for the functions on the next high
level of the abstraction.
 Thus, a file manipulation system might be layered as a set of routine to manipulate
fields(bit vectors on level of 0),a set of routine manipulate records(sets of fields on
level 1) and a set routine to manipulate files(sets of records on the level 2).
 Each levels of abstraction has exclusive use of certain resources(I/O devices data
structures)that other level a are not permitted to access. Higher level function
cannot invoke functions on lower levels, but lower level functions cannot invoke or
in any way make use of higher-level function.
STRUCTURE DESIGN:
 Structure design was developed by Constantine as a topdown techniques for
architectural design of software system.
 The basic approach in structure design systematic conversion of the data flow
diagrams into structure charts.
 Coupling measures the degree to which two distinct modules are bound together,
and cohesion is a measure of the relationship of the element with in a module to
one another.
17
1. A well-designed system exhibits a lows degree of coupling between modules and
a high degree of cohesion among each module.
2. The first step in structured design is review and refinement of the data flow
diagram(s) developed during requirements definition and external design.
3. The second step is to determine whether the system is transform-centered or
transaction-driven, and to derive a high – level structure chart based on this
determination.
4. In a transform-centered system, the data flow diagram contains Input,
Processing, and Output segments that are converted into Input, Processing, and
Output subsystems in the structure chart.
5. Boundaries between the three major subsystems in a transform – centered
system are identified by determining the point of most abstract input data and
the point of most abstract output data on the data flow diagram.
Integrated top- down development:
 Using integrated top-down development, design proceeds top-down from the
highest-level routines.
 They have the primary function of coordinating and sequencing the lower level
routines.
 There is a hierarchical structure to a top-down system in which routines can invoke
lower-level routines but cannot invoke routines on a higher level.
Jackson design methods:
In Jackson design technique, the mapping is accomplished in three steps:
1.The problem is modeled by specifying the input and output data structure using tree
structured diagrams.
2.Input-output model is converted in to a structural model for the program by identifying
points of correspondence between nodes in the input and output trees.
18
3.The structural model of the program is expanded into a detailed design model that
contains the operations needed to solve the problem.
DETAILED DESIGN CONSIDERATION:
 Detailed design is concerned with specifying algorithmic details, concrete data
representation, interconnection among function and data structures, and packaging
of the software product.
 Detailed design is strongly influenced by the implementation language, and it is not
the same as implementation.
 Detailed design is more concerned with semantic issues and less concerned with
syntactic details then is implementation.
 Detailed design also provides a vehicle for design inspection, structured
walkthroughs, and the critical design review.
 Product package is an important aspect of detailed design. Packaging is concerned
with the manner in which global data items are selectively shared among program
units.
Real Time and Distributed System
Real Time System
 By definition, real-time systems must provide specified amounts of computation
with in fixed time intervals.
19
 Real-time systems typically sense and control external devices, respond to external
events, and share processing time between multiple tasks processing demands are
both cyclic and event-driven in nature.
 The traditional considerations hierarchy, information hiding and modularity are
important concepts for the design of real-time systems.
 However these concepts are typically applied to the individual components of a
real-time systems.
 Higher-level issues of networking, performance and reliability must be analyzed and
designed before the component nodes or processes are developed.
Distributed System
According to Franta, a distributed system consists of a collection of nearly autonomous
processors that communicate to achieve a coherent computing system.
Each processor possesses a private memory, and processors communicate through an
interconnection network.
Major issues to be addressed in designing a distributed system includes:
 Specifying the topology of the communication network
 Establishing rules for accessing the shared communication channel
 Establishing rules for process communication and synchronization.
 The design of distributed systems is further complicated by the need to allocate
network functionality between hardware and software components of the network.
DISCUSS TEST PLANS.
Test Plan prescribes various kinds of activities that will be performed to demonstrate that
the software product meets its requirements.
20
The Test Plan specifies the following:
 The objectives of testing e.g., to achieve error-free operation under stated
conditions for a stated period of time.
 The test completion criteria to achieve a specified rate of error exposure, to achieve
a specified percent of logical path coverage.
 The system integration plan (strategy, schedule, responsible individuals),
 The particular test cases to be used.
There are four types of tests that software products must satisfy:
1. Functional Tests
2. Performance Tests
3. Stress Tests
4. Structural Tests
These tests are based on the requirements specifications; they are designed to
demonstrate that the system satisfies the requirements, which in turn must be phased in,
quantified, testable terms.
1. Functional Test
It specifies typical operating conditions ,typical input values , and typical expected results
. Functional test should also be designed to test boundary conditions just inside and just
beyond the boundaries(eg., square root of negative numbers ,inversions of one-by-one
matrices). Also, initial values and system default should be tested with data that have both
correct and incorrect ordering.
2. Performance test
It Designed to verify response time(under various loads) ,executive time ,throughput
,primary and secondary memory utilization ,and traffic rates on data channels and
21
communications links. Performance test will often indicate processing bottlenecks to be
addressed during system testing and turning.
3. Stress test
It is Designed to overload a system in various ways, such as attempting to sign on more
than the maximum allowed number of terminals, processing more than the allowed number
of identifiers or static levels or disconnecting a communication link. The purpose of this
testing are to determine the limitation of the system and when the system fails, to
determine the manner in which the failure is manifest. This test provides a valuable insight
concerning the strength and weakness of a system.
4. Structural Test
The goal of structural testing is to traverse a specified number of paths through in the
system to establish thoroughness of testing.
DISCUSS DESIGN GUIDELINES
Design is a creative process that can be guided and directed, but it can never be reduced
to an algorithmic procedure.
The following guidelines do not constitute a “design methodology,” but rather provide some
guidance for organizing the activities of software design.
1. Review the requirements specification. In particular, study the desired functional
characteristics and performance attributes of the system.
2. Review and expand the external interfaces, user dialogues, and report formats
developed during requirements analysis.
3. Review and refine the data flow diagrams developed during requirements analysis and
external design. Identify internal data stores and elaborate the processing functions.
4. Identify functional abstractions and data abstractions. Record them using a design
notation.
22
5. Define the visible interfaces for each functional abstraction and each data abstraction.
Record them using a design notation.
6. Define the modularization criteria to be used in establishing system structure.
7. Apply the techniques of your particular design method to establish system structure. For
example, derive the input and output data structures and convert the data structures into
a processing structure that maximizes information hiding, or a structure that enhances the
overlay capabilities or real-time response rate, etc.
8. Verify that the resulting system structure satisfies the requirements.
9. Develop interface specifications for the procedures in each module.
10. Conduct the preliminary design review. The level of detail should be inclusive to levels
1 and 2 of the procedure templates.
11. Develop concrete data representations for the data stores and data abstractions.
12. Expand the procedure templates to include the information in level 3.
13. Specify algorithmic details for the body of each procedure in the system, using
successive refinement, HIPO diagrams, pseudo code, structured English, and/or
structured flowcharts.
Develop concrete data structures and algorithms.
14. Conduct the critical design review.
15. Redesign as necessary
The major difficulties in software design are caused by inadequate requirements, failure
to consider alternative design strategies and the temptation to provide too much detail too
soon. The use of systematic design notations will greatly enhance your thoughts
processes and improve you ability to think about, communicate and verify the design
23