University Institute of Engineering

DEPARTMENT OF COMPUTER SCIENCE

& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Function Oriented Design

• Data Flow Diagram

2
 Function Oriented Design

• In function-oriented design, the system is comprised of many smaller

sub-systems known as functions.
• These functions are capable of performing significant task in the
system.
• The system is considered as top view of all functions.
• This design mechanism divides the whole system into smaller
functions, which provides means of abstraction by concealing the
information and their operation.

3
 Function Oriented Design

• Another characteristic of functions is that when a program calls a

function, the function changes the state of the program, which
sometimes is not acceptable by other modules.
• Function Oriented design is a method to software design where the
model is decomposed into a set of interacting units or modules where
each unit or module has a clearly defined function.
• Thus, the system is designed from a functional viewpoint.

4
 Design Notations

• Design Notations are primarily meant to be used during the process of

design and are used to represent design or design decisions.
• For a function-oriented design, the design can be represented
graphically or mathematically by the following:
•

5
 Data Flow Diagram

• Data-flow design is concerned with designing a series of functional

transformations that convert system inputs into the required outputs.
• The design is described as data-flow diagrams.
• These diagrams show how data flows through a system and how the
output is derived from the input through a series of functional
transformations.
• Data-flow design is an integral part of several design methods, and
most CASE tools support data-flow diagram creation.
• Different ways may use different icons to represent data-flow diagram
entities, but their meanings are similar.

6
 Data Flow Diagram

• The notation which is used is based on the following symbols:

7
Data Flow Diagram

8
 Example
• The report generator produces a report which describes all of the
named entities in a data-flow diagram.
• The user inputs the name of the design represented by the diagram.
• The report generator then finds all the names used in the data-flow
diagram.
• It looks up a data dictionary and retrieves information about each
name.
• This is then collated into a report which is output by the system.

9
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.
Image references
https://www.javatpoint.com/software-engineering-data-flow-diagrams

10
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Data Dictionary

• Structured Chart

• Pseudo Code

13
 Data Dictionaries

• A data dictionary lists all data elements appearing in the DFD model
of a system.
• The data items listed contain all data flows and the contents of all data
stores looking on the DFDs in the DFD model of a system.
• A data dictionary lists the objective of all data items and the definition
of all composite data elements in terms of their component data items.

14
 Data Dictionaries

• For example, a data dictionary entry may contain that the

data grossPay consists of the parts regularPay and overtimePay.
•
• grossPay = regularPay + overtimePay
• For the smallest units of data elements, the data dictionary lists their
name and their type.

15
 Data Dictionaries
• A data dictionary plays a significant role in any software development
process because of the following reasons:
• A Data dictionary provides a standard language for all relevant
information for use by engineers working in a project. A consistent
vocabulary for data items is essential since, in large projects, different
engineers of the project tend to use different terms to refer to the same
data, which unnecessarily causes confusion.
• The data dictionary provides the analyst with a means to determine the
definition of various data structures in terms of their component
elements.
16
 Structured Charts
• It partitions a system into block boxes. A Black box system that
functionality is known to the user without the knowledge of internal
design.
•

17
 Structured Charts
• Structured Chart is a graphical representation which shows:
• System partitions into modules
• Hierarchy of component modules
• The relation between processing modules
• Interaction between modules
• Information passed between modules

18
 Structured Charts
• The following notations are used in structured chart:

19
 Pseudo Code
• Pseudo Code is system description in short English like phrases
describing the function.
• It use keyword and indentation. Pseudo codes are used as replacement
for flow charts.
• It decreases the amount of documentation required.

20
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.

Reference Website
1. https://www.geeksforgeeks.org/software-engineering-structure-charts/

21
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Object Oriented Design

24
 Object Oriented Design
• In the object-oriented design method, the system is viewed as a
collection of objects (i.e., entities).
• The state is distributed among the objects, and each object handles its
state data.
• For example, in a Library Automation Software, each library
representative may be a separate object with its data and functions to
operate on these data.

25
 Object Oriented Design
• The tasks defined for one purpose cannot refer or change data of other
objects.
• Objects have their internal data which represent their state. Similar
objects create a class.
• In other words, each object is a member of some class. Classes may
inherit features from the super class.

26
Object Oriented Design

27
 Object Oriented Design
• Objects: All entities involved in the solution design are known as
objects.
• For example, person, banks, company, and users are considered as
objects.
• Every entity has some attributes associated with it and has some
methods to perform on the attributes.

28
 Object Oriented Design
• Classes:
• A class is a generalized description of an object. An object is an
instance of a class.

• A class defines all the attributes, which an object can have and
methods, which represents the functionality of the object.

29
 Object Oriented Design
• Messages:
• Objects communicate by message passing.
• Messages consist of the integrity of the target object, the name of the
requested operation, and any other action needed to perform the
function.
• Messages are often implemented as procedure or function calls.

30
 Object Oriented Design
• Abstraction In object-oriented design, complexity is handled using
abstraction.
• Abstraction is the removal of the irrelevant and the amplification of
the essentials.
• Encapsulation: Encapsulation is also called an information hiding
concept.
• The data and operations are linked to a single unit. Encapsulation not
only bundles essential information of an object together but also
restricts access to the data and methods from the outside world.

31
 Object Oriented Design
• Inheritance:
• OOD allows similar classes to stack up in a hierarchical manner where
the lower or sub-classes can import, implement, and re-use allowed
variables and functions from their immediate super classes.
• This property of OOD is called an inheritance.
• This makes it easier to define a specific class and to create generalized
classes from specific ones.

32
 Object Oriented Design
• Polymorphism:
• OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned the same name.
• This is known as polymorphism, which allows a single interface is
performing functions for different types.
• Depending upon how the service is invoked, the respective portion of
the code gets executed.

33
Advanatges
• The OO model is beneficial in the following ways −
• It facilitates changes in the system at low cost.
• It promotes the reuse of components.
• It simplifies the problem of integrating components to configure large
system.
• It simplifies the design of distributed systems.

34
Stages of Object Oriented Design
• The stages for object–oriented design can be identified as −
• Definition of the context of the system
• Designing system architecture
• Identification of the objects in the system
• Construction of design models
• Specification of object interfaces

35
36
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.

37
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Unified Modeling Language

40
 Unified Modeling Language
•
• Unified Modeling Language (UML) is a general purpose modeling
language.
• The main aim of UML is to define a standard way to visualize the way
a system has been designed.
• It is quite similar to blueprints used in other fields of engineering.

41
 Unified Modeling Language
• UML is not a programming language, it is rather a visual language.

• We use UML diagrams to portray the behavior and structure of a

system.

• UML helps software engineers, businessmen and system architects

with modeling, design and analysis

42
 Need of UML
• Complex applications need collaboration and planning from multiple
teams and hence require a clear and concise way to communicate
amongst them.
• Businessmen do not understand code. So UML becomes essential to
communicate with non programmers essential requirements,
functionalities and processes of the system.
• A lot of time is saved down the line when teams are able to visualize
processes, user interactions and static structure of the system.

43
 Classification of UML
• Diagrams in UML can be broadly classified as:
• Structural Diagrams – Capture static aspects or structure of a system.
Structural Diagrams include: Component Diagrams, Object Diagrams,
Class Diagrams and Deployment Diagrams.
• Behavior Diagrams – Capture dynamic aspects or behavior of the
system. Behavior diagrams include: Use Case Diagrams, State
Diagrams, Activity Diagrams and Interaction Diagrams.

44
Classification of UML

45
 Structural UML Diagrams
• Class Diagram –
• The most widely use UML diagram is the class diagram. It is the
building block of all object oriented software systems.
• We use class diagrams to depict the static structure of a system by
showing system’s classes, their methods and attributes.
• Class diagrams also help us identify relationship between different
classes or objects.

46
 Class Diagram

• The purpose of class diagram is to model the static view of an

application.
• Class diagrams are the only diagrams which can be directly mapped
with object-oriented languages and thus widely used at the time of
construction.
• The purpose of the class diagram −
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.
47
 Class Diagram

• The following points should be remembered while drawing a class diagram −

• The name of the class diagram should be meaningful to describe the aspect of the system.
• Each element and their relationships should be identified in advance.
• Responsibility (attributes and methods) of each class should be clearly identified
• For each class, minimum number of properties should be specified, as unnecessary
properties will make the diagram complicated.
• Use notes whenever required to describe some aspect of the diagram. At the end of the
drawing it should be understandable to the developer/coder.
• Finally, before making the final version, the diagram should be drawn on plain paper and
reworked as many times as possible to make it correct.

48
Class Diagram : Example

49
 Where to Use Class Diagrams?

• Describing the static view of the system.

• Showing the collaboration among the elements of the static view.
• Describing the functionalities performed by the system.
• Construction of software applications using object oriented languages.

50
 Structural UML Diagrams
• Composite Structure Diagram –
• We use composite structure diagrams to represent the internal structure of a class
and its interaction points with other parts of the system.
• A composite structure diagram represents relationship between parts and their
configuration which determine how the classifier (class, a component, or a
deployment node) behaves.
• They represent internal structure of a structured classifier making the use of parts,
ports, and connectors.
• We can also model collaborations using composite structure diagrams.
• They are similar to class diagrams except they represent individual parts in detail
as compared to the entire class.
51
 Structural UML Diagrams
• Object Diagram
• An Object Diagram can be referred to as a screenshot of the instances
in a system and the relationship that exists between them.
• Since object diagrams depict behavior when objects have been
instantiated, we are able to study the behavior of the system at a
particular instant.

52
 Structural UML Diagrams
• Object diagrams are derived from class diagrams so object diagrams
are dependent upon class diagrams.
• Object diagrams represent an instance of a class diagram. The basic
concepts are similar for class diagrams and object diagrams.
• Object diagrams also represent the static view of a system but this
static view is a snapshot of the system at a particular moment.
• Object diagrams are used to render a set of objects and their
relationships as an instance.

53
 Structural UML Diagrams
• The purpose of the object diagram can be summarized as −
• Forward and reverse engineering.
• Object relationships of a system
• Static view of an interaction.
• Understand object behaviour and their relationship from practical
perspective

54
Structural UML Diagrams

55
 Structural UML Diagrams
The following points are to be decided before starting the construction
of the diagram −
• The object diagram should have a meaningful name to indicate its
purpose.
• The most important elements are to be identified.
• The association among objects should be clarified.
• Values of different elements need to be captured to include in the
object diagram.
• Add proper notes at points where more clarity is required.

56
 Structural UML Diagrams
• Component Diagram
• Component diagrams are used to represent the how the physical
components in a system have been organized.
• We use them for modeling implementation details.
• Component Diagrams depict the structural relationship between
software system elements and help us in understanding if functional
requirements have been covered by planned development.

57
 Structural UML Diagrams
• Component Diagram
• Component diagram is a special kind of diagram in UML.
• It does not describe the functionality of the system but it describes
the components used to make those functionalities.
• Thus from that point of view, component diagrams are used to
visualize the physical components in a system. These components are
libraries, packages, files, etc.

58
 Structural UML Diagrams
The purpose of the component diagram can be summarized as −
• Visualize the components of a system.
• Construct executables by using forward and reverse engineering.
• Describe the organization and relationships of the components.
Component diagrams can be used to −
• Model the components of a system.
• Model the database schema.
• Model the executables of an application.
• Model the system's source code.

59
Component Diagram

60
 Structural UML Diagrams
• Deployment Diagram –
• Deployment Diagrams are used to represent system hardware and its
software.
• It tells us what hardware components exist and what software components
run on them.
• We illustrate system architecture as distribution of software artifacts over
distributed targets.
• An artifact is the information that is generated by system software.
• They are primarily used when a software is being used, distributed or
deployed over multiple machines with different configurations.

61
 Structural UML Diagrams
• Deployment diagrams are used for describing the hardware
components, where software components are deployed.
• Component diagrams and deployment diagrams are closely related.
• Component diagrams are used to describe the components and
deployment diagrams shows how they are deployed in hardware.
• The purpose of deployment diagrams can be described as −
• Visualize the hardware topology of a system.
• Describe the hardware components used to deploy software
components.
• Describe the runtime processing nodes.
62
 Deployment Diagram
• Deployment diagrams can be used −
• To model the hardware topology of a system.
• To model the embedded system.
• To model the hardware details for a client/server system.
• To model the hardware details of a distributed application.
• For Forward and Reverse engineering.

63
Deployment Diagram

64
 Structural UML Diagrams
• Package Diagram
• We use Package Diagrams to depict how packages and their elements
have been organized.
• A package diagram simply shows us the dependencies between
different packages and internal composition of packages.
• Packages help us to organize UML diagrams into meaningful groups
and make the diagram easy to understand.
• They are primarily used to organize class and use case diagrams.

65
 Structural UML Diagrams
• Package Diagram
• A package is a grouping of model elements which means that a
package can contain model elements of different kinds, including
other packages to create hierarchies.
• Package diagram is used to simplify complex class diagrams, you can
group classes into packages.
• A package is a collection of logically related UML elements.

66
Package Diagram

67
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.
Image References:
https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/
https://www.uml.org/

68
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Behavior Diagrams

• Use case Diagrams

71
 Behavior Diagrams
• Sequence Diagram
• A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place.
• We can also use the terms event diagrams or event scenarios to refer to
a sequence diagram.
• Sequence diagrams describe how and in what order the objects in a
system function.
• These diagrams are widely used by businessmen and software
developers to document and understand requirements for new and
existing systems.

72
 Behavior Diagrams
• Sequence Diagram
• Sequence diagram describes an interaction by focusing on the sequence of
messages that are exchanged, along with their corresponding occurrence
specifications on the lifelines.
• Sequence diagram is used to:
• Represent the details of a UML use case.
• Model the logic of a sophisticated procedure, function, or operation.
• See how objects and components interact with each other to complete a
process.
• Plan and understand the detailed functionality of an existing or future
scenario.
73
Sequence Diagram

74
 Behavior Diagrams
• Communication Diagram
• A Communication Diagram(known as Collaboration Diagram in UML
1.x) is used to show sequenced messages exchanged between objects.
• A communication diagram focuses primarily on objects and their
relationships.
• We can represent similar information using Sequence diagrams,
however, communication diagrams represent objects and links in a
free form.

75
 Behavior Diagrams
• Communication Diagram
• Communication diagrams offer benefits similar to sequence diagrams,
but they will offer a better understanding of how components
communicate and interact with each other rather than solely
emphasizing the sequence of events.
• They can be a useful reference for businesses, organizations, and
engineers who need to visualize and understand the physical
communications within a program.

76
 Behavior Diagrams
• Communication Diagram

• Model the logic of a sophisticated procedure, function, or operation.

• Identify how commands are sent and received between objects or
components of a process.
• Visualize the consequences of specific interactions between various
components in a process.
• Plan and understand the detailed functionality of an existing or future
scenario.

77
Communication Diagram

78
 Behavior Diagrams
• Timing Diagram

• Timing Diagram are a special form of Sequence diagrams which are used to
depict the behavior of objects over a time frame.
• We use them to show time and duration constraints which govern changes
in states and behavior of objects.
• Timing diagrams are UML interaction diagrams used to show interactions
when a primary purpose of the diagram is to reason about time. Timing
diagrams focus on conditions changing within and among lifelines along a
linear time axis. Timing diagrams describe behavior of both
individual classifiers and interactions of classifiers, focusing attention on
time of events causing changes in the modeled conditions.

79
 Behavior Diagrams
• Timing Diagram

80
 Behavior Diagrams
• Use Case Diagrams
• Use Case Diagrams are used to depict the functionality of a system or
a part of a system.
• They are widely used to illustrate the functional requirements of the
system and its interaction with external agents(actors).
• A use case is basically a diagram representing different scenarios
where the system can be used.

81
 Use Case Diagrams
The purposes of use case diagrams can be said to be as follows
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors influencing the system.
• Show the interaction among the requirements are actors.

82
Use Case Diagrams

83
 Use Case Diagrams
• Use case diagrams can be used for −
• Requirement analysis and high level design.
• Model the context of a system.
• Reverse engineering.
• Forward engineering.

84
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.
Image Reference
https://www.uml.org/
https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/

85
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Interaction Diagram

• Activity Diagram

• State Chart Diagram

88
 Interaction Diagram
• The purpose of interaction diagram is −
• To capture the dynamic behavior of a system.
• To describe the message flow in the system.
• To describe the structural organization of the objects.
• To describe the interaction among objects.

89
 Interaction Diagram
• Following things are to be identified clearly before drawing the
interaction diagram
• Objects taking part in the interaction.
• Message flows among the objects.
• The sequence in which the messages are flowing.
• Object organization.

90
Interaction Diagram

91
 Behavior Diagrams
• Activity Diagrams
• We use Activity Diagrams to illustrate the flow of control in a system.
• We can also use an activity diagram to refer to the steps involved in
the execution of a use case.
• We model sequential and concurrent activities using activity
diagrams. describe or depict what causes a particular event using an
activity diagram.

92
 Activity Diagram
• The purpose of an activity diagram can be described as −
• Draw the activity flow of a system.
• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.

93
 Activity Diagram
• Activity diagrams are mainly used as a flowchart that consists of
activities performed by the system. Activity diagrams are not exactly
flowcharts as they have some additional capabilities. These additional
capabilities include branching, parallel flow etc.
• Before drawing an activity diagram, we should identify the following
elements −
• Activities
• Association
• Conditions
• Constraints
94
 Activity Diagram
• Following diagram is drawn with the four main activities −
• Send order by the customer
• Receipt of the order
• Confirm the order
• Dispatch the order

95
 Activity Diagram
• Activity diagram can be used for −
• Modeling work flow by using activities.
• Modeling business requirements.
• High level understanding of the system's functionalities.
• Investigating business requirements at a later stage.

96
 State chart Diagram
• State chart diagram is one of the five UML diagrams used to model
the dynamic nature of a system. They define different states of an
object during its lifetime and these states are changed by events
• Following are the main purposes of using State chart diagrams −
• To model the dynamic aspect of a system.
• To model the life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model the states of an object.

97
 Behavior Diagrams
• State Machine Diagrams
• A state diagram is used to represent the condition of the system or part
of the system at finite instances of time.
• It’s a behavioral diagram and it represents the behavior using finite
state transitions. State diagrams are also referred to as State
machines and State-chart Diagrams .
• These terms are often used interchangeably.
• So simply, a state diagram is used to model the dynamic behavior of a
class in response to time and changing external stimuli.

98
 How to Draw a State chart Diagram?
• State chart diagram is used to describe the states of different objects
in its life cycle. Emphasis is placed on the state changes upon some
internal or external events.
• Before drawing a State chart diagram we should clarify the following
points −
• Identify the important objects to be analyzed.
• Identify the states.
• Identify the events.

99
State Chart Diagram

100
 Where to Use State chart Diagrams?
• The main usage can be described as −
• To model the object states of a system.
• To model the reactive system. Reactive system consists of reactive
objects.
• To identify the events responsible for state changes.
• Forward and reverse engineering.

101
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.
Image References
https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/
https://www.uml.org/

102
THANK YOU