Software Engineering, Subject code: 17CS601, Unit -3

RAGHU ENGINEERING COLLEGE

(Affiliated to JNTU-KAKINADA & Accredited by NBA)
Visakhapatnam-531162
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
[Link]. CSE Semester-I
Regulation: AR 20 SUB: SOFTWARE ENGINEERING

Syllabus for Unit – 3

Software Design: Overview of design Process, Characteristics of good software design,

principles, modular design, design methodologies, structured design, structured design
methodologies, transform vs transaction analysis, cohesion and coupling, Approaches to software
design.

1. Explain about software design and process.

 Software Design is a crucial phase of the software development life cycle that focuses on
the solution domain of a system. It begins once the business needs customer requirements
and technical considerations are available in the SRS document.
 Software Design is the process of describing the blue print or sketch of the final software
product in the form of a design model.
 Software product is considered a collection of software modules. A module is a part of a
software product, which has data and functions together and an interface with other
modules to produce some output.
 Software design usually involves problem solving and planning a software solution. This
includes both low-level component and algorithm and high- level, architecture design.
 Software design is the process of implementing software solutions to one or more set of
problems. One of the important parts of software design is the software requirements
analysis (SRA).
Software Design Process:

 A software design exists between requirements engineering and programming. A software

design process is a set of design activities carried out in the design phase to produce a
design model from the SRS.
 Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation.
 For assessing user requirements, an SRS (Software Requirement Specification) document
is created whereas for coding and implementation, there is a need of more specific and

1
 Software Engineering, Subject code: 17CS601, Unit -3

detailed requirements in software terms. The output of this process can directly be used
into implementation in programming languages.
 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 fulfil the
requirements mentioned in SRS.
 The software design process is basically consists of three design phases or design level,
viz., architectural design, physical design, and detailed design. The software design process
is shown in below figure


Architecture 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. Architectural style
(e.g. client-server, layered, data centered, etc.) play important role to produce the external
design.
 Each architectural style has a different way of architecture mechanism, functional
characteristics, exception handling, performance criteria, data control, data store,
constraints, and external interfaces for the product.

Physical or High-level Design

 The high-level design or structural design or system 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.

2
 Software Engineering, Subject code: 17CS601, Unit -3

 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 is algorithmic design of each software module. It is also called logical
design. The detailed design concentrates on the specification of algorithms and data
structures of each module, the actual interface descriptions of data stores of the modules,
and package specification of the system.
 It 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.
 It uses the concept of abstraction for writing the stepwise procedures of the modules.
Structured English or pseudo codes are generally used for writing the specifications of
detailed designing.

2. Write the characteristics of a good software design

 A designer always tries to produce a good design. The definition of “a good software
design” can vary depending on the application being designed. For example, the memory
size used by a program may be an important issue to characterize a good solution for
embedded software development – since embedded applications are often required to be
implemented using memory of limited size due to cost, space, or power consumption
considerations.
 For embedded applications, one may sacrifice design comprehensibility to achieve code
compactness. For embedded applications, factors as design comprehensibility may take a
back seat while judging the goodness of design.
 Therefore, the criteria used to judge how good a given design solution is can vary widely
depending upon the application. Not only is the goodness of design dependent on the
targeted application, but also the notion of goodness of a design itself varies widely across
software engineers and academicians.
 However, most researchers and software engineers agree on a few desirable
Characteristics that every good software design for general application must possess. The
characteristics are listed below:
o Correctness: The software, which we are making, should meet all the
specifications stated by the customer.
o Usability/Learn ability: The amount of efforts or time required to learn how to
use the software should be less. This makes the software user-friendly even for IT-
illiterate people.

3
 Software Engineering, Subject code: 17CS601, Unit -3

o Integrity: Just as medicines have side-effects, in the same way software may have
a side-effect i.e. it may affect the working of another application. But quality
software should not have side effects.
o Reliability: The software product should not have any defects. Not only this, it
shouldn't fail while execution.
o Efficiency: This characteristic relates to the way software uses the available
resources. The software should make effective use of the storage space and execute
command as per desired timing requirements.
o Security: With the increase in security threats nowadays, this factor is gaining
importance. The software shouldn't have ill effects on data / hardware. Proper
measures should be taken to keep data secure from external threats.
o Safety: The software should not be hazardous to the environment/life. Possibly the
most important goodness criterion is design correctness. A design has to be correct
to be acceptable. Given that a design solution is correct, understand ability of a
design is possibly the most important issue to be considered while judging the
goodness of a design.
o Maintainability: Maintenance of the software should be easy for any kind of user.
o Flexibility: Changes in the software should be easy to make.
o Extensibility: It should be easy to increase the functions performed by it.
o Scalability: It should be very easy to upgrade it for more work (or for more number
of users).
o Testability: Testing the software should be easy.
o Modularity: Any software is said to make of units and modules which are
independent of each other. These modules are then integrated to make the final
software. If the software is divided into separate independent parts that can be
modified, tested separately, it has high modularity.
o Interoperability: Interoperability is the ability of software to exchange
information with other applications and make use of information transparently.
o Reusability: If we are able to use the software code with some modifications for
different purpose then we call software to be reusable.
o Portability: The ability of software to perform same functions across all
environments and platforms, demonstrate its portability.
 A design that is easy to understand is also easy to develop, maintain and change. Thus,
unless a design is easily understandable, it would require tremendous effort to implement
and maintain it.
3. What are design principle of a good software? Explain

 Software design is one of the important phases in SDLC that is performed to shape the
solution to a problem. There are certain design concepts and principles that govern the
building of quality of software design.

4
 Software Engineering, Subject code: 17CS601, Unit -3

 The design concepts and principles remain the same for all kinds of application system
development, irrespective of the design techniques. Some of the common concepts of
Software design are
1. Abstraction
2. Information Hiding
3. Functional Decomposition
4. Design Strategies
5. Modular Design
1. Abstraction:

 Abstraction is the process or result of generalization by reducing the information content

of a concept or an observable phenomenon, typically in order to retain only information
,which is relevant for a particular purpose.
 Abstraction is one of the most fundamental principles taken into account in the software
development process.
 With improving programming technology and changing nature of customer needs, it
becomes very difficult for software engineers to keep all the things in their minds.
 Therefore, to overcome such complexity of technology and problem, they concentrate on
the essential details of the system and delay the unnecessary details.
 For example, banks have several kinds of accounts (saving account, deposit account,
recurring account, current account) and each account holds money of the account holders.
Each of these accounts provides facilities for deposit, with drawl, and balance enquiry.
 A bank account can be declared in an abstract manner with the above features without
describing how these operations will be performed on the account types.
 Abstraction helps in maintenance phase to understand and maintain the system. It is
beneficial in the modern programming environment, where application programming
interfaces (APIs) and components programming features are used in system development.
 Software designers and architects widely use abstraction during software design there are
certain advantages of using abstraction in software development.
o It separates design from implementation, which is easy to understand and manage.
o It helps in problem understanding and software maintenance.
o It reduces the complexity of modern computer programming for software users and
engineers.
o It helps in program organization that can be generalized for recovering common
problems and therefore it promotes software reuse.
 There are three types of Abstraction namely
o Functional Abstraction:

 It specifies the functions that a module performs in the system. It is specified

by the function name with parameters and return types. Functional
abstraction is produced through partioning the problems into subparts.

5
 Software Engineering, Subject code: 17CS601, Unit -3


The common features in the subparts are accumulated in a group that
represents functional abstraction. Examples are Function prototype,
function call, closed subroutines
o Data Abstraction:


Data abstraction specifies the entities or data objects that provide certain
services to the external environment.
 In data Abstraction, Essential details are given and the detailed views are
suppressed. That is it hides the representation and implementation details of
data objects.
 Abstract Data Types (ADTs), such as structures in c, classes in C++ and
packages in java are the examples of data abstraction.
o Control Abstraction:

It provides the operational characteristics of the system without describing

their implementation details.
 For examples loops, iterations, frameworks, and multithreading describe
control abstraction. Control Abstraction is defined to perform some
operation using subroutines.
 Subroutines perform certain operations and returns to caller program.
Control abstraction uses flags to signal the execution of a program or its
subparts.
2. Information Hiding:

 Parnas initially proposed the concept of information hiding in 1972 and he suggested that
modules can be characterized by the design decisions in which each module hides the
details from other modules.
 That is, making the essential details inaccessible to others to prevent unauthorized access
and damage from the external environment.
 The design Modules of the software interact with other modules through interfaces by
passing arguments
 The main information that can be hidden includes data structures using ADT, Procedures
or Algorithms processes for the execution, input/output formats, policy and mechanism
etc.
 Information hiding is an important design principle which is expressed through
encapsulation and abstraction. Encapsulation is a programming language such as C++,
Java, etc.
 Data and functions are encapsulated through access specifies within objects that provide
abstraction by hiding the detailed information.

6
 Software Engineering, Subject code: 17CS601, Unit -3

 Objects share information to some extent depending upon the programming features. For
example, access specifiers like private, public and protected allow required data and
services from objects.
3. Functional Decomposition:

 Functional Decomposition is the process of partioning a large and complex problem into
small, manageable, and understandable pieces.
 The goal of functional decomposition is to make the maintenance task easier, to make it
easy to understand and develop software in an efficient manner.
 It is performed using abstraction and information hiding. The decomposition process uses
“Divide and conquer” approach to divide the software into independent parts.
 When these parts are combined together, they act together to achieve the goal of the
software. The problem is initially considered as a single function with its essential details
and later it is elaborated into discrete and small pieces.
 Functional decomposition divides a large problem into successfully smaller until the
functional level achieved.

4. Design Strategies: Top down and Bottom Up

Top down Design

 Functional decomposition results in a hierarchy of components.

 We know that a system is composed of more than one sub-systems and it contains a number
of components. Further, these sub-systems and components may have their onset of sub-
system and components and creates hierarchical structure in the system.
 A top down strategy also referred to as step wise refinement is essentially partioning a
system to elaborate on its sub systems.
 Top-down design takes the whole software system as one entity and then decomposes it to
achieve more than one sub-system or component based on some characteristics. Each sub-
system or component is then treated as a system and decomposed further. This process
keeps on running until the lowest level of system in the top-down hierarchy is achieved.
 Top-down design starts with a generalized model of system and keeps on defining the more
specific part of it. When all components are composed the whole system comes into
existence.
 Top-down design is more suitable when the software solution needs to be designed from
scratch and specific details are unknown.
 During the top down decomposition, abstraction helps designers to define the essential
details and suppress the lower level information.

7
 Software Engineering, Subject code: 17CS601, Unit -3

Bottom-up Design

 The bottom up design model starts with most specific and basic components. It proceeds
with composing higher level of components by using basic or lower level components. It
keeps creating higher level components until the desired system is not evolved as one single
component. With each higher level, the amount of abstraction is increased.
 Bottom-up strategy is also referred to as layers of abstraction are piecing together the
subsystems to form the whole systems. It starts with the lower-level subsystems at the
bottom level which are the individual elements in the system.
 Bottom-up strategy is more suitable when a system needs to be created from some existing
system, where the basic primitives can be used in the newer system.
 Both, top-down and bottom-up approaches are not practical individually. Instead, a good
combination of both is used.

5. Modular Design

 A Modular design focuses on minimizing the interconnections between modules. In a

Modular system design, several independent and executable modules are composed
together to construct an executable application program.
 The programming language supports, interfaces, and information hiding principles ensure
modular system design. There are various modularization criterions to measure the
modularity of a system.
 The most common criterions are functional diagrams, Such as DFD, Modular
Programming languages, coupling and cohesion.
 An Effective modular system has low coupling and high cohesion. Coupling and cohesion
are often used to opposite end of a scale in measuring how “Good” a piece of software is.
 These metrics are commonly used for measuring the quality of an object-oriented code.

8
 Software Engineering, Subject code: 17CS601, Unit -3

Modularity

 Modularity has been influential for the programming languages that support abstract data
types, object oriented designs, component based development, and the principles of
software architectures,
 Modularity plays an important role in architectural design of software. Nowadays it
becomes a desirable feature in a system. Modularization is the process of breaking a system
into pieces called modules so that these can be managed and implemented. A module is a
part of software system that can be separately implemented and a change in module has an
effect on other modules.
 Thus a modular system consists of various modules linked via interfaces. An interface is a
kind of link or relationship that combines two or more modules together. Modularity is the
measurement of modularization of a system into pieces.

Modularization

 This is a technique to divide a software system into multiple discrete and independent
modules, which are expected to be capable of carrying out task(s) independently.
 These modules may work as basic constructs for the entire software. Designers tend to
design modules such that they can be executed and/or compiled separately and
independently.
 Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of
software.

Advantages of Modularization

 Smaller components are easier to maintain

 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired for security aspect

4. What do you mean by Coupling? Explain in details.

9
 Software Engineering, Subject code: 17CS601, Unit -3

 Coupling is the strength of interconnection between modules. Alternatively, it is the

measure of the degree of interdependency between modules.
 Modules are either loosely coupled or strongly coupled. In strong coupling two modules
are dependent in each other.
 Strong coupling can be observed in assembly language programs where change in one part
or data requires change in other parts of the system. In addition, these are difficult to reuse,
test and release for the operation.
 In loose coupling, there weak interconnections between modules. Although modules are
somehow interconnected with other modules, Low coupling is generally preferred in good
software design.
 Independency between modules increases as coupling decreases. Coupling increases as
interconnection between module increases.
 The number of function calls, number of parameters passed, return values, data types,
sharing of data files or data items can measure interconnection between modules.
 There are different types of coupling. In that message coupling is the lowest (best) and
content coupling is the highest (worst) level of coupling. The ranking of the coupling from
lowest (best) to highest (worst) is as follows:

1. Message Coupling Lowest(Best)

2. Data Coupling
3. Stamp Coupling
4. Control Coupling
5. External Coupling
6. Common Coupling
7. Content Coupling Highest (Worst)

 Message Coupling: Message Coupling is the lowest (i.e., best) type of coupling which
exists between modules. It can be observed in object-oriented or component-based
systems, where objects or components communicate through parameters or message
passing. For Example, in C++ objects communicate with each other by sending a message
through parameters in the function call.
 Data coupling: Data coupling exists between modules when data are passed as
parameters in the argument list of the function call. Each datum is a primary data item
(e.g., integer, character, float, etc.) that can be used between modules. Data coupling is
good if a small number of data items are passed in the function call.
 Stamp coupling- Stamp coupling occurs between modules when data are passed by
parameters using complex data structures, which may use parts or entire data structure by
other modules. For example, structure in C, records in Pascal, etc. Stamp Coupling is
preferred when most of the items are used in the argument list of the function.

10
 Software Engineering, Subject code: 17CS601, Unit -3

 Control coupling: Control coupling exists when one module controls the flow of another
by passing control information such as a flag set or switch statements. Control coupling
controls the sequence of instruction execution in another module. For example, a flag
variable decides what function or module is to be executed next.
 External Coupling: External Coupling occurs when two modules share an externally
imposed data format, communication protocol, or device interface. All the modules share
the same I/O device or the external environment.
 Common Coupling: Common coupling is when two modules share common data (e.g.,
a global variable). In C language, all modules in the program access external data items.
If there is any change in the shared resource, it influences all the modules using it.
 Content coupling – It is the highest coupling (worst).Content coupling exists between
two modules when one module refers or shares its internal working with another module.
Accessing local data items or instructions of another module is an example of content
coupling. When a module can directly access or modify or refer to the content of another
module, it is called content level coupling

5. What do you mean by Cohesion? Explain in details.

 Cohesion in a single module is the degree to which the elements of a single module are
functionally related to achieve an object.
 Module cohesion represents how tightly bound the internal elements of the module are to
one another. Higher cohesion is preferred for an effective modular design.
 Generally, whenever cohesion is greater, coupling between the modules is lower.
Cohesion between the elements of module is measured in terms of strength of the hiding
of the elements within module itself.
 Functional Cohesion is the strongest (best) and Coincidental Cohesion is the weakest
(worst) level of cohesion. The ratings of the common categories of cohesion ranked from
the strongest (best) to the weakest (Worst).
 There are many different levels of cohesion used at several levels of a module, such as

1. Functional Cohesion Lowest(Best)

2. Sequential Cohesion
3. Communicational Cohesion
4. Procedural Cohesion
5. Temporal Cohesion
6. Logical Cohesion
7. Coincidental Cohesion Highest (Worst)

11
 Software Engineering, Subject code: 17CS601, Unit -3

 Functional Cohesion: Functional cohesion (Strongest (Best)) 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 well-defined function. It can
also be reused. In this each part necessary for execution of a single function. e.g., compute
square root or sort the array.
 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. It May
contain several functions or parts of different functions. For example, “withdraw money”
and “update balance” both are bound together to withdraw money from an account.
 Communicational cohesion - When elements of module are grouped together, which are
executed sequentially and work on same data (information), it is called communicational
cohesion. A module may perform more than one function. For example,”printf' and punch
the output file “can be communicational cohesion. The binding of elements in a module
is higher that procedural cohesion.
 Procedural cohesion - When elements of module are grouped together, which are executed
sequentially in order to perform a task, it is called procedural cohesion. The functions are
executed in a certain order. For example, “entering, reading, and verifying the ATM
password” are bound in an ordered manner for the procedurally cohesive module “enter
password”
 Temporal Cohesion - When elements of module are organized such that they are
processed at a similar point in time, it is called temporal cohesion. All the functions that
are activated at a single time, such as start-up shutdown, are brought together. For
example, “a database trigger is activated on executing a certain procedure”.
 Logical cohesion - When logically categorized elements are put together into a module, it
is called logical cohesion. The similar functions such as input, error handling, etc. put
together. Functions fall in same logical class. All the parts may communicate with each
other by passing control information such as flag variable, using some shared source code,
etc. to determine which ones executed.
 Co-incidental cohesion – It is the weakest level of 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. It is harder to understand and not reusable.

6. What do you mean by Structure Analysis? Explain in brief.

 Structured analysis is used to carry out the top-down decomposition of a set of high-level
functions depicted in the problem description and to represent them graphically.
 During structured analysis, functional decomposition of the system is achieved. That is,
each function that the system performs is analyzed and hierarchically decomposed into
more detailed functions.

12
 Software Engineering, Subject code: 17CS601, Unit -3

 Structured analysis technique is based on the following essential underlying principles:

 Top-down decomposition approach.
 Divide and conquer principle. Each function is decomposed independently.
 Graphical representation of the analysis results using Data Flow Diagrams
(DFDs).

7. What do you mean by DFD? Explain in brief

 The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that
shows the different processing activities or functions that the system performs and the data
interchange among these functions.
 Each function is considered as a processing station (or process) that consumes some input
data and produces some output data. The system is represented in terms of the input data
to the system, various processing carried out on these data, and the output data generated
by the system.
Symbols used in construction of DFD
 There are essentially five different types of symbols used for construction of DFDs. The
symbols are as follows:
Function symbol :
 A function is represented by a circle. This symbol is called bubble or process.
External entity symbols.
 The external entities are those physical entities external to the s/w system which interact
with the system by inputting data to the system or by consuming the data produced by the
system. In addition, these symbols can be used to represent external h/w and s/w that would
interact with the s/w being modeled.
Data flow symbol :
 A directed arc (arrow) is used for a data flow symbol. A data flow symbol represents the
data flow occurring between two processes or between an external entity and a process in
the direction of the flow of data.
Data store symbol :
 A data store is represented by two parallel lines. It represents a logical file, where data
stored symbol can either be a data structure or a physical file on disk.
Output symbol:
 The output symbol is used when a hardcopy is produced.

Important terms used in constructing DFDs

13
 Software Engineering, Subject code: 17CS601, Unit -3

 Synchronous and asynchronous operations

o If two bubbles are connected by a data flow arrow, they are synchronous i.e. they
operated at a same speed. For example : in the following example the data item act
as an input to read number, unless the output of read number generated the valid
number does not work as the output of the read number act as the input of valid
number.
o If two bubbles are connected through a data store, the speed of the operation of the
bubbles are independent i.e. asynchronous. In previous case the output of read
number is input of valid number but here the read number, read the number and
stored it in the database, which is later used by the validate number.

valid-number
number validate
number
Read
number
Data-item

Synchronous Operation with two functions

Read valid-number
Data-item validate
number
number

number

Asynchronous Operation with two functions

 Data Dictionary

o A data dictionary lists all data items appearing in the DFD model of a system. The
data items listed include all data flows and the contents of all data stores appearing
on the DFDs in the DFD model of a system.
14
 Software Engineering, Subject code: 17CS601, Unit -3

o A data dictionary lists the purpose of all data items and the definition of all
composite data items in terms of their component data items.
o For the smallest units of data items, the data dictionary lists their name and their
type. Composite data items can be defined in terms of primitive data items using
the following data definition operators:
 +: denotes composition of two data items, e.g. a + b represents data a and b.
 [,,]: represents selection, i.e. any one of the data items listed in the brackets
can occur. For example, [a ,b] represents either a occurs or b occurs.
 (): the contents inside the bracket represent optional data which may or may
not appear. e.g. a+(b) represents either a occurs or a + b occurs.
 {}: represents iterative data definition, e.g. {name}5 represents five name
data.
 {name}* represents zero or more instances of name data.
 =: represents equivalence, e.g. a = b + c means that a represents b and c.
 /* */: Anything appearing within /* and */ is considered as a comment.

8. Discuss the steps to construct DFD for a system

 A DFD model of a system graphically depicts the transformation of the data input to the
system to the final result through a hierarchy of levels.
 A DFD starts with the most abstract definition of the system (lowest level) and at each
higher level DFD more details are successively introduced. To develop a higher-level DFD
model, processes are decomposed into their sub-processes and the data flow among these
sub-processes is identified.
 To develop the data flow model of a system, first the most abstract representation of the
problem is to be worked out. The most abstract representation of the problem is also called
the context diagram. After, developing the context diagram, the higher-level DFDs have to
be developed.
Context diagram
 The context diagram is the most abstract data flow representation of a system. It represents
the entire system as a single bubble. This bubble is labeled according to the main function
of the system.
 The various external entities with which the system interacts and the data flow occurring
between the system and the external entities are also represented. The data input to the
system and the data output from the system are represented as incoming and outgoing
arrows.

15
 Software Engineering, Subject code: 17CS601, Unit -3

 These data flow arrows should be annotated with the corresponding data names. The name
‘context diagram’ is well justified because it represents the context in which the system is
to exist, i.e. the external entities who would interact with the system and the specific data
items they would be supplying the system and the data items they would be receiving from
the system. The context diagram is also called as the level 0 DFD.
 To develop the context diagram of the system, it is required to analyze the SRS document
to identify the different types of users who would be using the system and the kinds of data
they would be inputting to the system and the data they would be receiving the system.
Here, the term “users of the system” also includes the external systems, which supply data
to or receive data from the system.
 The bubble in the context diagram is annotated with the name of the software system being
developed (usually a noun). This is in contrast with the bubbles in all other levels, which
are annotated with verbs. This is expected since the purpose of the context diagram is to
capture the context of the system rather than its functionality.
Decomposition
 Each bubble in the DFD represents a function performed by the system. The bubbles are
decomposed into sub-functions at the successive levels of the DFD.
 Decomposition of a bubble is also known as factoring or exploding a bubble. Each bubble
at any level of DFD is usually decomposed to anything between 3 to 7 bubbles.

Example:
RMS calculating Software
A software system called RMS calculating software would read three integral numbers from
the user in the range of -1000 and 1000 and would determine the root mean square of the
three input numbers and display it.
The context diagram of the system accept three integers form the user and return the result to him.
This is shown in the following figure as context diagram.

User

Data-items rms

rms
calculator
0

16
 Software Engineering, Subject code: 17CS601, Unit -3

To draw the level 1 DFD, from an analysis of the problem description, there are three basic
functions that the system needs to perform i.e.,
1. Validate the input
2. Calculate the rms i.e., root mean square of the input numbers
3. Display result
Based on the sequence of the functions, the number / labels like 0.1, 0.2, 0.3 assigned to the
functions. After representing the functions the level 1 DFD looks as follows:

rms

Data-items Validate- Valid - data rms

Compute- Display -
input rms result
0.1 0.2 0.3
1 1 1

To draw level 2 DFD, we have to consider a function in level 1 and then decompose the function
in to lower level. In this case, the function 0.2 is considered for decomposition. The following
figure display the level 2 DFD

Square
0.2.3
S q u a r e

0 . 2 . 1
csq

Square
0.2.2
S q u a r e
bsq
0 . 2 . 1

Square Mean
0.2.1 0.2.4
asq msq
S q u a r e

0 . 2 . 1

Root rms
0.2.5
S q u a r e

0 . 2 . 1

17
 Software Engineering, Subject code: 17CS601, Unit -3

Data dictionary for DFD model

Data_items: {integer}3

rms: float

valid-data: data-items

a: integer

b: integer

c: integer

asq: integer

bsq: integer

csq: integer

msq: integer

9. What do you mean by structured design? Discuss is details.

 The aim of structured design is to transform the results of the structured analysis (i.e. a
DFD representation) into a structure chart. Structured design provides two strategies to
guide transformation of a DFD into a structure chart.

 Transform analysis
 Transaction analysis
 Normally, one starts with the level 1 DFD, transforms it into module representation using
either the transform or the transaction analysis and then proceeds towards the lower-level
DFDs.
 At each level of transformation, it is important to determine whether the transform or the
transaction analysis is applicable to a particular DFD.

Transform analysis

 Transform analysis identifies the primary functional components (modules) and the high
level inputs and outputs for these components. The first step in transform analysis is to
divide the DFD into 3 types of parts:

 Input
 Logical processing
 Output
18
 Software Engineering, Subject code: 17CS601, Unit -3

 The input portion of the DFD includes processes that transform input data from physical
(e.g. character from terminal) to logical forms (e.g. internal tables, lists, etc.). Each input
portion is called an afferent branch.
 The output portion of a DFD transforms output data from logical to physical form. Each
output portion is called an efferent branch. The remaining portion of a DFD is called the
central transform.
 In the next step of transform analysis, the structure chart is derived by drawing one
functional component for the central transform, and the afferent and efferent branches.
These are drawn below a root module, which would invoke these modules.
 Identifying the highest level input and output transforms requires experience and skill. One
possible approach is to trace the inputs until a bubble is found whose output cannot be
deduced from its inputs alone.
 Processes, which validate input or add information to them are not central transforms.
Processes, which sort input or filter data from it are. The first level structure chart is
produced by representing each input and output unit as boxes and each central transform
as a single box.
 In the third step of transform analysis, the structure chart is refined by adding sub-functions
required by each of the high-level functional components. Many levels of functional
components may be added. This process of breaking functional components into
subcomponents is called factoring.
 Factoring includes adding read and write modules, error-handling modules, initialization
and termination process, identifying customer modules, etc. The factoring process is
continued until all bubbles in the DFD are represented in the structure chart.

Transaction Analysis

 A transaction allows the user to perform some meaningful piece of work. Transaction
analysis is useful while designing transaction processing programs. In a transaction-driven
system, one of several possible paths through the DFD is traversed depending upon the
input data item.
 This is in contrast to a transform centered system which is characterized by similar
processing steps for each data item. Each different way in which input data is handled is a
transaction. A simple way to identify a transaction is to check the input data.
 The number of bubbles on which the input data to the DFD are incident defines the number
of transactions. However, some transaction may not require any input data. These
transactions can be identified from the experience of solving a large number of examples.
 For each identified transaction, trace the input data to the output. All the traversed bubbles
belong to the transaction.
 These bubbles should be mapped to the same module on the structure chart. In the structure
chart, draw a root module and below this module draw each identified transaction a

19
 Software Engineering, Subject code: 17CS601, Unit -3

module. Every transaction carries a tag, which identifies its type. Transaction analysis uses
this tag to divide the system into transaction modules and a transaction-center module.

10. What do you mean by structure chart? Discuss is details.

 A structure chart represents the software architecture, i.e. the various modules making up
the system, the dependency (which module calls which other modules), and the parameters
that are passed among the different modules. Hence, the structure chart representation can
be easily implemented using some programming language.
 Since the main focus in a structure chart representation is on the module structure of the
software and the interactions among different modules, the procedural aspects (e.g. how a
particular functionality is achieved) are not represented.
 The basic building blocks which are used to design structure charts are the following:

o Rectangular boxes: Represents a module.

o Module invocation arrows: Control is passed from one module to another module
in the direction of the connecting arrow.
o Data flow arrows: Arrows are annotated with data name; named data passes from
one module to another module in the direction of the arrow.
o Library modules: Represented by a rectangle with double edges.
o Selection: Represented by a diamond symbol.
o Repetition: Represented by a loop around the control flow arrow.
 In any structured chart, there should be one and only one module at the top, called the root
or main. There should be at most one control relationship between any two modules in the
structured chart.
 That means if module A invokes B, module B can not invoke module A. The main reason
for this restriction is that the different modules of the structured chart to be arranges in
layers or levels.
Flow chart vs. Structured Chart
 Flow chart is a conventional technique to represent the flow of control in the program. A
structured chart differs from flow chart in following three ways:
o It is usually difficult to identify different modules of a program form its flow chart
representation.
o Data interchange among different modules is not represented in the flow chart.
o Sequential ordering of tasks that is inherent to a flow chart is suppressed in the
structured chart
 The process of the transformation of the DFDs into structured chart can be seen using the
following diagram. The system considers the DFD as the input and transform it into
structured chart, which is considered as the input to the programmers for coding.

20
 Software Engineering, Subject code: 17CS601, Unit -3

Main

RMS
Validate Input Compute RMS Write Result

Read Input Validate Input

 In the above diagram, it is observed that the top most node is main. This is also called as
root.
 In the next level, the system is divided into three modules or functions such as validate
input, compute RMS and write result.
 The next level, the function validate input is decomposed into two more sub-functions such
as read input and validate input.
 This expression helps the programmers or the coder to know about the functions they
implement and finally the product will take a shape.

11. Discuss the object oriented design principle.

 In traditional approach of designing, we use DFD with its different levels and later
structured chart is designed based on DFD. The structured chart help the programmer to
do coding based on this.
 In traditional approach, the main program is divided into modules or functions. The
modules are designed separately and finally combine to obtain the whole system.
 However, in object oriented system, the designing is quite different. In this approach, the
class diagram is the main unit to develop and it is the base on which the whole system is
designed.
 Object oriented design has become a popular design methodology in the recent years. It
works around the entities and their characteristics instead of functions involved in the
software system. This design strategy focuses on entities and its characteristics. The whole
concept of software solution revolves around the engaged entities.

21
 Software Engineering, Subject code: 17CS601, Unit -3

Concepts of object oriented design

 Classes - A class is a generalized description of an object. An object is an instance of a

class. Class defines all the attributes, which an object can have and methods, which defines
the functionality of the object. In the solution design, attributes are stored as variables and
functionalities are defined by means of methods or procedures.
 Objects - All entities involved in the solution design are known as objects. For example,
person, banks, company and customers are treated as objects. Every entity has some
attributes associated to it and has some methods to perform on the attributes.
 Encapsulation - In OOD, the attributes (data variables) and methods (operation on the
data) are bundled together is called encapsulation. Encapsulation not only bundles
important information of an object together, but also restricts access of the data and
methods from the outside world. This is called information hiding
 Inheritance - OOD allows similar classes to stack up in hierarchical manner where the
lower or sub-classes can import, implement and re-use allowed variables and methods from
their immediate super classes. This property of OOD is known as inheritance. This makes
it easier to define specific class and to create generalized classes from specific ones.
 Message passing - Any application requires a number of objects interacting in a
harmonious manner. Objects in a system may communicate with each other by using
message passing. Suppose a system has two objects − obj1 and obj2. The object obj1 sends
a message to object obj2, if obj1 wants obj2 to execute one of its methods.
 Polymorphism - OOD languages provide a mechanism where methods performing similar
tasks but vary in arguments, can be assigned same name. This is called polymorphism,
which allows a single interface performing tasks for different types. Depending upon how
the function is invoked, respective portion of the code gets executed.

 The different object oriented principles ones in use were:

 Object Management Technology [Rumbaugh 1991]
 Booch’s methodology [Booch 1991]
 Object-Oriented Software Engineering [Jacobson 1992]
 Odell’s methodology [Odell 1992]
 Shaler and Mellor methodology [Shaler 1992]
 UML has borrowed many concepts from these modeling techniques. Especially, concepts
from the first three methodologies have been heavily drawn upon.
 Object Management Group (OMG) as a de facto standard adopted UML in 1997. OMG is
an association of industries which tries to facilitate early formation of standards
 UML, as the name implies, is a modeling language. It may be used to visualize, specify,
construct, and document the artifacts of a software system. It provides a set of notations
(e.g. rectangles, lines, ellipses, etc.) to create a visual model of the system. Like any other

22
 Software Engineering, Subject code: 17CS601, Unit -3

language, UML has its own syntax (symbols and sentence formation rules) and semantics
(meanings of symbols and sentences).
 Also, we should clearly understand that UML is not a system design or development
methodology, but can be used to document object-oriented and analysis results obtained
using some methodology.
 In the late 1980s and early 1990s, there was a proliferation of object-oriented design
techniques and notations. Different software development houses were using different
notations to document their object-oriented designs. These diverse notations used to give
rise to a lot of confusion.
 UML was developed to standardize the large number of object-oriented modeling notations
that existed and were used extensively in the early 1990s

12. What do you mean by UML diagram? Discuss its type

 UML can be used to construct nine different types of diagrams to capture five different
views of a system. Just as a building can be modeled from several views (or perspectives)
such as ventilation perspective, electrical perspective, lighting perspective, heating
perspective, etc.; the different UML diagrams provide different perspectives of the
software system to be developed and facilitate a comprehensive understanding of the
system. Such models can be refined to get the actual implementation of the system.
 The UML diagrams can capture the following five views of a system:
o User’s view
o Structural view
o Behavioral view
o Implementation view
o Environmental view

23
 Software Engineering, Subject code: 17CS601, Unit -3

User’s view:
 This view defines the functionalities (facilities) made available by the system to its
users. The users’ view captures the external users’ view of the system in terms of the
functionalities offered by the system.
 The users’ view is a black-box view of the system where the internal structure, the
dynamic behavior of different system components, the implementation etc. are not
visible.
 The users’ view is very different from all other views in the sense that it is a functional
model compared to the object model of all other views. The users’ view can be
considered as the central view and all other views are expected to conform to this view.
This thinking is in fact the crux of any user centric development style.
Structural view:
 The structural view defines the kinds of objects (classes) important to the
understanding of the working of a system and to its implementation.
 It also captures the relationships among the classes (objects). The structural model is
also called the static model, since the structure of a system does not change with time.
Behavioral view:
 The behavioral view captures how objects interact with each other to realize the system
behavior. The system behavior captures the time-dependent (dynamic) behavior of the
system.
Implementation view:
 This view captures the important components of the system and their dependencies.
Environmental view:
 This view models how the different components are implemented on different pieces of
hardware.

13. What do you mean by Use Case Diagram? Explain with an example
 The use case model for any system consists of a set of “use cases”. Intuitively, use
cases represent the different ways in which a system can be used by the users. Use
cases correspond to the high-level functional requirements.
 The use cases partition the system behavior into transactions, such that each transaction
performs some useful action from the user’s point of view. To complete each
transaction may involve either a single message or multiple message exchanges
between the user and the system to complete.
 The purpose of a use case is to define a piece of coherent behavior without revealing
the internal structure of the system. The use cases do not mention any specific
algorithm to be used or the internal data representation, internal structure of the
software, etc.
 A use case typically represents a sequence of interactions between the user and the
system. These interactions consist of one mainline sequence. The mainline sequence
24
 Software Engineering, Subject code: 17CS601, Unit -3

represents the normal interaction between a user and the system. The mainline
sequence is the most occurring sequence of interaction. The variations are also called
alternative paths. A use case can be viewed as a set of related scenarios tied together
by a common goal. The mainline sequence and each of the variations are called
scenarios or instances of the use case. Each scenario is a single path of user events and
system activity through the use case.
 Use cases can be represented by drawing a use case diagram and writing an
accompanying text elaborating the drawing. In the use case diagram, each use case is
represented by an ellipse with the name of the use case written inside the ellipse.
 All the ellipses (i.e. use cases) of a system are enclosed within a rectangle which
represents the system boundary. The name of the system being modeled (such as
Library Information System) appears inside the rectangle.
 The different users of the system are represented by using the stick person icon. Each
stick person icon is normally referred to as an actor. An actor is a role played by a user
with respect to the system use. It is possible that the same user may play the role of
multiple actors.
 Each actor can participate in one or more use cases. The line connecting the actor and
the use case is called the communication relationship. It indicates that the actor makes
use of the functionality provided by the use case. Both the human users and the external
systems can be represented by stick person icons. When a stick person icon represents
an external system, it is annotated by the stereotype <<external system>>.
 Text Description: Each ellipse on the use case diagram should be accompanied by a
text description. The text description should define the details of the interaction
between the user and the computer and other aspects of the use case. It should include
all the behavior associated with the use case. The behavior description is often written
in a conversational style describing the interactions between the actor and the system.
 Actors: In addition to identifying the actors, some information about actors using this
use case which may help the implementation of the use case may be recorded.
 Pre-condition: The preconditions would describe the state of the system before the
use case execution starts.
 Post-condition: This captures the state of the system after the use case has successfully
completed.
 Non-functional requirements: This could contain the important constraints for the
design and implementation
 Exceptions, error situations: This contains only the domain-related errors such as
lack of user’s access rights, invalid entry in the input fields, etc. Obviously, errors that
are not domain related, such as software errors, need not be discussed here.
 Sample dialogs: These serve as examples illustrating the use case.
 Specific user interface requirements: These contain specific requirements for the
user interface of the use case. For example, it may contain forms to be used, screen
shots, interaction style, etc.

25
 Software Engineering, Subject code: 17CS601, Unit -3

 Document references: This part contains references to specific domain-related

documents which may be useful to understand the system operation.
UML offers three mechanisms for factoring of use cases as follows:
 Generalization :
o Use case generalization can be used when one use case that is similar to
another, but does something slightly differently or something more.
Generalization works the same way with use cases as it does with classes.
o The child use case inherits the behavior and meaning of the parent use case. It
is important to remember that the base and the derived use cases are separate
use cases and should have separate text descriptions.
 Includes
o The includes relationship in the older versions of UML (prior to UML 1.1) was
known as the uses relationship. The includes relationship involves one use case
including the behavior of another use case in its sequence of events and actions.
o The includes relationship occurs when a chunk of behavior that is similar
across a number of use cases. The factoring of such behavior will help in not
repeating the specification and implementation across different use cases.
o Thus, the includes relationship explores the issue of reuse by factoring out the
commonality across use cases. It can also be gainfully employed to decompose
a large and complex use cases into more manageable parts. the includes
relationship is represented using a predefined stereotype <<include>>. In the
includes relationship, a base use case compulsorily and automatically includes
the behavior of the common use cases.
 Extends
o The main idea behind the extends relationship among the use cases is that it
allows you to show optional system behavior. An optional system behavior is
extended only under certain conditions.
o The extends relationship is similar to generalization. But unlike generalization,
the extending use case can add additional behavior only at an extension point
only when certain conditions are satisfied.
o The extension points are points within the use case where variation to the
mainline (normal) action sequence may occur. The extends relationship is
normally used to capture alternate paths or scenarios.
Example of use case
 It is observed that there are three different actors in the case of library management system.
Those are librarian, member, and library clerk.
 Each perform different work separately to make the system successful.
 There is a library catalog, which store the information about the books i.e., it is just like a
database management system.

26
 Software Engineering, Subject code: 17CS601, Unit -3

The text description of the use case add member is described as follows:

Text description

U1: Add membership: using this use case, the Librarian add the member to the library list by
the information provided by them.

Scenario 1: Mainline Sequence

1. User : request the librarian to add them as a member in the library system
2. Librarian: display prompt to enter information like name, address, registration number
3. User: enter necessary information
4. Librarian: display the generated id and add the user as a member for the library system.

Scenario 2: at the step 4 of mainline scenario

4. Librarian: display the message that the user has already registered.

Scenario 3: at the step 4 of mainline scenario

4. Librarian: Display message that some input information have not been entered or entered
as wrong and ask the user to reenter the same information.

27
 Software Engineering, Subject code: 17CS601, Unit -3

 Like the above use case description, the text description for each use cases need to be
written for the clarity of the use case mentioned.

14. Discuss the different types of diagrams in structural view with example.

 The structural view gives us an idea about the structure of the program. In object oriented
system, the class diagram is the basic unit and the object diagram gives an instance of the
class diagram.

Class diagram

 A class diagram describes the static structure of a system. It shows how a system is
structured rather than how it behaves. The static structure of a system comprises of a
number of class diagrams and their dependencies.
 The main constituents of a class diagram are classes and their relationships: generalization,
aggregation, association, and various kinds of dependencies.
Classes
 The classes represent entities with common features, i.e. attributes and operations. Classes
are represented as solid outline rectangles with compartments. Classes have a mandatory
name compartment where the name is written centered in boldface.
 The class name is usually written using mixed case convention and begins with an
uppercase. The class names are usually chosen to be singular nouns. Classes have optional
attributes and operations compartments. A class may appear on several diagrams. Its
attributes and operations are suppressed on all but one diagram.
Attributes
 An attribute is a named property of a class. It represents the kind of data that an object
might contain. Attributes are listed with their names, and may optionally contain
specification of their type, an initial value, and constraints.
 The type of the attribute is written by appending a colon and the type name after the
attribute name. Typically, the first letter of an attribute name is a small letter.
Operation
 Operation is the implementation of a service that can be requested from any object of the
class to affect behavior. An object’s data or state can be changed by invoking an operation
of the object. A class may have any number of operations or no operation at all.
 Typically, the first letter of an operation name is a small letter. Abstract operations are
written in italics. The parameters of an operation (if any), may have a kind specified, which
may be ‘in’, ‘out’ or ‘in-out’. An operation may have a return type consisting of a single
return type expression.

28
 Software Engineering, Subject code: 17CS601, Unit -3

Association
 Associations are needed to enable objects to communicate with each other. An association
describes a connection between classes. The association relation between two objects is
called object connection or link. Links are instances of associations.
 A link is a physical or conceptual connection between object instances. Usually, an
association is a binary relation (between two classes). However, three or more different
classes can be involved in an association.
 A class can have an association relationship with itself (called recursive association). In
this case, it is usually assumed that two different objects of the class are linked by the
association relationship.
 Association between two classes is represented by drawing a straight line between the
concerned classes. The name of the association is written along side the association line.
An arrowhead may be placed on the association line to indicate the reading direction of the
association.
 The arrowhead should not be misunderstood to be indicating the direction of a pointer
implementing an association. On each side of the association relation, the multiplicity is
noted as an individual number or as a value range. The multiplicity indicates how many
instances of one class are associated with each other. Observe that associations (and links)
appear as verbs in the problem statement.
Aggregation

 Aggregation is a special type of association where the involved classes represent a whole-
part relationship. The aggregate takes the responsibility of forwarding messages to the
appropriate parts.
 Thus, the aggregate takes the responsibility of delegation and leadership. When an instance
of one object contains instances of some other objects, then aggregation (or composition)
relationship exists between the composite object and the component object. Aggregation is
represented by the diamond symbol at the composite end of a relationship.
 Aggregation relationship cannot be reflexive (i.e. recursive). That is, an object cannot
contain objects of the same class as itself. Also, the aggregation relation is not symmetric.
That is, two classes A and B cannot contain instances of each other. However, the
aggregation relationship can be transitive. In this case, aggregation may consist of an
arbitrary number of levels.
Composition
 Composition is a stricter form of aggregation, in which the parts are existence-dependent
on the whole. This means that the life of the parts closely ties to the life of the whole. When
the whole is created, the parts are created and when the whole is destroyed, the parts are
destroyed.
 A typical example of composition is an invoice object with invoice items. As soon as the
invoice object is created, all the invoice items in it are created and as soon as the invoice
object is destroyed, all invoice items in it are also destroyed. The composition relationship
is represented as a filled diamond drawn at the composite-end.

29
 Software Engineering, Subject code: 17CS601, Unit -3

Example of class diagram

 From the diagram, it is found out that there are 11 different classes are there such as Library
catalog, Library employee, Library, Book, Librarian, Library clerk, Member, Reference
book, Course book, Student, Member, and Employee.
 Each class diagram consist of three parts. First part gives an information about the name
of the class, the second section inform about the data member of class and the third section
inform about the member functions in the class.
 The data member inform about the data member and the return types like Name is of String
type. ‘-’ sign inform about the access specifier, the ‘-’ indicates that the access specifier is
private.
 The member functions mentioned has ‘+’ mark at the start, which informs that the function
has an access specifier public.
 The classes are associated with different relations like association, aggregation and
composition mentioned by the arrows connecting the classes.

Object diagram

30
 Software Engineering, Subject code: 17CS601, Unit -3

 Object diagrams can be described as an instance of class diagram. So these diagrams are
more close to real life scenarios where we implement a system. Object diagrams are a set
of objects and their relationships just like class diagrams and also represent the static view
of the system.
 The usage of object diagrams is similar to class diagrams but they are used to build
prototype of a system from practical perspective.
 The following example explain about the object diagram.

 From the diagram is observed that “CSIT : Library ”, it informs that the CSIT is an object
of class Library.
 Similarly the object name is mentioned than ‘:’ and finally the class name to inform that
the object belongs the class name.

15. What do you mean by sequence diagram? Explain with example

 A sequence diagram shows interaction among objects as a two dimensional chart. The chart
is read from top to bottom. The objects participating in the interaction are shown at the top
of the chart as boxes attached to a vertical dashed line. Inside the box the name of the object
is written with a colon separating it from the name of the class and both the name of the
object and the class are underlined.
 The objects appearing at the top signify that the object already existed when the use case
execution was initiated. However, if some object is created during the execution of the use
case and participates in the interaction (e.g. a method call), then the object should be shown
at the appropriate place on the diagram where it is created.
 vertical dashed line is called the object’s lifeline. The lifeline indicates the existence of the
object at any particular point of time. The rectangle drawn on the lifetime is called the
activation symbol and indicates that the object is active as long as the rectangle exists.
 Each message is indicated as an arrow between the lifeline of two objects. The messages
are shown in chronological order from the top to the bottom. That is, reading the diagram
from the top to the bottom would show the sequence in which the messages occur.
 Each message is labeled with the message name. Some control information can also be
included. Two types of control information are particularly valuable.
31
 Software Engineering, Subject code: 17CS601, Unit -3

 A condition (e.g. [invalid]) indicates that a message is sent, only if the condition
is true.
 An iteration marker shows the message is sent many times to multiple receiver
objects as would happen when a collection or the elements of an array are being
iterated. The basis of the iteration can also be indicated

 The above diagram inform about the class name at the top of each lifeline inside a rectangle
box.
 The dotted line is the life line for the class element. When a class send a message to another
class, it perform that through an arrow with a label mentioned to that.

16. Explain the collaboration diagram

 A collaboration diagram shows both structural and behavioral aspects explicitly. This is
unlike a sequence diagram which shows only the behavioral aspects.
 The structural aspect of a collaboration diagram consists of objects and the links existing
between them. In this diagram, an object is also called a collaborator.
 The behavioral aspect is described by the set of messages exchanged among the different
collaborators.
 The link between objects is shown as a solid line and can be used to send messages between
two objects. The message is shown as a labeled arrow placed near the link. Messages are

32
 Software Engineering, Subject code: 17CS601, Unit -3

prefixed with sequence numbers because they are only way to describe the relative
sequencing of the messages in this diagram.
 The second interaction diagram is collaboration diagram. It shows the object organization
as shown below. Here in collaboration diagram the method call sequence is indicated by
some numbering technique as shown below.
 The number indicates how the methods are called one after another. We have taken the same
order management system to describe the collaboration diagram. The method calls are
similar to that of a sequence diagram.
 But the difference is that the sequence diagram does not describe the object organization
whereas the collaboration diagram shows the object organization. Now to choose between
these two diagrams the main emphasis is given on the type of requirement.
 If the time sequence is important then sequence diagram is used and if organization is
required then collaboration diagram is used. An interaction diagram emphasizes the
structural organization of the objects that send and receive messages.
 The following diagram gives an example of collaboration diagram:

 It is found out from above diagram that the steps needed is number from one to n. The
step one is first executed then the next step until the last one.
 The collaboration diagram is quite same as that of sequence diagram, the only
difference between these two diagram is the way they represent.
 In sequence diagram, the object are shown with their life lines and the communication
in carried out between two objects.

33
 Software Engineering, Subject code: 17CS601, Unit -3

 However, in collaboration diagram each class is represented as an entity and the

communication between the entities are shown as sequence of steps.

17. Explain about state chart diagram

 A state chart diagram normally used to model how the state of an object change in its
lifetime. These are good at describing the behavior of an object change across several use
case executions.
 State chart diagrams are based on finite state machine formalism. A good FSM consist of a
finite number of states corresponding to that of the object being modelled. The object
undergoes state changes when specific event occur.
 A major disadvantage of the FSM formalism is the state explosion problem. The number of
states became too many and difficult to control.
 Actions are associated with transactions and are considered to be processes that occur
quickly and are not interruptible. Activities are associated with states and can take longer.
An activity can be interrupted by an event.
 The basic element of the state chart diagram are as follows:
 Initial state: this is represented by a filled circle.
 Final state: this is represented by a filled circle inside a larger circle
 State: these are represented by rectangles with rounded corners
 Transitions : a transition is shown as an arrow between two states. Normally, the
name of the event which causes the transition is places along side of the arrow. We
can assign a guard condition to the transition. A guard is a Boolean logic condition.
The transition can take place only if the guard condition is true.
 The following diagram give example of state chart diagram

Order received

Unprocessed order

[Reject] checked [Accept] checked

Rejected order Accepted order

[All items available]
[Some items not
processed/deliver
available] processed

Pending order Fulfilled order

[all items available] new

[Some items not available] new supply
supply
34
 Software Engineering, Subject code: 17CS601, Unit -3

18. Explain about activity diagram

 The activity diagram is one modelling element which was not present in any of the
predecessors of UML. No such diagram is present either in the works of Booch, Jacobson,
or Rambaugh. It is possibly based on the event diagram of Odell.
 The diagram focuses on representing various activities or chunks of processing and their
sequence of activation. An activity is a state with an internal action and one or more
outgoing transactions, which automatically follow the termination of the internal process.
 Activity diagrams are similar to that of procedural flow charts. The main difference is that
activity diagram support description of parallel activity and synchronization aspects
involved in different activities.
 Parallel activities are represented on an activity diagram by using swim lanes. Swim lanes
enables us to group activities based on who is performing them. Thus, swim lane subdivide
activities based on the responsibilities of some components.
 The activity diagram are normally employed in business processing modelling. This is
carried out in the initial phase or requirement analysis and specification. It can be very
much useful in understanding complex processing activities involving the role played by
many components.
 The following diagram gives an example of activity diagram.

35
 Software Engineering, Subject code: 17CS601, Unit -3

19. Explain about Component diagram

 It shows the organizations and dependencies among a set of components. Component
diagrams are different in terms of nature and behavior. Component diagrams are used to
model physical aspects of a system.
 Now the question is what are these physical aspects? Physical aspects are the elements like
executable, libraries, files, documents etc. which resides in a node.
 So component diagrams are used to visualize the organization and relationships among
components in a system. These diagrams are also used to make executable systems.

 Now the usage of component diagrams can be described as:

o Model the components of a system.
o Model database schema.
o Model executable of an application.
o Model system source code

36
 Software Engineering, Subject code: 17CS601, Unit -3

20. Explain about deployment diagram

 It shows the configuration of run-time processing nodes and the components that are part
of them. Deployment diagrams are used to visualize the topology of the physical
components of a system where the software components are deployed.
 So deployment diagrams are used to describe the static deployment view of a system.
Deployment diagrams consist of nodes and their relationships.
 So the usage of deployment diagrams can be described as follows:
 To model the hardware topology of a system.
 To model embedded system.
 To model hardware details for a client/server system.
 To model hardware details of a distributed application.
 Forward and reverse engineering.
 The following diagram gives an example of deployment diagram

37
 Software Engineering, Subject code: 17CS601, Unit -3

21. Explain about object oriented analysis and design principle.

 OOA focuses on the problem domain and OOD concentrates on the solution domain. OOA
and OOD help OOP in implementation of the system. Thus, OOA, OOD, and OOP work
together for the development of software system.
 Thus, object-oriented software development employs OOA, OOD, and OOP. Development
of software using object-oriented analysis and object-oriented design methods is pictorially
as shown below:
 The main activities of OOSD are as follows
 Project Initiation
 Requirement Engineering
 System Design
 Object Design
 Implementation
 Testing
 Deployment
 A project is initiated when a need emerges in the society for the automation of the
organizational activities. Needs are converted into the problem statement either by the
development team, especially through the project manager, or by the customer, especially
by the end user.
 During requirement engineering, requirements are discovered, analyzed, and specified in
the requirements document.
 The solution for a system is planned keeping in view the aspects of user and system
requirements. The main focus of system design is to decide the overall structure ad style
of the system architecture.

38
 Software Engineering, Subject code: 17CS601, Unit -3

 Object design maps the analysis model to implementation of subsystems. It provides the
basis of implementation but it is the not actual implementation in any programming
language.
 Implementation is the phase of translating design into coding. Object-oriented
programming languages such as C++, Java, Smalltalk, etc., are used for coding. The
implementation phase covers the implementation of data structures for attributes and
methods for operations in the object diagrams.
 There exist various object-oriented design tools that produce object oriented source codes
in an abstract form. In this case, mapping approaches are used for mapping the designs into
codes. These are model transformations, refactoring, forward engineering and reverse
engineering.
 Source codes are tested to uncover errors, faults, and failures in the system. Various
components are tested separately to detect any unusual behavior in the system. Thereafter,
testing is performed in an integrated environment on the system as a whole.

22. Explain about software architecture.

 Software Architecture is an evolving discipline in the modern society of software

development. Software Architecture typically refers to the bigger structures of a software
system, and it deals with how multiple software processes cooperate to carry out their tasks.
Software Design refers to the smaller structures and it deals with the internal design of a
single software process.
 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. These decisions
comprise of −
 Selection of structural elements and their interfaces by which the system is
composed.
 Behavior as specified in collaborations among those elements.
 Composition of these structural and behavioral elements into large subsystem.
 Architectural decisions align with business objectives.
 Architectural styles guide the organization.

Importance of software architecture

39
 Software Engineering, Subject code: 17CS601, Unit -3

 Software architecture is the overall design of some common patterns. The understanding
of architectural paradigm can help to p [produce a new system from the existing system.
 Software architecture plays the role of a bridge between requirements and implementation.
Deciding the right architecture is crucial to the success of the most software systems. For
example, this is one of the reasons of the success of UNIX operating system as compared
to other operating systems.

Benefit of software architecture

 Understanding and communion among stakeholders: There are various stakeholders

involved in a project and each stakeholder wants to understand the system architecture.
Software architecture is comprised of all major parts and these are specified through
abstraction. Thus, architectural description provides stakeholders a common language to
understand communication on, have consensus on, and negotiate on the structure.
 Early decision stages: software Architecture provides the structural organization of
software. The implementation issues can be specified in the structural elements. Software
Architecture provides the project development structure, which helps in deciding the
resources early in the system development.
 Promotes Reuse: At the source codes are reused, the architectural decisions can also be
reused at multiple levels. Reusable libraries are designed to manage common architectures
that can be used in product line software. Product line software shares common
architectural frameworks.
 Analyzing and describing the high level properties of a software system: Deciding and
fixing system properties from the architectural design is more beneficial than detecting and
correcting them during development and implementation.
 Construction and Evolution: The components and their subparts and dependencies
among them are highlighted in the architectural description, which helps in development.
Software Architecture indicates the components that can evolve over time.

40
 Software Engineering, Subject code: 17CS601, Unit -3

 Management: A bad Architecture will always need much effort in managing and leading
to the success of a project. The right architecture is critical to the success of the product
development and product. The right architecture also helps in understanding requirements,
Implementation strategies, and Maintenance and potential risks.

23. Write short notes on common architectural design

The following table lists architectural styles that can be organized by their key focus area

Category Architectural Design Description

Message bus Prescribes use of a software system

that can receive and send messages
using one or more communication
channels.
Communication
Service–Oriented Architecture (SOA) Defines the applications that expose
and consume functionality as a
service using contracts and
messages.

Client/server Separate the system into two

applications, where the client makes
requests to the server.

Deployment
3-tier or N-tier Separates the functionality into
separate segments with each
segment being a tier located on a
physically separate computer.

Domain Domain Driven Design Focused on modeling a business

domain and defining business
objects based on entities within the
business domain.

41
 Software Engineering, Subject code: 17CS601, Unit -3

Component Based Breakdown the application design

into reusable functional or logical
components that expose well-
defined communication interfaces.

Layered Divide the concerns of the

application into stacked groups
Structure
(layers).

Object oriented Based on the division of

responsibilities of an application or
system into objects, each containing
the data and the behavior relevant to
the object.

---

Weblinks:

1.[Link]

2. [Link]

Important questions

1. Explain about software design and its process

2. List out the characteristics of good software design
3. What are the design principles of a good software design?
4. What do you mean by coupling? Discuss its type
5. What do you mean by cohesion? Discuss its type
6. What do you mean by DFD? Discuss symbols used in DFD
7. What do you mean by synchronous and asynchronous operations in DFD with
diagram
8. What do you mean by data dictionary? Discuss operation used in it
9. What do you mean by transaction analysis in DFD? Explain with example
10. What do you mean by transform analysis in DFD? Explain with example
11. Discuss about object oriented design principle.

42
 Software Engineering, Subject code: 17CS601, Unit -3

12. What do you mean by UML diagram? Discuss its type

13. What is use case diagram? Explain with an example
14. What is Structural view of UML diagram? Explain with an example
15. What is sequence diagram? Explain with an example
16. What is state chart diagram? Explain with an example
17. What is activity diagram? Explain with an example

43