SOFTWARE ENGINEERING

UNIT – IV
SOFTWARE DESIGN

 DESIGN CONCEPTS
● Software design is a process to transform user requirements into some suitable form,
which helps the programmer in software coding and implementation.

● A software design is a description of the architecture of the software to be

implemented, the data which is part of the system, the interfaces between system
components and, sometimes, the algorithms used. The design process activities are
the followings:

1) Architectural design: The sub-systems of system and their relationships are

identified based on the main functional requirements of software.

2) Abstract specification: For each sub-system, an abstract specification of its

services and the constraints under which it must operate is defined.

3) Interface design: Interfaces allow the sub-system’ services to be used by other sub-
systems. The representation of interface should be hidden. In this activity the interface
is designed and documented for each sub-system. The specification of interface must
be unambiguous.

4) Component design: Services are allocated to components and the interfaces of

these components are designed.

5) Data structure design: The data structures used in the system implementation are
designed in detail and specified.

Software Quality Guidelines and Attributes

 Design Guidelines
• A good design should exhibit good architectural structure, be modular.

• contain distinct representations of data, architecture, interfaces, and components.

1
• lead to data structures that are appropriate for the objects to be implemented and
be drawn from recognizable design patterns.

• lead to components that exhibit independent functional characteristics.

• lead to interfaces that reduce the complexity of connections between modules and
with the external environment.

• be derived using a reputable method that is driven by information obtained during

software requirements analysis.

Quality Guidelines

1) Created using recognizable architectural styles or patterns,

2) Composed of components that exhibit good design characteristics,

3) A design should be modular; that is, the software should be logically partitioned
into elements or subsystems.

4) A design should lead to components that exhibit independent functional

characteristics.

5) A design should be derived using a repeatable method that is driven by information

obtained during software requirements analysis.

6) A design should be represented using a notation that effectively communicates its

meaning.

Objectives of Software Design

 Correctness: Software design should be correct as per requirement.

 Completeness: The design should have all components like data structures,
modules, and external interfaces, etc.
 Efficiency: Resources should be used efficiently by the program.
 Flexibility: Able to modify on changing needs.
 Consistency: There should not be any inconsistency in the design.
 Maintainability: The design should be so simple so that it can be easily
maintainable by other designers.

2
 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.

Generic Procedure: Start with a high-level description of what the software / program
does. Refine each part of the description one by one by specifying in greater details the
functionality of each part. These points lead to Top-Down Structure.

Problem in Top-Down design method:

Mostly each module is used by at most one other module and that module is called
its Parent module.

Solution to the problem:

Designing of reusable module. It means modules use several modules to do their
required functions.

3
 Function Oriented Design Strategies:

Structure Charts

● A Structure Chart in software engineering is a chart which shows the breakdown of

a system to its lowest manageable parts. They are used in structured programming to
arrange program modules into a tree.

● Each module is represented by a box, which contains the module's name. The tree
structure visualizes the relationships between modules, showing data transfer
between modules using arrows.

● The tree shows the relationship between modules, showing data transfer between
the models. A structure chart is a nice representation for a design that uses functional
abstraction.

● 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.

● Structure chart represents hierarchical structure of modules. At each layer a specific

task is performed. Structured Chart is a graphical representation which shows:

 System partitions into modules

 Hierarchy of component modules
 The relation between processing modules
 Interaction between modules
 Information passed between modules

The following notations are used in structured chart:

4
 OBJECT-ORIENTED DESIGN
● Object–Oriented Design Object-oriented design includes two main stages, namely,
system design and object design.

● System Design In this stage, the complete architecture of the desired system is
designed. The system is conceived as a set of interacting subsystems that in turn is
composed of a hierarchy of interacting objects, grouped into classes.

● System design is done according to both the system analysis model and the proposed
system architecture. Here, the emphasis is on the objects comprising the system rather
than the processes in the system.

1) Classes and Objects

Object

● An object is a real-world element in an object–oriented environment that may have

a physical or a conceptual existence.

Jacobson has defined an object as:

● “An instance is an object created from a class. The class describes the (behaviour and
information) structure of the instance, while the current state of the instance is defined
by the operations performed on the instance.”

● An object may have a physical existence, like a customer, a car, etc.

Class

● A class represents a collection of objects having same characteristic properties that

exhibit common behavior.

Jacobson has defined a class as:

● “A class represents a template for several objects and describes how these objects are
structured internally. Objects of the same class have the same definition both for their
operations and for their information structures.”

2) Inheritance

OOD allows similar classes to stack up in a hierarchical manner where the lower or
sub-classes can import, implement, and re-use allowed variables and functions from
their immediate super classes. This property of OOD is called an inheritance. This

5
makes it easier to define a specific class and to create generalized classes from specific
ones.

3) Polymorphism

Polymorphism means many forms. OOD languages provide a mechanism where

methods performing similar tasks but vary in arguments, can be assigned the same
name. This is known as polymorphism.
The same message is sent to different objects irrespective of their class, but the
responses of objects may be different. When we abstract the interface of an operation
and leave the implementation details to sub-classes, this activity is called
polymorphism. This operation is called polymorphic operation.

4) Encapsulation

Encapsulation is also known as information hiding concept. It is a way in which both

data and functions (or operations) that operate on data are combined into a single unit.
The only way to access the data is through functions, which operate on the data. The
data is hidden from the external world. Hence, it is safe from outside (external) and
accidental modifications.

5) Messages, Methods, Responsibility, Abstraction

● A message is a request for performing an operation by some object in the system. A
message may consist of the identification of the target object, name of the requested
operation and other relevant information for processing the request.
● A ‘method’ is the sequence of steps (or set of operations) to be performed to fulfil the
assigned task. There may be many methods available for any task.
● It is the responsibility of the receiver of the message to choose an appropriate method
to complete a task effectively and efficiently.
● Responsibility is an important concept of an object-oriented system. Behaviour of an
object is described in terms of responsibilities. This improves the independence amongst
the objects which is very important for solving any complex problem.
● The complexity of a problem is managed using the right level of abstraction which is
the elimination of the irrelevant and the amplification of the essentials. abstraction
concept provides independence and improves the clarity of the system.

6
 DETAILED DESIGN
● Detailed design deals with the implementation part of what is seen as a system and
its sub-systems in the previous two designs. It is more detailed towards modules and
their implementations.
● It defines logical structure of each module and their interfaces to communicate with
other modules, developing the detailed design is useful for the more complex and
important modules, and is often done informally by the programmer as part of the
personal process of developing code.

 Once high-level design is done, you have-

 a graphical representation of the structure of your software system.
 a document that defines high-level details of each module in your system
including-
 a module’s interface (including input and output data types)
 notes on possible algorithms or data structures the module can use to meet its
responsibilities
 a list of any non-functional requirements that might impact the module

 After high-level design, a designer’s focus shifts to low-level design

 Each module’s responsibilities should be specified as precisely as possible
 Constraints on the use of its interface should be specified
 pre and post conditions can be identified
 module-wide invariants can be specified
 internal data structures and algorithms can be suggested

A) Logic/Algorithm Design
A procedure is a finite sequence of well-defined steps or operations, each of which
requires a finite amount of memory and time to complete.

steps that one has to perform while developing an algorithm-

1) statement of the problem

The starting step in the design of algorithms is statement of the problem. The problem
for which an algorithm is being devised has to be precisely and clearly stated and
properly understood by the person responsible for designing the algorithm.

7
 2) development of a mathematical model
● In modeling, one has to select the mathematical structures that are best suited for the
problem. It can help to look at other similar problems that have been solved.
● In most cases, models are constructed by taking models of similar problems and
modifying the model to suit the current problem.

3) design of the algorithm

During this step the data structure and program structure are decided. Once the
algorithm is designed, its correctness should be verified.

B) stepwise refinement technique

● The most common method for designing algorithms or the logic for a module is to use
the stepwise refinement technique.
● The stepwise refinement technique breaks the logic design problem into a series of
steps, so that the development can be done gradually.
● The process starts by converting the specifications of the module into an abstract
description of an algorithm containing a few abstract statements. In each step, one or
several statements in the algorithm developed so far are decomposed into more detailed
instructions.

 VERIFICATION
Verification can mean the:
act of reviewing, inspecting, testing, checking, auditing, or otherwise establishing and
documenting whether items, processes, services or documents conform to specified
requirements.
 Verification does not involve code execution, while Validation involves code execution.
 Verification checks whether the software confirms a specification.
 Verification finds the bugs early in the development cycle.
 the Verification process targets software architecture, design, database, etc.
Verification is done by the QA team.

Features of Software Verification

• Performed during the early stages of the software development process to determine
for the specific requirements.
• Verification denotes precision of the end or final product.

8
• It conducts software review, walk through, inspection, and evaluate documents.

Methods of Verification
• Static Verification: Static verification involves inspection of the code.
• Dynamic Verification: It concerns with the working behaviour of the software.

Coverage in Verification
• Statement Coverage: Code includes many statements. Code is verified.
• Path Coverage: Sequence of control flow from entry to exit.
• Decision Coverage: When and application is executed, it may have to make decisions
based upon the situation it faces.
Verification activities may include carrying out formal proofs. The activities to be
conducted in a project are described in the Software Verification and Validation Plan
(SVVP).

9
 Software Metrics

A software metric is a measure of software characteristics which are measurable or countable. Software
metrics are valuable for many reasons, including measuring software performance, planning work
items, measuring productivity, and many other uses.

Within the software development process, many metrics are that are all connected. Software metrics are
similar to the four functions of management: Planning, Organization, Control, or Improvement.

Classification of Software Metrics

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software product. The
two important software characteristics are:

 Size and complexity of software.

 Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

2. Process Metrics: These are the measures of various characteristics of the software development
process. For example, the efficiency of fault detection. They are used to measure the characteristics
of methods, techniques, and tools that are used for developing software.

1
0
Types of Metrics

Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed
to be of greater importance to a software developer. For example, Lines of Code (LOC) measure.

External metrics: External metrics are the metrics used for measuring properties that are viewed
to be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.

Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource
metrics. For example, cost per FP where FP stands for Function Point Metric.

Project metrics: Project metrics are the metrics used by the project manager to check the project's
progress. Data from the past projects are used to collect various metrics, like time and cost; these
estimates are used as a base of new software. Note that as the project proceeds, the project
manager will check its progress from time-to-time and will compare the effort, cost, and time with
the original effort, cost and time. Also understand that these metrics are used to decrease the
development costs, time efforts and risks. The project quality can also be improved. As quality
improves, the number of errors and time, as well as cost required, is also reduced.

Advantage of Software Metrics

Comparative study of various design methodology of software systems.

1
1
For analysis, comparison, and critical study of different programming language concerning their
characteristics.

In comparing and evaluating the capabilities and productivity of people involved in software
development.

In the preparation of software quality specifications.

In the verification of compliance of software systems requirements and specifications.

In making inference about the effort to be put in the design and development of the software
systems.

In getting an idea about the complexity of the code.

In taking decisions regarding further division of a complex module is to be done or not.

In guiding resource manager for their proper utilization.

In comparison and making design trade offs between software development and maintenance cost

In providing feedback to software managers about the progress and quality during various phases
of the software development life cycle.

In the allocation of testing resources for testing the code.

Disadvantage of Software Metrics

The application of software metrics is not always easy, and in some cases, it is difficult and costly.

The verification and justification of software metrics are based on historical/empirical data whose
validity is difficult to verify.

These are useful for managing software products but not for evaluating the performance of the
technical staff.

The definition and derivation of Software metrics are usually based on assuming which are not
standardized and may depend upon tools available and working environment.

Most of the predictive models rely on estimates of certain variables which are often not known
precisely.

1
2