Unit-3 SE Notes DKPJ

Download as pdf or txt
Download as pdf or txt
You are on page 1of 12

UNIT-III SE [KCS-601]

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 Basics

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.

Objectives of Software Design

Following are the purposes of Software design:

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


2. Completeness:The design should have all components like data structures,
modules, and external interfaces, etc.

1 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]

3. Efficiency:Resources should be used efficiently by the program.


4. Flexibility:Able to modify on changing needs.
5. Consistency:There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily
maintainable by other designers.

Software Design Levels

Software design yields three levels of results:

 Architectural Design - The architectural design is the highest abstract version of


the system. It identifies the software as a system with many components
interacting with each other. At this level, the designers get the idea of proposed
solution domain.
 High-level Design- The high-level design breaks the ‘single entity-multiple
component’ concept of architectural design into less-abstracted view of sub-
systems and modules and depicts their interaction with each other. High-level
design focuses on how the system along with all of its components can be
implemented in forms of modules. It recognizes modular structure of each sub-
system and their relation and interaction among each other.
 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.

Software Architecture

Architecture serves as a blueprint for a system. It provides an abstraction to manage


the system complexity and establish a communication and coordination mechanism
among components.
 It defines a structured solution to meet all the technical and operational
requirements, while optimizing the common quality attributes like performance
and security.
 Further, it involves a set of significant decisions about the organization related to
software development and each of these decisions can have a considerable impact
on quality, maintainability, performance, and the overall success of the final
product.

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]

 ADL (Architecture Description Language) − ADL defines the software


architecture formally and semantically.

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 −

 Use case diagram


 Sequence diagram
 Communication diagram
 State chart diagram
 Activity diagram
 Interaction overview
 Time sequence diagram
The following table provides a brief description of these diagram −
Sr.No. Diagram & Description

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.

3 State Machine/state chart


Represents the event driven state change of a system. It basically describes the
state change of a class, interface, etc. Used to visualize the reaction of a system by
internal/external factors.

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

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

2. Following topics Read from chapter -6 " Software Metricis" of Book " Software
Engineering by KK agarwal and Yogesh Singh " for the UNIT-III

" Software Measurement and Metrics: Various Size Oriented Measures:


Halestead’s Software Science, Function Point (FP) Based Measures"

6 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]

Cyclomatic Complexity

Program Flow Graph Notation

Where each circle represents one or more nonbranching PDL(procedural design


Language) or source code statements

Cyclomatic Complexity

Cyclomatic complexity is a software metric that provides a quantitative measure of the


logical complexity of a program. When used in the context of the basis path testing
method, the value computed for cyclomatic complexity defines the number of
independent paths in the basis set of a program and provides us with an upper bound for
the number of tests that must be conducted to ensure that all statements have been
executed at least once.

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.

Cyclomatic complexity has a foundation in graph theory and provides us with an


extremely useful software metric. Complexity is computed in one of three ways:
1. The number of regions of the flow graph correspond to the cyclomatic
complexity.
2. Cyclomatic complexity, V(G), for a flow graph, G, is defined as
V(G) = E-N + 2
where E is the number of flow graph edges, N is the number of flow
graph nodes.
3. Cyclomatic complexity, V(G), for a flow graph, G, is also defined as
V(G) = P + 1
where P is the number of predicate nodes contained in the flow graph G.

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.

Therefore, the cyclomatic complexity of the flow graph in Figure B is 4.


More important, the value for V(G) provides us with an upper bound for the number of
independent paths that form the basis set and, by implication, an upper bound on the
number of tests that must be designed and executed to guarantee coverage of all program
statements.

What is Cyclomatic Complexity?

9 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-III SE [KCS-601]

Cyclomatic complexity is a source code complexity measurement that is being


correlated to a number of coding errors. It is calculated by developing a Control Flow
Graph of the code that measures the number of linearly-independent paths through a
program module.
Lower the Program's cyclomatic complexity, lower the risk to modify and easier to
understand. It can be represented using the below formula:
Cyclomatic complexity = E - N + 2*P
where,
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points

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

void main c { int a, b, c, max,


1. print f ('enter 3 integers"),
2. scan f (" %d %d %d", & a, & , & c),b
3. if (a >) b
4. if ( a > c)
5. Max = a
6. else max = c,
7. else if (b > c)
8. Max = b
9. else max = c
10. print and ( "a max = % d", max), 3

No. of independent paths


v (a) = e - n + 2
= 11 - 9 + 2
=4

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

You might also like