Unit-3 SE Notes DKPJ
Unit-3 SE Notes DKPJ
Unit-3 SE Notes DKPJ
UNIT-III
Software Design: Basic Concept of Software Design, Architectural Design, Low Level
Design: Modularization, Design Structure Charts, Pseudo Codes, Flow Charts,
Coupling and Cohesion Measures, Design Strategies: Function Oriented Design,
Object Oriented Design, Top-Down and Bottom-Up Design. Software Measurement
and Metrics: Various Size Oriented Measures: Halestead’s Software Science,
Function Point (FP) Based Measures, Cyclomatic Complexity Measures: Control
Flow Graphs.
__________________________________________________________________
Software design is a process to transform user requirements into some suitable form,
which helps the programmer in software coding and implementation. Software design is
the first step in SDLC (Software Design Life Cycle), which moves the concentration
from problem domain to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS.
Software design is a mechanism to transform user requirements into some suitable form,
which helps the programmer in software coding and implementation. 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.
1 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
Software Architecture
Goals of Architecture
The primary goal of the architecture is to identify requirements that affect the structure
of the application. A well-laid architecture reduces the business risks associated with
2 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
building a technical solution and builds a bridge between business and technical
requirements.
Some of the other goals are as follows −
Expose the structure of the system, but hide its implementation details.
Realize all the use-cases and scenarios.
Try to address the requirements of various stakeholders.
Handle both functional and quality requirements.
Reduce the goal of ownership and improve the organization’s market position.
Improve quality and functionality offered by the system.
Improve external confidence in either the organization or system.
Limitations
Software architecture is still an emerging discipline within software engineering. It has
the following limitations −
Lack of tools and standardized ways to represent architecture.
Lack of analysis methods to predict whether architecture will result in an
implementation that meets the requirements.
Lack of awareness of the importance of architectural design to software
development.
Lack of understanding of the role of software architect and poor communication
among stakeholders.
Lack of understanding of the design process, design experience and evaluation of
design.
Architecture Models
Software architecture involves the high level structure of software system abstraction, by
using decomposition and composition, with architectural style and quality attributes. A
software architecture design must conform to the major functionality and performance
requirements of the system, as well as satisfy the non-functional requirements such as
reliability, scalability, portability, and availability.
A software architecture must describe its group of components, their connections,
interactions among them and deployment configuration of all components.
A software architecture can be defined in many ways −
UML (Unified Modeling Language) − UML is one of object-oriented solutions
used in software modeling and design.
Architecture View Model (4+1 view model) − Architecture view model
represents the functional and non-functional requirements of software application.
3 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
UML
UML stands for Unified Modeling Language. It is a pictorial language used to make
software blueprints. UML was created by Object Management Group (OMG). The UML
1.0 specification draft was proposed to the OMG in January 1997. It serves as a standard
for software requirement analysis and design documents which are the basis for
developing a software.
UML can be described as a general purpose visual modeling language to visualize,
specify, construct, and document a software system. Although UML is generally used to
model software system, it is not limited within this boundary. It is also used to model
non software systems such as process flows in a manufacturing unit.
The elements are like components which can be associated in different ways to make a
complete UML picture, which is known as a diagram. So, it is very important to
understand the different diagrams to implement the knowledge in real-life systems. We
have two broad categories of diagrams and they are further divided into sub-categories
i.e. Structural Diagrams and Behavioral Diagrams.
Structural Diagrams
Structural diagrams represent the static aspects of a system. These static aspects
represent those parts of a diagram which forms the main structure and is therefore stable.
These static parts are represented by classes, interfaces, objects, components and nodes.
Structural diagrams can be sub-divided as follows −
Class diagram
Object diagram
Component diagram
Deployment diagram
Package diagram
Composite structure
The following table provides a brief description of these diagrams −
Sr.No. Diagram & Description
1 Class
Represents the object orientation of a system. Shows how classes are statically
related.
2 Object
Represents a set of objects and their relationships at runtime and also represent
the static view of the system.
4 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
3 Component
Describes all the components, their interrelationship, interactions and interface of
the system.
4 Composite structure
Describes inner structure of component including all classes, interfaces of the
component, etc.
5 Package
Describes the package structure and organization. Covers classes in the package
and packages within another package.
6 Deployment
Deployment diagrams are a set of nodes and their relationships. These nodes are
physical entities where the components are deployed.
Behavioral Diagrams
Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspects
are basically the changing/moving parts of a system. UML has the following types of
behavioral diagrams −
1 Use case
Describes the relationships among the functionalities and their internal/external
controllers. These controllers are known as actors.
2 Activity
Describes the flow of control in a system. It consists of activities and links. The
flow can be sequential, concurrent, or branched.
5 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
4 Sequence
Visualizes the sequence of calls in a system to perform a specific functionality.
5 Interaction Overview
Combines activity and sequence diagrams to provide a control flow overview of
system and business process.
6 Communication
Same as sequence diagram, except that it focuses on the object’s role. Each
communication is associated with a sequence order, number plus the past
messages.
7 Time Sequenced
Describes the changes by messages in state, condition and events.
" Instructions"
1. Follwing topics read from Read Chapter-5 Software Design of Book " Software
Engineering by KK agarwal and Yogesh Singh " for the UNIT-III
2. Following topics Read from chapter -6 " Software Metricis" of Book " Software
Engineering by KK agarwal and Yogesh Singh " for the UNIT-III
6 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
Cyclomatic Complexity
Cyclomatic Complexity
An independent path is any path through the program that introduces at least one
new set of processing statements or a new condition. When stated in terms of a flow
graph, an independent path must move along at least one edge that has not been traversed
before the path is defined. For example, a set of independent paths for the flow graph
illustrated in Figure 17.2B is
path 1: 1-11
path 2: 1-2-3-4-5-10-1-11
path 3: 1-2-3-6-8-9-10-1-11
path 4: 1-2-3-6-7-9-10-1-11
7 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
Note that each new path introduces a new edge. The path 1-2-3-4-5-10-1-2-3-6-8-9-10-1-
11 is not considered to be an independent path because it is simply a combination of
already specified paths and does not traverse any new edges.
Paths 1, 2, 3, and 4 constitute a basis set for the flow graph in Figure 17.2B. That
is, if tests can be designed to force execution of these paths (a basis set), every statement
in the program will have been guaranteed to be executed at least one time and every
condition will have been executed on its true and false sides. It should be noted that the
basis set is not unique. In fact, a number of different basis sets can be derived for a given
procedural design.
Write a program to find the greater out of two number is even or ODD
Flowchart, (A) and flow graph (B)
Compound logic
8 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
How do we know how many paths to look for? The computation of cyclomatic
complexity provides the answer.
Referring once more to the flow graph in Figure B, the cyclomatic complexity
can be computed using each of the algorithms just noted:
1. The flow graph has four regions.
2. V(G) = 11 edges - 9 nodes + 2 = 4.
3. V(G) = 3 predicate nodes + 1 = 4.
9 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
Example :
if(a>b)
{ if(a>b)
a=b; }
else
{ a=c; }
printf("a=",a);
printf("b=",b);
printf("c=",c);
FlowGraph:
The Cyclomatic complexity is calculated using the above control flow diagram that
shows seven nodes(shapes) and eight edges (lines), hence the cyclomatic complexity is
8-7+2=3
10 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
Example :
Consider following program to draw flow graph and calculate cyclomatric
complexity
No. of procedures = 1
∴ cyclomatic complexity = e - n + 2
11 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]
= 11 - 9 + 2
=4
Cyclomatric complexity = No of regions =4
Cyclomatric complexity = P+1 = 3+1 =4 Where P is No of predicates
12 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut