Software Engineering unit 3

SOFTWARE ENGINEERING
UNIT-3
ABHIMANYU MISHRA
ASSISTANT PROF.(CSE)
JETGI
24/12/16 1Abhimanyu Mishra(CSE) JETGI

 Basic concept of software design.
 Architectural design.
 Low level designs.
 Design strategies.
 Software Measurement and Metrics.
 Function point based measure.
 Cyclomatic complexity Measure.
 Control flow diagram.
CONTENTS

Basic design principles that enable the software engineering to navigate the design
process suggest a set of principles for software design, which have been adapted and
extended in following list:-
 Free from the suffer from “tunnel vision”.
 The design should be traceable to the analysis model.
 The design should not repeat the same thing.
 The design should “minimize the intellectual distance” between the software and
the problem as it exists in real world.
 The design should exhibit uniformly and integration.
 The design should be accessed for quality as it is being created.
 The design should be able to handle all unusual circumstances.
 Design is not coding and coding is not design.
Software Design :

DESIGN PROCESS
The general design process shown above characterizes many design
disciplines, including building architecture, graphic design, various
branches of engineering, and software design. The software design process
can be decomposed mainly into the following three level of design:
 Interface level
 Architecture level
 Detailed level

Interface design- Interface design is the specification of the interaction between a
system and its environment. This phase proceed at high level.
Architectural design- The objective of architectural design is modelling of
overall software structure by representing components interface dependency and
relationship and interaction.
 Detailed design- Detailed design is the specification of the internal elements of
all major system components, their structure, properties, relationship and often
their algorithm and data structures.
Levels of design:

Software
Super class
ordinate
Peer user
Sub routine
User
Actor
Fig- Architectural design

“A modular system consists of well-define, manageable units with well
define interfaces among the units. The modularization of problem
partitioning, sometimes called problem decomposition”.
Desirable properties of modular system include:
•Each module is a well defined subsystem that is potentially useful in
other application.
• Each module has a single, well define purpose.
•Modules can be separately compiled and stored in a library.
•Module can use other modules.
•Module should be easier to use than to build.
•Module should be simpler from the outside than from the inside.
Low level design- Modularization:

Certain principles must be followed to ensure proper modularity:
• Linguistic modular units.
• Few interface
• Small interface(Weak coupling)
• Explicit interface
• Information hiding

Structural Chart
For a function oriented design, the design can be represented graphically, by structural
charts. The structure of a program is made up of the modules of that program together
with the interconnections between modules.
As an example consider the structure of the following program, whose structure is:
Main()
{
int sum, n N, a[MAX],j;
Readnums (a,&N);
Sort(a ,N);
Scanf (&n);
Sum= Add_n (a,n);
printf(Sum);
}
Readnums (a,N)
int a[], *N;
{
}

Sum
Main
Readnums Sort Add_n
Switch
a,n
A,n a
x,y
x,y
Fig- The structure chart of the sort program

Coupling and Cohesion-
Coupling is the measure of the degree of independence between modules.
Two modules are considered as independence modules if they individually
can work effectively without help to another module.
Two modules that are strongly
connected, highly dependent on each other mean one can’t work properly in
absence of another is called highly coupled module.
Uncoupled modules Highly-coupled modules

COHESION MEASURES:
Cohesion is the measure of functional relatedness elements within a single
module. When dividing a system into modules, it must be ensure that the
activities within the module are tightly bound to one another. It can be viewed
as opposite of coupling.
The level of cohesion go from good to bad i.e. the first from of
cohesion described below is the best form of cohesion and the last form of
cohesion is the worst form of cohesion.
“In functional independent module we have various advantages such as module
reusability, reducing the complexity of the design and reducing the errors”.

Types of cohesion module:
 Functional cohesion- All activities in the module are functionally related or
they are performing a similar function such as interest calculation, tax
calculation, etc.
 Sequential cohesion- In this scheme of cohesion, modules are divided into a
series of activities such that output of one module becomes the input to the
next module and chain continues.
 Communicational cohesion- This form of cohesion relates to a situation where
all modules share common data.
 Procedural cohesion- In this scheme, activities share the same procedural
implementation.
 Temporal cohesion- In this type of module cohesion, activities occurring in the
same period are grouped together.
 Logical cohesion- In logical cohesion, activities belonging to the same
category.
 Coincidental cohesion- There is no criteria of module.

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, a system is design from a functional view point.
One of the best-known advocates of this method is NIKLAUS width, the creator of
PASCAL and a number of other language.
For a function oriented design, the following can represent the design graphically or
mathematically:
 Data flow diagram
 Data dictionaries
 Structure charts
 Pseudo-code

Software Measurement & Metrics:
• Software measurement is a new way of managing software development.
Software measurements once an obscure and mysterious specialty has
become essential to good software engineering.
• Measurement enables software managers to assess software quality,
improve the software process and assist in planning, tracking, and control
of a software project.
• A prediction system consists of a mathematical model together with a set of
prediction procedures for determining unknown parameters and
interpreting result.
cost = s*c/d
Where s is distance , c is the cost and d is average distance.

SOFTWARE METRICS:
Software metrics can be defined as “It is a 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 all aspects of the management
process.
Categories of metrics:
i. Product metrics
ii. Process metrics
iii. Projects metrics
Areas of application-
The most established area of software metric is cost and
size estimation techniques. There are many proprietary packages in the market
that provide estimates of software system size, cost to develop a system, and the
duration of the development or enhancement of the project.

HALESTEAD’S SOFTWARE SCIENCE:
In the early 1970s, the “Late Professor Maurice Halestead and his co-workers” at
Purdue university developed the software science family of measurement.
Tokens are classified as either operators and operands. All software science
measures are function of the counts of these tokens.
It can be classified as:
 Program length- n= n1+n2
n: Vocabulary of a program
n1: Number of unique operators
n2: Number of unique operator
 Program Volume- V= N*log2n
The unit of volume is the common units for size “bits” . It is
actual size of program if a uniform binary encoding for the vocabulary is used.

Advantages of Halestead’s software matrices:
 Do not require indepth analysis of programming structure.
 Predict rate of error.
 Predict maintenance efforts.
 Useful in scheduling.
 Measures overall quality of programs.
 Simple to calculate.
 Can be used for any programming language.
Disadvantages of Halestead’s software matrices:
 It depends on complete code.
 It has little or no use for predictive estimation model

24/12/16 Abhimanyu Mishra(CSE) JETGI 19
Functional point based measures:
Alan Albercht while working for IBM, recognized the problem in size
measurement in the 1970s, and developed a technique which he called
“Functional Point Analysis”.
It measures functionality from the users point of view, that is, on the basis of
what the user request and receives in return. Therefore, it deals with the
functionality being delivered, and not with the line of code.
“The principle of Alberncht’s function point analysis is that a system is
decomposed into functional units”.
 Inputs: information entering the system.
 Outputs: information leaving the system.
 Enquiries: request for instant access to information.
 Internal logical files: informations held within the system.
 External interface files: information held by other system that is used by the
system being analyzed.

ILF
System
User
Other
applicati
on
User
Inquiries
EIF
Inputs
Fig- Functional point analysis

6
4
Functional units
Weighting factors
Low Average High
External input 3 4
External output 5 7
External inquiries 3 4 6
Internal Logical Files 7 10 15
External Interface Files 5 7 10
Fig- The 5 functional unit are ranked according to their complexity i.e. low, average, high
using a set of prescriptive standards.

Advantages of functional point analysis:
 It is not restricted to code.
 Language independent.
 More accurate than estimated LOC>
Disadvantages of functional point analysis:
 Subjective counting.
 Hard to automate and difficult to compute.
 Ignores quality of output.
 Oriented to traditional data processing application.
 Effort prediction using the unadjusted function count is
often no worse then when the TCF is added.

CYCLOMATIC COMPLEXITY:
The Cyclomatic complexity is also known as structural complexity because it
gives internal view of the code. This approach is used to find the number of
independent path through a program.
This provide us the upper bound for the number of tests that must be conducted to
ensure that all statements have been executed at least once and every condition
has been executed on its true and false side.
McCabe’s Cyclomatic metric, V(G) of a graph G with n vertices, e edges, and P
connected components is
V(G) = e-n+2p
V(G) =pi + 1
V(G) = number of region

Fig- Example of Cyclomatic complexity
V(G)= 8-6+2
4

Software Engineering unit 3

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Software Engineering unit 3

Semelhante a Software Engineering unit 3 (20)

Mais de Abhimanyu Mishra

Mais de Abhimanyu Mishra (19)

Último

Último (20)

Software Engineering unit 3