University Institute of Engineering

DEPARTMENT OF COMPUTER SCIENCE &

ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 1

 Introduction to Software Engineering

Course Outcome

CO
Title Level
Number

Analyze the basic knowledge in software

CO1 engineering to learn the various software Understand
development process models.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 2

 Chapter-1
Topics covered

• Definition of software and Software engineering

• Need of Software engineering

• Objectives of Software engineering

• Software Development Life Cycle

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 3

 Software
• Software is a program or set of programs containing instructions
which provide desired functionality .

• The software is collection of Integrated programs.

• Software consists of carefully-organized instructions and code written

by programmers in any of various special computer languages.

• Computer programs and associated documentation such as

requirements, design models and user manuals.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 4
 Dual Role of Software
• 1. As a product –
• It delivers the computing potential across network of Hardware.
• It enables the Hardware to deliver the expected functionality.
• It acts as information transformer because it produces, manages,
acquires, modifies, displays, or transmits information.
• 2. As a vehicle for delivering a product –
• It provides system functionality
• It controls other software
• It helps build other software

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 5

 Program vs. Software
• Program is a set of instruction related each other where as Software
Product is a collection of program designed for specific task.
• Programs are usually small in size where as Software Products are
usually large in size.
• Programs are developed by individuals that means single user where
as Software Product are developed by large no of users.
• In program, there is no documentation or lack in proper documentation
whereas in Software Product, Proper documentation and well
documented and user manual prepared.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 6

 Program vs. Software
• Development of program is Unplanned, usually not Systematic etc but
Development of Software Product is well Systematic, organized,
planned approach.

• Programs provide Limited functionality and less features where as

Software Products provides more functionality as they are big in size
more options and features.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 7

 Software Engineering
• Software Engineering is a systematic approach to the design,
development, operation, and maintenance of a software system.

• Software engineering is an engineering discipline that’s applied to the

development of software in a systematic approach

• It’s the application of theories, methods, and tools to design build a

software that meets the specifications, cost, and ensures quality.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 8

 Software Engineering
• It is not only concerned with the technical process of building a
software, it also includes activities to manage the project, develop
tools, methods and theories that support the software production.
• Not applying software engineering methods results in more expensive,
less reliable software, and it can be vital on the long term, as the
changes come in, the costs will dramatically increase.
• Different methods and techniques of software engineering are
appropriate for different types of systems.
• For example, games should be developed using series of prototypes,
while critical control systems require a complete analyzable
specification to be developed.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 9
 Objectives of Software Engineering
• Maintainability – the ease with which changes in a functional unit can be
performed in order to meet prescribed requirements.

• Correctness – the extent to which software meets its specified requirements

• Reusability – the extent to which a module can be used in multiple

applications.

• Testability – the extent to which software facilitates both the establishment of

test criteria and the evaluation of the software with respect to those criteria.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 10
 Objectives of Software Engineering
• Reliability – an attribute of software quality. The extent to which a
program can be expected to perform its intended function, over an
arbitrary time period.

• Portability – the ease with which software can be transferred from

one computer system or environment to another.

• Adaptability – the ease with which software allows differing system

constraints and user needs to be satisfied by making changes to the
software.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 11

 Need of Software Engineering
Software Engineering is required due to the following reasons:

• To manage Large software

• For more Scalability
• Cost Management
• To manage the dynamic nature of software
• For better quality Management

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 12

Importance of Software Engineering

• Fig 1 Importance of Software Engineering

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 13

 Importance of Software Engineering
• Reduces complexity
• Software engineering has a great solution to reduce the complication
of any project.
• Software engineering divides big problems into various small issues.
• And then start solving each small issue one by one. All these small
problems are solved independently to each other.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 14

 Importance of Software Engineering
• To minimize software cost:
• Software needs a lot of hardwork and software engineers are highly
paid experts.
• But using software engineering, programmers project everything and
decrease all those things that are not needed.
• In turn, the cost for software productions becomes less as compared to
any software that does not use software engineering method.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 15

 Importance of Software Engineering
• To decrease time:
• To achieve the requirements of the software, many codes are executed
to reach the definite running code.
• This is a very time-consuming procedure, and if it is not well handled,
then this can take a lot of time.
• So if you are making your software according to the software
engineering method, then it will decrease a lot of time.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 16

 Importance of Software Engineering
• Handling big projects:
• Big projects are not done in a couple of days, and they need lots of
patience, planning, and management.
• And to invest many months of any company, it requires heaps of
planning, direction, testing, and maintenance.
• The company has provided many resources to the plan and it should be
completed well in time.
• So to handle a big project without any problem, the company has to go
for a software engineering method.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 17

 Importance of Software Engineering
• Reliable software:
• Software should be secure, means if you have delivered the software,
then it should work for at least its given time or subscription.
• And if any bugs come in the software, the company is responsible for
solving all these bugs.
• Because in software engineering, testing and maintenance are given,
so there is no worry of its reliability.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 18

 Importance of Software Engineering
• Effectiveness:
• Effectiveness comes if anything has made according to the standards.
• Software standards are the big target of companies to make it more
effective.
• So Software becomes more effective in the act with the help of
software engineering.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 19

 Software Development Life Cycle
• Software Development Life Cycle (SDLC) is a process used by the
software industry to design, develop and test high quality software.
• The SDLC aims to produce a high-quality software that meets or
exceeds customer expectations, reaches completion within times and
cost estimates.
• The life cycle defines a methodology for improving the quality of
software and the overall development process.
• It consists of a detailed plan describing how to develop, maintain,
replace and alter or enhance specific software.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 20

Software Development Life Cycle

Fig 2 Software Development Life Cycle

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 21

 Stage 1: Requirement Analysis
• Requirement analysis is the most important and fundamental stage in
SDLC.
• It is performed by the senior members of the team with inputs from the
customer, the sales department, market surveys and domain experts in the
industry.
• The information is then used to plan the basic project approach and to
conduct product feasibility study in the economical, operational and
technical areas.
• The outcome of the technical feasibility study defines various approaches
that can be followed to implement the project successfully with minimum
risks.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 22
 Stage 2: Defining Requirements
• Once the requirement analysis is done the next step is to clearly define
and document the product requirements and get them approved from
the customer or the market analysts.
• This is done through an SRS (Software Requirement
Specification) document which consists of all the product
requirements to be designed and developed during the project life
cycle

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 23

 Stage 3: Designing the Product Architecture
• Based on the requirements specified in SRS, usually more than one
design approach for the product architecture is proposed and
documented in a Design Document Specification (DDS).
• DDS is reviewed by all the important stakeholders and based on
various parameters as risk assessment, product robustness, design
modularity, budget and time constraints, the best design approach is
selected for the product.
• A design approach clearly defines all the architectural modules of the
product along with its communication and data flow representation
with the external and third party modules.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 24
 Stage 4: Building or Developing the Product
• In this stage of SDLC the actual development starts and the product is
built.
• The programming code is generated as per DDS during this stage.
• If the design is performed in a detailed and organized manner, code
generation can be accomplished without much hassle.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 25

 Stage 4: Building or Developing the Product
• Developers must follow the coding guidelines defined by their
organization and programming tools like compilers, interpreters,
debuggers, etc. are used to generate the code.
• Different high level programming languages such as C, C++, Pascal,
Java and PHP are used for coding.
• The programming language is chosen with respect to the type of
software being developed.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 26

 Stage 5: Testing the Product
• This stage is usually a subset of all the stages as in the modern SDLC
models, the testing activities are mostly involved in all the stages of
SDLC.
• However, this stage refers to the testing only stage of the product
where product defects are reported, tracked, fixed and retested, until
the product reaches the quality standards defined in the SRS.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 27

 Stage 6: Deployment in the Market and
Maintenance
• Once the product is tested and ready to be deployed it is released
formally in the appropriate market.
• Sometimes product deployment happens in stages as per the business
strategy of that organization.
• The product may first be released in a limited segment and tested in
the real business environment (UAT- User acceptance testing).

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 28

 Stage 6: Deployment in the Market and
Maintenance
• Then based on the feedback, the product may be released as it is or
with suggested enhancements in the targeting market segment.
• After the product is released in the market, its maintenance is done for
the existing customer base.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 29

 References
• https://nptel.ac.in/courses/106/105/106105182/
• https://www.tutorialspoint.com/software_engineering/index.htm
• https://www.javatpoint.com/software-engineering-tutorial
• https://www.tutorialride.com/software-engineering/software-
engineering-tutorial.htm
• https://tutorialsinhand.com/tutorials/software-engineering-
tutorial/software-engineering-introduction/software-engineering-
home.aspx

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 30

 Image References
• Fig 1
https://www.tutorialspoint.com/software_engineering/index.htm
• Fig 2
• https://www.tutorialride.com/software-engineering/software-
engineering-tutorial.htm

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 31

THANK YOU

32
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 33

 Introduction to Software Engineering

Course Outcome

CO
Title Level
Number

Define principles and working of software

CO1 Understand
process models.

Describe agile development methodology

CO2 Remember
and analyse where to apply.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 34

 Topics covered
Software Development life Cycle models

Waterfall model

Iterative Waterfall model

Prototype model

Evolutionary model

Spiral model

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 35

 Software life cycle model
• A software life cycle model is a descriptive and diagrammatic
representation of the software life cycle.

• A life cycle model represents all the activities required to make a

software product transit through its life cycle phases.

• It captures the order in which these activities are to be undertaken.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 36

CPU Classical Waterfall Model
• Classical waterfall model divides life cycle into phases:
• feasibility study,
• requirements analysis and specification,
• design,
• coding and unit testing,
• integration and system testing,
• maintenance.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 37

CLASSICAL WATERFALL MODEL

Fig 1 Classical Waterfall Model

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 38

 FEASIBILITY STUDY
• Main aim of feasibility study: determine whether developing the
product
• financially worthwhile
• technically feasible.
• First roughly understand what the customer wants:
• different data which would be input to the system,
• processing needed on these data,
• output data to be produced by the system,
• various constraints on the behaviour of the system.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 39

 FEASIBILITY STUDY
• Work out an overall understanding of the problem.
• Formulate different solution strategies.
• Examine alternate solution strategies in terms of:
• resources required,
• cost of development, and
• development time.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 40

 REQUIREMENT ANALYSIS AND
SPECIFICATION
• Aim of this phase:
• understand the exact requirements of the customer,
• document them properly.
• Consists of two distinct activities:
• requirements gathering and analysis
• requirements specification.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 41

 REQUIREMENT GATHERING
• Gathering relevant data:
• usually collected from the end-users through interviews and
discussions.
• For example, for a business accounting software:
• interview all the accountants of the organization to find out their
requirements.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 42

 REQUIREMENT ANALYSIS
• The data you initially collect from the users:
• would usually contain several contradictions and ambiguities:
• each user typically has only a partial and incomplete view of the
system.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 43

 DESIGN
• Design phase transforms requirements specification:
• into a form suitable for implementation in some programming
language.
• In technical terms:
• during design phase, software architecture is derived from the
SRS document.
• Two design approaches:
• traditional approach,
• object oriented approach.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 44

 IMPLEMENTATION
• Purpose of implementation phase (aka coding and unit testing phase):
• translate software design into source code.
• During the implementation phase:
• each module of the design is coded,
• each module is unit tested
• tested independently as a stand alone unit, and debugged,
• each module is documented.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 45

 INTEGRATION AND SYSTEM TESTING
• Different modules are integrated in a planned manner:
• modules are almost never integrated in one shot.
• Normally integration is carried out through a number of steps.
• During each integration step,
• the partially integrated system is tested.
• After all the modules have been successfully integrated and tested:
• system testing is carried out.
• Goal of system testing:
• ensure that the developed system functions according to its requirements as
specified in the SRS document.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 46

 MAINTENANCE
• Maintenance of any software product:
• requires much more effort than the effort to develop the product
itself.
• development effort to maintenance effort is typically 40:60.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 47

Advantages
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well
understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 48

Disadvantages
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 49

Application
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the
product.
• The project is short.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 50

 ITERATIVE WATERFALL MODEL
• Classical waterfall model is idealistic:
• assumes that no defect is introduced during any development activity.
• in practice:
• defects do get introduced in almost every phase of the life cycle.
• Defects usually get detected much later in the life cycle:
• For example, a design defect might go unnoticed till the coding or testing phase.
• Once a defect is detected:
• we need to go back to the phase where it was introduced
• redo some of the work done during that and all subsequent phases.
• Therefore we need feedback paths in the classical waterfall model.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 51

ITERATIVE WATERFALL MODEL

Fig 2 Iterative Waterfall Model

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 52

 PROTOTYPING MODEL
• Before starting actual development,
• a working prototype of the system should first be built.
• A prototype is a toy implementation of a system:
• limited functional capabilities,
• low reliability,
• inefficient performance.
• Start with approximate requirements.
• Carry out a quick design.
• Prototype model is built using several short-cuts:
• Short-cuts might involve using inefficient, inaccurate, or dummy functions.
• A function may use a table look-up rather than performing the actual computations.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 53

PROTOTYPING MODEL

Fig 3 Prototype model

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 54

Prototype Model

Fig 4 Steps of prototype model

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 55

Advantages
• Users are actively involved in the development
• Since in this methodology a working model of the system is provided,
the users get a better understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 56

Disadvantages
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the
system as scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as the full
system was designed Incomplete or inadequate problem analysis.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 57

When to use
• Prototype model should be used when the desired system needs to
have a lot of interaction with the end users.
• Typically, online systems, web interfaces have a very high amount of
interaction with end users, are best suited for Prototype model. It
might take a while for a system to be built that allows ease of use and
needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system
and provide a feedback which is incorporated in the prototype to result
in a useable system. They are excellent for designing good human
computer interface systems.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 58
 Evolutionary Model
• Evolutionary model (aka successive versions or incremental model):
• The system is broken down into several modules which can be incrementally
implemented and delivered.
• First develop the core modules of the system.
• The initial product skeleton is refined into increasing levels of capability:
• by adding new functionalities in successive versions.
• Successive version of the product:
• functioning systems capable of performing some useful work.
• A new release may include new functionality:
• also existing functionality in the current release might have been enhanced.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 59

Evolutionary Model

Fig 5 Evolutionary Model

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 60

 Spiral Model
• Each loop of the spiral represents a phase of the software process:
• the innermost loop might be concerned with system feasibility,
• the next loop with system requirements definition,
• the next one with system design, and so on.
• The team must decide:
• how to structure the project into phases.
• Start work using some generic model:
• add extra phases
• for specific projects or when problems are identified during a project.
• Each loop in the spiral is split into four sectors (quadrants).

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 61

 Spiral Model

Fig 6 Spiral Model

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 62

 Spiral Model
• Identify objectives of the phase,
• Examine the risks associated with these objectives.
• Risk:
• any adverse circumstance that might hamper successful
completion of a software project.
• Find alternate solutions possible.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 63

Advantages
• Changing requirements can be accommodated.
• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and the risky parts can
be developed earlier which helps in better risk management.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 64

Disadvantages
• Management is more complex.
• End of the project may not be known early.
• Not suitable for small or low risk projects and could be expensive for
small projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive
documentation.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 65

 APPLICATIONS
• Managing clients requirements in industry.
• Generating software for noticing health activities with novel smart
technologies.
• Content Management and to analyzing Fraud detection and Prevention
• Advertisements Targeting Platforms Managing content, posts, images and
videos on social media platforms
• Analyzing customer data in real-time for improving business performance
• Public sector fields such as intelligence, defense, cyber security and
scientific research

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 66

 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.javatpoint.com/software-engineering-sdlc-models

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 67

 IMAGE REFERENCES
• Fig 1 https://www.javatpoint.com/software-engineering-sdlc-models
• Fig 2 https://flexagon.com/blog/7-software-development-models-
you-should-know/
• Fig 3 https://www.javatpoint.com/software-engineering-sdlc-models
• Fig 4 https://flexagon.com/blog/7-software-development-models-
you-should-know/
• Fig 5 https://www.javatpoint.com/software-engineering-sdlc-models
• Fig 6
http://swebokwiki.org/Chapter_9:_Software_Engineering_Models

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 68

THANK YOU

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University

 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 70

 Introduction to Software Engineering

Course Outcome

CO
Title Level
Number

Define principles and working of software

CO1 Understand
process models.

Describe agile development methodology

CO2 Remember
and analyse where to apply.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 71

 Topics covered

• Agile Software Development

• V Model

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 72

 Agile software Development

• Agile is a time-bound, iterative approach to software delivery that

builds software incrementally from the start of the project, instead of
trying to deliver all at once.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 73

 Why Agile?
• Technology in this current era is progressing faster than ever,
enforcing the global software companies to work in a fast-paced
changing environment.

• The conventional software models such as Waterfall Model that

depends on completely specifying the requirements, designing, and
testing the system are not geared towards rapid software development.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 74

 Why Agile?
• As a consequence, a conventional software development model fails to
deliver the required product.
• This is where the agile software development comes to the rescue
• It was specially designed to curate the needs of the rapidly changing
environment by embracing the idea of incremental development and
develop the actual final product.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 75

 Characteristics of Agile Model
• Highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
• It welcomes changing requirements, even late in development.
• Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shortest timescale.
• Build projects around motivated individuals. Give them the
environment and the support they need, and trust them to get the job
done.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 76

 Characteristics of Agile Model
• Working software is the primary measure of progress.

• Simplicity the art of maximizing the amount of work not done is

essential.

• The most efficient and effective method of conveying information to

and within a development team is face-to-face conversation.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 77

 Development Process in Agile
• In Agile development, Design and Implementation are considered to
be the central activities in the software process.
• Design and Implementation phase also incorporate other activities
such as requirements elicitation and testing into it.
• In an agile approach, iteration occurs across activities.
• Therefore, the requirements and the design are developed together,
rather than separately.
.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 78

 Development Process in Agile
• The allocation of requirements and the design planning and
development as executed in a series of increments.
• In contrast with the conventional model, where requirements gathering
needs to be completed in order to proceed to the design and
development phase, it gives Agile development an extra level of
flexibility.
• An agile process focuses more on code development rather than
documentation.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 79

 Advantages
• Deployment of software is quicker and thus helps in increasing the
trust of the customer.
• Can better adapt to rapidly changing requirements and respond faster.
• Helps in getting immediate feedback which can be used to improve the
software in the next increment.
• People – Not Process. People and interactions are given a higher
priority rather than process and tools.
• Continuous attention to technical excellence and good design.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 80

 Disadvantages
• In case of large software projects, it is difficult to assess the effort
required at the initial stages of the software development life cycle.

• The Agile Development is more code focused and produces less

documentation.

• Agile development is heavily depended on the inputs of the customer.

If the customer has ambiguity in his vision of the final outcome, it is
highly likely for the project to get off track.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 81

 Disadvantages
• Face to Face communication is harder in large-scale organizations.
• Only senior programmers are capable of taking the kind of decisions
required during the development process.
• Hence it’s a difficult situation for new programmers to adapt to the
environment.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 82

 V Model
• The V-model is a type of SDLC model where process executes in a
sequential manner in V-shape.
• It is based on the association of a testing phase for each corresponding
development stage.
• Development of each step directly associated with the testing phase.
• The next phase starts only after completion of the previous phase i.e.
for each development activity, there is a testing activity corresponding
to it.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 83

 V Model

Fig 1 V Model

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 84

 Phases of V Model : Design Phase
• Requirement Analysis:
• This phase contains detailed communication with the customer to
understand their requirements and expectations.
• This stage is known as Requirement Gathering.
• System Design:
• This phase contains the system design and the complete hardware and
communication setup for developing product.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 85

 Phases of V Model : Design Phase
• Architectural Design: System design is broken down further into
modules taking up different functionalities.
• The data transfer and communication between the internal modules
and with the outside world (other systems) is clearly understood.

• Module Design: In this phase the system breaks down into small
modules. The detailed design of modules is specified, also known as
Low-Level Design (LLD).

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 86

 Phases of V Model : Testing Phase
• Unit Testing: Unit Test Plans are developed during module design
phase. These Unit Test Plans are executed to eliminate bugs at code or
unit level.

• Integration testing: After completion of unit testing Integration

testing is performed. In integration testing, the modules are integrated
and the system is tested. Integration testing is performed on the
Architecture design phase. This test verifies the communication of
modules among themselves.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 87

 Phases of V Model : Testing Phase
• System Testing: System testing test the complete application with its
functionality, inter dependency, and communication. It tests the
functional and non-functional requirements of the developed
application.
• User Acceptance Testing (UAT): UAT is performed in a user
environment that resembles the production environment. UAT verifies
that the delivered system meets user’s requirement and system is ready
for use in real world.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 88

 Principles of V-Model
• Large to Small: In V-Model, testing is done in a hierarchical
perspective, For example, requirements identified by the project team,
create High-Level Design, and Detailed Design phases of the project.
As each of these phases is completed the requirements, they are
defining become more and more refined and detailed.
• Data/Process Integrity: This principle states that the successful
design of any project requires the incorporation and cohesion of both
data and processes. Process elements must be identified at each and
every requirements.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 89

Principles of V-Model
• Scalability: This principle states that the V-Model concept has the
flexibility to accommodate any IT project irrespective of its size,
complexity or duration.
• Cross Referencing: Direct correlation between requirements and
corresponding testing activity is known as cross-referencing.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 90

Principles of V-Model
• Tangible Documentation: This principle states that every project
needs to create a document. This documentation is required and
applied by both the project development team and the support team.
Documentation is used to maintaining the application once it is
available in a production environment.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 91

Why Preferred
• It is easy to manage due to the rigidity of the model. Each phase of V-
Model has specific deliverables and a review process.
• Proactive defect tracking – that is defects are found at early stage.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 92

 When to use?
• Where requirements are clearly defined and fixed.

• The V-Model is used when ample technical resources are available

with technical expertise.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 93

 Advantages

• This is a highly disciplined model and Phases are completed one at a

time.
• V-Model is used for small projects where project requirements are
clear.
• Simple and easy to understand and use.
• This model focuses on verification and validation activities early in the
life cycle thereby enhancing the probability of building an error-free
and good quality product.
• It enables project management to track progress accurately.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 94

 Disadvantages
• High risk and uncertainty.
• It is not a good for complex and object-oriented projects.
• It is not suitable for projects where requirements are not clear and
contains high risk of changing.
• This model does not support iteration of phases.
• It does not easily handle concurrent events.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 95

 References
• https://stackify.com/agile-
methodology/#:~:text=Examples%20of%20Agile%20Methodology,pic
k%20one%20or%20two%20methods.
• https://nptel.ac.in/courses/106/105/106105182/
• https://www.agilealliance.org/agile101/
• https://www.visual-paradigm.com/scrum/what-is-agile-software-
development/
• Image Reference https://resources.collab.net/agile-101/agile-
methodologies

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 96

THANK YOU

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 97

 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 98

 Introduction to Software Engineering

Course Outcome

CO
Title Level
Number
Define principles and working of software process
CO1 Understand
models.

Describe agile development methodology and analyse

CO2 Remember
where to apply.

Prepare SRS and software process metrics for a given

CO3 Analyse
requirement.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 99

 Topics covered
• Requirement analysis

• Requirement gathering

• Analysis Principles

• Software Prototyping

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 100

 REQUIREMENT ANALYSIS AND SPECIFICATION
• Many projects fail:
• Because they start implementing the system.
• Without determining whether they are building what the customer really
wants.
• It is important to learn:
• Requirements analysis and specification techniques carefully.
• Goals of requirements analysis and specification phase:
• Fully understand the user requirements.
• Remove inconsistencies, anomalies, etc. from requirements.
• Document requirements properly in an SRS document.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 101
REQUIREMENT ANALYSIS AND SPECIFICATION
• Requirements analysis consists of two main activities:
• Requirements gathering
• Analysis of the gathered requirements
• Analyst gathers requirements through:
• Observation of existing systems,
• Studying existing procedures,
• Discussion with the customer and end-users,
• Analysis of what needs to be done, etc.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 102
REQUIREMENT ANALYSIS
• Requirement analysis is significant and essential activity after elicitation.
• We analyze, refine, and scrutinize the gathered requirements to make
consistent and unambiguous requirements.
• This activity reviews all requirements and may provide a graphical view of
the entire system.
• After the completion of the analysis, it is expected that the understandability
of the project may improve significantly.
• Here, we may also use the interaction with the customer to clarify points of
confusion and to understand which requirements are more important than
others.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 103

Requirement Analysis

Fig 1 Steps of requirement analysis

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 104
 Example

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 105

REQUIREMENT ANALYSIS
• Draw the context diagram: The context diagram is a simple model that
defines the boundaries and interfaces of the proposed systems with the
external world. It identifies the entities outside the proposed system that
interact with the system.

• Development of a Prototype (optional):One effective way to find out what

the customer wants is to construct a prototype. We can use their feedback to
modify the prototype until the customer is satisfied continuously. Hence, the
prototype helps the client to visualize the proposed system and increase the
understanding of the requirements. When developers and users are not sure
about some of the elements, a prototype may help both the parties to take a
final decision.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 106

REQUIREMENT ANALYSIS
• Model the requirements: This process usually consists of various
graphical representations of the functions, data entities, external
entities, and the relationships between them. The graphical view may
help to find incorrect, inconsistent, missing, and superfluous
requirements. Such models include the Data Flow diagram, Entity-
Relationship diagram, Data Dictionaries, State-transition diagrams,
etc.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 107

REQUIREMENT ANALYSIS
• Finalize the requirements: After modeling the requirements, we will
have a better understanding of the system behavior. The
inconsistencies and ambiguities have been identified and corrected.
The flow of data amongst various modules has been analyzed.
Elicitation and analyze activities have provided better insight into the
system. Now we finalize the analyzed requirements, and the next step
is to document these requirements in a prescribed format.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 108

 REQUIREMENT GATHERING
• Gathering relevant data:
• usually collected from the end-users through interviews and
discussions.
• For example, for a business accounting software:
• interview all the accountants of the organization to find out their
requirements.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 109

 ANALYSIS PRINCIPLES
• Main purpose of requirements analysis:
• Clearly understand the user requirements,
• Detect inconsistencies, ambiguities, and incompleteness.
• Incompleteness and inconsistencies:
• Resolved through further discussions with the end-users and the
customers.
• Some part of the requirement:
• contradicts with some other part.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 110

Analysis Principle
• Over the past two decades, a large number of analysis modeling
methods have been developed.
• Investigators have identified analysis problems and their causes and
have developed a variety of notations and corresponding sets of
heuristics to overcome them.
• Each analysis method has a unique point of view.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 111

Analysis principle
• The information domain of a problem must be represented and
understood.
• The functions that the software is to perform must be defined.
• The behavior of the software must be represented.
• The models that depict information, function, and
• The models that depict information function and behavior must be
partitioned in a manner that uncovers details in a layered fashion.
• The analysis process should move from essential information toward
implementation detail.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 112

Analysis Principle
• In addition to these operational analysis principles for requirements
engineering:
• Understand the problem before you begin to create the analysis model.
• Develop prototype that enable a user to understand how
human/machine interaction will occur.
• Record the origin of and the reason for every requirement.
• Use multiple views of requirements.
• Rank requirements.
• Work to eliminate ambiguity
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 113
 Software Prototyping
• Development of a preliminary version of a software system in order to
allow certain aspects of that system to be investigated.
• Often the primary purpose of a prototype is to obtain feedback from
the intended users; the requirements specification for the system can
then be updated to reflect this feedback, and so increase confidence in
the final system.
• A prototype may for example be developed with no concern for its
efficiency or performance, and certain functions of the final system
may be entirely omitted.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 114

Software Prototyping
• Additionally a prototype can be used to investigate particular problem
areas, or certain implications of alternative design or implementation
decisions.
• The intention with a prototype is normally to obtain the required
information as rapidly as possible and with the minimum investment
of resources, and it is therefore common to concentrate on certain
aspects of the intended system and completely ignore others.
• It must however be realistic in those aspects specifically under
investigation.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 115

SOFTWARE REQUIREMENT SPECIFICATION
• Main aim of requirements specification:
• Systematically organize the requirements arrived during requirements
analysis.
• Document requirements properly.

• The SRS document is useful in various contexts:

• Statement of user needs
• Contract document
• Reference document
• Definition for implementation

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 116

 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.tutorialspoint.com/software_testing_dictionary/software_requirement_specification.htm

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 117

THANK YOU

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University

 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 119
 Introduction to Software Engineering

Course Outcome

CO
Title Level
Number
Prepare SRS and software process metrics for a given
CO3 Analyse
requirement.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 120

 Topics covered
• Software requirement Specification

• SRS document

• Functional and non functional requirement

121
SOFTWARE REQUIREMENT SPECIFICATION
• Main aim of requirements specification:
• Systematically organize the requirements arrived during requirements
analysis.
• Document requirements properly.

• The SRS document is useful in various contexts:

• Statement of user needs
• Contract document
• Reference document
• Definition for implementation

122
 SRS DOCUMENT
• The SRS document is known as black-box specification:
• The system is considered as a black box whose internal details are not known.
• Only its visible external (i.e. input/output) behaviour is documented.
• SRS document concentrates on:
• What needs to be done
• Carefully avoids the solution (“how to do”) aspects.
• The SRS document serves as a contract
• Between development team and the customer.
• Should be carefully written

123
SRS Document
• A software requirements specification (SRS) is a document that
captures complete description about how the system is expected to
perform. It is usually signed off at the end of requirements engineering
phase.
• A software requirements specification (SRS) is a detailed
description of a software system to be developed with its functional
and non-functional requirements.
• The SRS is developed based the agreement between customer and
contractors.

124
SRS Document
• It may include the use cases of how user is going to interact with
software system.
• The software requirement specification document consistent of all
necessary requirements required for project development.
• To develop the software system we should have clear understanding
of Software system.
• To achieve this we need to continuous communication with customers
to gather all requirements.

125
SRS Document
• A good SRS defines the how Software System will interact with all
internal modules, hardware, communication with other programs and
human user interactions with wide range of real life scenarios.
• Using the Software requirements specification (SRS) document on
QA lead, managers creates test plan.
• It is very important that testers must be cleared with every detail
specified in this document in order to avoid faults in test cases and its
expected results.

126
 Qualities of SRS
• Correctness of SRS should be checked : Since the whole testing phase
is dependent on SRS, it is very important to check its correctness.
There are some standards with which we can compare and verify.
• Ambiguity should be avoided. Sometimes in SRS, some words have
more than one meaning and this might confused testers making it
difficult to get the exact reference. It is advisable to check for such
ambiguous words and make the meaning clear for better
understanding.

127
Qualities of SRS
• Requirements should be complete. When tester writes test cases,
what exactly is required from the application, is the first thing which
needs to be clear. For e.g. if application needs to send the specific data
of some specific size then it should be clearly mentioned in SRS that
how much data and what is the size limit to send.
• Consistent requirements.The SRS should be consistent within itself
and consistent to its reference documents. If you call an input “Start
and Stop” in one place, don’t call it “Start/Stop” in another. This sets
the standard and should be followed throughout the testing phase.

128
Qualities of SRS
• Verification of expected result: SRS should not have statements like
“Work as expected”, it should be clearly stated that what is expected
since different testers would have different thinking aspects and may
draw different results from this statement.
• Testing environment: some applications need specific conditions to
test and also a particular environment for accurate result. SRS should
have clear documentation on what type of environment is needed to
set up.

129
Qualities of SRS
• Pre-conditions defined clearly: one of the most important part of test
cases is pre-conditions. If they are not met properly then actual result
will always be different expected result. Verify that in SRS, all the pre-
conditions are mentioned clearly.
• Requirements ID: these are the base of test case template. Based on
requirement Ids, test case ids are written. Also, requirements ids make
it easy to categorize modules so just by looking at them, tester will
know which module to refer. SRS must have them such as id defines a
particular module.

130
Qualities of SRS
• Security and Performance criteria: security is priority when a software is tested
especially when it is built in such a way that it contains some crucial information
when leaked can cause harm to business.
• Assumption should be avoided: sometimes when requirement is not cleared to
tester, he tends to make some assumptions related to it, which is not a right way to
do testing as assumptions would go wrong and hence, test results may vary.
• Deletion of irrelevant requirements: there are more than one team who work on
SRS so it might be possible that some irrelevant requirements are included in SRS.
Based on the understanding of the software, tester can find out which are these
requirements and remove them to avoid confusions and reduce work load.
• Freeze requirements: when an ambiguous or incomplete requirement is sent to
client to analyze and team gets a reply, that requirement result will be updated in
the next SRS version and client will freeze that requirement. Freezing here means
that result will not change again until and unless some major addition or
modification is introduced in the software.

131
 Properties of a good SRS document
• Concise: The SRS report should be concise and at the same time,
unambiguous, consistent, and complete. Verbose and irrelevant
descriptions decrease readability and also increase error possibilities.
• Structured: It should be well-structured. A well-structured document
is simple to understand and modify. In practice, the SRS document
undergoes several revisions to cope up with the user requirements.
Often, user requirements evolve over a period of time. Therefore, to
make the modifications to the SRS document easy, it is vital to make
the report well-structured.

132
Properties of a good SRS document
• Black-box view: It should only define what the system should do and
refrain from stating how to do these. This means that the SRS
document should define the external behavior of the system and not
discuss the implementation issues. The SRS report should view the
system to be developed as a black box and should define the externally
visible behavior of the system. For this reason, the SRS report is also
known as the black-box specification of a system.

133
Properties of a good SRS document
• Conceptual integrity: It should show conceptual integrity so that the
reader can merely understand it. Response to undesired events: It
should characterize acceptable responses to unwanted events. These
are called system response to exceptional conditions.
• Verifiable: All requirements of the system, as documented in the SRS
document, should be correct. This means that it should be possible to
decide whether or not requirements have been met in an
implementation.

134
 FUNCTIONAL REQUIREMENTS
• Functional requirements describe:
• A set of high-level requirements
• Each high-level requirement:
• takes in some data from the user
• outputs some data to the user
• Each high-level requirement:
• might consist of a set of identifiable functions
• For each high-level requirement:
• Every function is described in terms of:
• Input data set
• Output data set
• Processing required to obtain the output data set from the input data set.

135
 NON FUNCTIONAL REQUIREMENTS
• Characteristics of the system which can not be expressed as functions:
• Maintainability,
• Portability,
• Usability, etc.
• Non functional requirements include:
• Reliability issues,
• Performance issues:
• Example: How fast the system can produce results
• so that it does not overload another system to which it supplies data, etc.
• Human-computer interface issues,
• Interface with other external systems,
• Security, maintainability, etc.

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

137
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 139
 Introduction to Software Engineering

Course Outcome

CO
Title Level
Number
Prepare SRS and software process metrics for a given
CO3 Analyse
requirement.

Prepare Test Suite and Quality Assurance plan for a

CO4 Create
given project.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 140

 Topics covered
• Functional and non functional requirement

• Decision tree

• Decision table

• Data Modeling

• Functional Modeling

• Behavioral Modeling

141
 FUNCTIONAL REQUIREMENTS
• Functional requirements describe:
• A set of high-level requirements
• Each high-level requirement:
• takes in some data from the user
• outputs some data to the user
• Each high-level requirement:
• might consist of a set of identifiable functions
• For each high-level requirement:
• Every function is described in terms of:
• Input data set
• Output data set
• Processing required to obtain the output data set from the input data set.

142
FUNCTIONAL REQUIREMENTS
• A Functional Requirement is a description of the service that the
software must offer.
• It describes a software system or its component.
• A function is nothing but inputs to the software system, its behavior,
and outputs.
• It can be a calculation, data manipulation, business process, user
interaction, or any other specific functionality which defines what
function a system is likely to perform.
• Functional Requirements are also called Functional Specification.

143
FUNCTIONAL REQUIREMENTS
• In software engineering and systems engineering, a Functional
Requirement can range from the high-level abstract statement of the
sender's necessity to detailed mathematical functional requirement
specifications.
• Functional software requirements help you to capture the intended
behavior of the system.

144
FUNCTIONAL REQUIREMENTS : EXAMPLE

145
Functional requirement should include:
• Details of operations conducted in every screen
• Data handling logic should be entered into the system
• It should have descriptions of system reports or other outputs
• Complete information about the workflows performed by the system
• It should clearly define who will be allowed to create/modify/delete
the data in the system
• How the system will fulfill applicable regulatory and compliance
needs should be captured in the functional document

146
Benefits of Functional Requirement
• Helps you to check whether the application is providing all the
functionalities that were mentioned in the functional requirement of that
application
• A functional requirement document helps you to define the functionality of
a system or one of its subsystems.
• Functional requirements along with requirement analysis help identify
missing requirements. They help clearly define the expected system service
and behavior.
• Errors caught in the Functional requirement gathering stage are the cheapest
to fix.
• Support user goals, tasks, or activities

147
Types of Functional Requirements
• Transaction Handling
• Business Rules
• Certification Requirements
• Reporting Requirements
• Administrative functions
• Authorization levels
• Audit Tracking
• External Interfaces
• Historical Data management
• Legal and Regulatory Requirements

148
 NON FUNCTIONAL REQUIREMENTS
• Characteristics of the system which can not be expressed as functions:
• Maintainability,
• Portability,
• Usability, etc.
• Non functional requirements include:
• Reliability issues,
• Performance issues:
• Example: How fast the system can produce results
• so that it does not overload another system to which it supplies data, etc.
• Human-computer interface issues,
• Interface with other external systems,
• Security, maintainability, etc.

149
NON FUNCTIONAL REQUIREMENTS
• NON-FUNCTIONAL REQUIREMENT (NFR) specifies the quality
attribute of a software system.
• They judge the software system based on Responsiveness, Usability,
Security, Portability and other non-functional standards that are critical
to the success of the software system.
• Example of nonfunctional requirement, “how fast does the website
load?”
• Failing to meet non-functional requirements can result in systems that
fail to satisfy user needs.

150
NON FUNCTIONAL REQUIREMENTS
• Non-functional Requirements allows you to impose constraints or
restrictions on the design of the system across the various agile
backlogs.
• Example, the site should load in 3 seconds when the number of
simultaneous users are > 10000.

151
TYPES OF NON-FUNCTIONAL REQUIREMENTS
• Usability requirement
• Serviceability requirement
• Manageability requirement
• Recoverability requirement
• Security requirement
• Data Integrity requirement
• Capacity requirement
• Availability requirement
• Scalability requirement
• Interoperability requirement
• Reliability requirement
• Maintainability requirement
• Regulatory requirement
• Environmental requirement

152
Examples of Non-functional requirements
• Users must change the initially assigned login password immediately after
the first successful login. Moreover, the initial should never be reused.
• Employees never allowed to update their salary information. Such attempt
should be reported to the security administrator.
• Every unsuccessful attempt by a user to access an item of data shall be
recorded on an audit trail.
• A website should be capable enough to handle 20 million users with
affecting its performance
• The software should be portable. So moving from one OS to other OS does
not create any problem.
• Privacy of information, the export of restricted technologies, intellectual
property rights, etc. should be audited.

153
Advantages of Non-Functional Requirement
• The nonfunctional requirements ensure the software system follow
legal and compliance rules.
• They ensure the reliability, availability, and performance of the
software system
• They ensure good user experience and ease of operating the software.
• They help in formulating security policy of the software system.

154
Disadvantages of Non-functional requirement
• None functional requirement may affect the various high-level
software subsystem
• They require special consideration during the software
architecture/high-level design phase which increases costs.
• Their implementation does not usually map to the specific software
sub-system,
• It is tough to modify non-functional once you pass the architecture
phase.

155
Functional Vs Non-Functional requirements

156
 Representation of complex processing logic

• Decision trees
• Decision tables

157
Decision Tree
• A decision tree is a map of the possible outcomes of a series of related
choices.
• It allows an individual or organization to weigh possible actions
against one another based on their costs, probabilities, and benefits.
• They can be used either to drive informal discussion or to map out an
algorithm that predicts the best choice mathematically.
• A decision tree typically starts with a single node, which branches into
possible outcomes. Each of those outcomes leads to additional nodes,
which branch off into other possibilities. This gives it a treelike shape.

158
Decision Tree
• There are three different types of nodes: chance nodes, decision nodes,
and end nodes.
• A chance node, represented by a circle, shows the probabilities of
certain results.
• A decision node, represented by a square, shows a decision to be
made, and an end node shows the final outcome of a decision path.

159
Decision Tree Symbols

160
Decision Tree
• A Decision Tree offers a graphic read of the processing logic
concerned in a higher cognitive process and therefore the
corresponding actions are taken.
• The perimeters of a choice tree represent conditions and therefore the
leaf nodes represent the actions to be performed looking on the result
of testing the condition.

161
Example
• For example, consider Library Membership Automation Software (LMS)
where it ought to support the following three options: New member,
Renewal, and Cancel membership. These are explained as following below.
1. New Member Option:
• Decision:
Once the ‘new member’ possibility is chosen, the software system asks
details concerning the member just like the member’s name, address,
number, etc.
• Action:
If correct info is entered then a membership record for the member is made
and a bill is written for the annual membership charge and the protection
deposit collectible.
162
Example
2 Cancel Membership Option:
• Decision:
If the ‘cancel membership’ possibility is chosen, then the software system asks for
member’s name and his membership range.
• Action:
The membership is off, a cheque for the balance quantity because of the member
is written and at last the membership record is deleted from the information.
3 Renewal Option:
• Decision:
If the ‘renewal’ possibility is chosen, the LMS asks for the member’s name and his
membership range to test whether or not he’s a sound member or not.
• Action:
If the membership is valid then membership ending date is updated and therefore
the annual membership bill is written, otherwise, a slip-up message is displayed.
163
Example

Fig 1 Example of decision tree

164
Advantages
The advantages of decision tree are as follow:
• They are easy to understand
• They can be useful with or without hard data, and any data requires
minimal preparation
• New options can be added to existing trees
• Their value in picking out the best of several options

165
Disadvantages
• When dealing with categorical data with multiple levels, the
information gain is biased in favor of the attributes with the most
levels.
• Calculations can become complex when dealing with uncertainty and
lots of linked outcomes.
• Conjunctions between nodes are limited to AND, whereas decision
graphs allow for nodes linked by OR.

166
 Decision table
• Decision tables specify:
• Which variables are to be tested
• What actions are to be taken if the conditions are true,
• The order in which decision making is performed.
• A decision table shows in a tabular form:
• Processing logic and corresponding actions
• Upper rows of the table specify:
• The variables or conditions to be evaluated
• Lower rows specify:
• The actions to be taken when the corresponding conditions are satisfied.

167
 Decision table
• In technical terminology,
• a column of the table is called a rule:
• A rule implies:
• if a condition is true, then execute the corresponding action.

168
Decision Table
• Decision table is a brief visual representation for specifying which
actions to perform depending on given conditions.
• The information represented in decision tables can also be represented
as decision trees or in a programming language using if-then-else and
switch-case statements.
• A decision table is a good way to settle with different combination
inputs with their corresponding outputs and also called cause-effect
table.
• Reason to call cause-effect table is a related logical diagramming
technique called cause-effect graphing that is basically used to obtain
the decision table.
169
Importance of Decision Table
• Decision tables are very much helpful in test design technique.
• It helps testers to search the effects of combinations of different inputs and
other software states that must correctly implement business rules.
• It provides a regular way of stating complex business rules, that is helpful
for developers as well as for testers.
• It assists in development process with developer to do a better job. Testing
with all combination might be impractical.
• A decision table is basically an outstanding technique used in both testing
and requirements management.
• It is a structured exercise to prepare requirements when dealing with
complex business rules.
• It is also used in model complicated logic.

170
Example: How to make Decision Base Table for
Login Screen
• Let's create a decision table for a login screen.

171
Example
• The condition is simple if the user provides correct username and
password the user will be redirected to the homepage. If any of the
input is wrong, an error message will be displayed.

172
Example
• Notations
• T – Correct username/password
• F – Wrong username/password
• E – Error message is displayed
• H – Home screen is displayed
• Interpretation:
• Case 1 – Username and password both were wrong. The user is shown an error message.
• Case 2 – Username was correct, but the password was wrong. The user is shown an error
message.
• Case 3 – Username was wrong, but the password was correct. The user is shown an error
message.
• Case 4 – Username and password both were correct, and the user navigated to homepage

173
Advantages and Disadvantages
• Advantages
• When the system behavior is different for different input and not same for a range of
inputs, both equivalent partitioning, and boundary value analysis won't help, but decision
table can be used.
• The representation is simple so that it can be easily interpreted and is used for
development and business as well.
• This table will help to make effective combinations and can ensure a better coverage for
testing
• Any complex business conditions can be easily turned into decision tables
• In a case we are going for 100% coverage typically when the input combinations are low,
this technique can ensure the coverage.
• Disadvantages
• The main disadvantage is that when the number of input increases the table will become
more complex

174
Comparison

175
 Formal specification
• A formal specification technique is a mathematical method to:
• Accurately specify a system.
• Verify that implementation satisfies specification.
• Prove properties of the specification. A formal software specification
is a statement expressed in a language whose vocabulary, syntax, and
semantics are formally defined.
• The need for a formal semantic definition means that the specification
languages cannot be based on natural language; it must be based on
mathematics.

176
Formal Specification
• Advantages:
• Well-defined semantics, no scope for ambiguity
• Automated tools can check properties of specifications
• Executable specification
• The development of a formal specification provides insights and
understanding of the software requirements and the software design.
• Given a formal system specification and a complete formal
programming language definition, it may be possible to prove that a
program conforms to its specifications.
• Formal specification may be automatically processed. Software tools
can be built to assist with their development, understanding, and
debugging.

177
Formal Specification
• Depending on the formal specification language being used, it may be
possible to animate a formal system specification to provide a
prototype system.
• Formal specifications are mathematical entities and may be studied
and analyzed using mathematical methods.
• Formal specifications may be used as a guide to the tester of a
component in identifying appropriate test cases.

178
 Formal specification
• Disadvantages of formal specification techniques:
• Difficult to learn and use
• Not able to handle complex systems

• Mathematical techniques used include:

• Logic-based
• set theoretic
• algebraic specification
• finite state machines, etc.
179
Formal Specification
• Formal specifications sometimes are not used because:
• Software management is conservative and unwilling to adopt new
techniques whose payoff is not immediately obvious.
• Most software engineers have not been trained in formal specification
techniques.
• Some classes of systems are difficult to specify using existing
specification techniques. Interactive and interrupt driven systems
might be examples.

180
 APPLICATIONS
• Managing clients requirements in industry.
• Generating software for noticing health activities with novel smart
technologies.
• Content Management and to analyzing Fraud detection and Prevention
• Advertisements Targeting Platforms Managing content, posts, images and
videos on social media platforms
• Analyzing customer data in real-time for improving business performance
• Public sector fields such as intelligence, defense, cyber security and
scientific research

181
 Data Modeling
• A data model can be thought of as a flowchart that illustrates the relationships
among data.
• It enables stakeholders to identify errors and make changes before any
programming code has been written.
• Alternatively, models can be introduced as part of reverse engineering efforts that
extract models from existing systems, as seen with NoSQL data.
• Data modelers often use multiple models to view the same data and ensure that all
processes, entities, relationships and data flows have been identified.
• Data modeling stages roughly break down into creation of logical data models that
show specific attributes, entities and relationships among entities and the physical
data model.

182
 Functional Modeling
• In the Functional Model, software converts information. and to accomplish this,

it must perform at least three common tasks- input, processing and output.

• When functional models of an application are created, the software engineer

emphasizes problem specific tasks. The functional model begins with a single

reference level model

183
 Functional Modeling
• In a series of iterations, more and more functional detail is given, until all system

functionality is fully represented.

• Information is converted because it flows from a computer-based system.

• The system takes input in various forms; Hardware, software, and human elements

are applied to replace it; And produces in various forms.

184
 Behavioral Modeling
• Behavioral model describes the interaction in the system. It represents
the interaction among the structural diagrams. Behavioral modeling
shows the dynamic nature of the system. They consist of the
following:
• Activity diagrams
• Interaction diagrams
• Use case diagrams

185
 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/computer-organization-and-architecture-tutorials/

186
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 188
 Topics covered
• Structural Modeling

• Data Dictionary

189
 Structural Modeling
• Structural modeling captures the static features of a system. They
consist of the following −
• Classes diagrams
• Objects diagrams
• Deployment diagrams
• Package diagrams
• Composite structure diagram
• Component diagram

190
 Structural Modeling
• Structural model represents the framework for the system and this
framework is the place where all other components exist.
• Hence, the class diagram, component diagram and deployment
diagrams are part of structural modeling.
• They all represent the elements and the mechanism to assemble them.

191
 Structural Modeling
• Structural models of software display the organization of a system in
terms of the components that make up that system and their
relationships.
• Structural models may be static models, which show the structure of
the system design, or dynamic models, which show the organization
of the system when it is executing.
• You create structural models of a system when you are discussing and
designing the system architecture.

192
 Structural Modeling
• Structural models of software display the organization of a system in
terms of the components that make up that system and their
relationships.

• Structural models may be static models, which show the structure of

the system design or dynamic models, which show the organization of
the system when it is executing.

193
 Data Dictionary
• A data dictionary is a file or a set of files that includes a database's
metadata.
• The data dictionary hold records about other objects in the database,
such as data ownership, data relationships to other objects, and other
data.
• The data dictionary is an essential component of any relational
database.
• Ironically, because of its importance, it is invisible to most database
users.

194
 Data Dictionary
• The data dictionary, in general, includes information about the following:
• Name of the data item
• Aliases
• Description/purpose
• Related data items
• Range of values
• Data structure definition/Forms

195
 Data Dictionary
• Data flows capture the name of processes that generate or receive the
data items.
• If the data item is primitive, then data structure form captures the
physical structures of the data item.
• If the data is itself a data aggregate, then data structure form capture
the composition of the data items in terms of other data items.

196
 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/computer-organization-and-architecture-tutorials/

197
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 199
 Topics covered
• Function Oriented Design

• Data Flow Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 200

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 201

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 202

 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:
•

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 203

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 204

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

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 205

Data Flow Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 206

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 207

 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

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 208

THANK YOU

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University

 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 210
 Topics covered
• Data Dictionary

• Structured Chart

• Pseudo Code

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 211

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 212

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 213

 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.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 214
 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.
•

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 215

 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

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 216

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

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 217

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 218

 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/

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 219

THANK YOU

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University

 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 221
 Topics covered
• Object Oriented Design

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 222

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 223

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 224

Object Oriented Design

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 225

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 226

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 227

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 228

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 229

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 230

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 231

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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 232

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

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 233

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 234
 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 235

THANK YOU

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University

 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 237
 Topics covered
• Unified Modeling Language

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 238

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 239

 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

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 240

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 241

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 242

Classification of UML

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 243

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 244

 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.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 245
 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 246

Class Diagram : Example

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 247

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 248

 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.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 249
 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 250

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 251

 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

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 252

Structural UML Diagrams

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 253

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 254

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 255

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 256

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 257

Component Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 258

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 259

 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.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 260
 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 261

Deployment Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 262

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 263

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 264

Package Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 265

 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/

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 266

THANK YOU

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University

 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 268
 Topics covered
• Behavior Diagrams

• Use case Diagrams

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 269

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 270

 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.
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 271
Sequence Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 272

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 273

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 274

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 275

Communication Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 276

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 277

 Behavior Diagrams
• Timing Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 278

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 279

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 280

Use Case Diagrams

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 281

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 282

 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/

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 283

THANK YOU

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University

 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
Subject Name: Software Engineering
Subject Code: 23CST-206

Er. Jagmeet Kaur

E8387
ASSISTANT PROFESSOR DISCOVER . LEARN . EMPOWER
CSE

09/12/24 Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 285
 Topics covered
• Interaction Diagram

• Activity Diagram

• State Chart Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 286

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 287

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 288

Interaction Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 289

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 290

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 291

 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
Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 292
 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

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 293

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 294

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 295

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 296

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 297

State Chart Diagram

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 298

 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.

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 299

 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/

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University 300

THANK YOU

Er. Jagmeet Kaur, Asst. Prof., CSE, Chandigarh University