Software

Engineering
CS3201 [3 1 0 4]
Contents

• Software Engineering: Introduction, Importance, Evaluation, Characteristics, Components. Software

Application; Software Development Process Models: Waterfall Model, Prototyping Model, Spiral Model,
RAD Model, etc., Agile Modelling; Requirement Engineering: Problem Analysis, Requirement
Verification, Requirement Validation Modularity; Software Project Management: Cost Estimation Project
Scheduling, Risk Management, Quality Assurance, Project Monitoring; Estimation Techniques: Size
estimation- LOC Estimation, Function Count, Cost Estimation, Halstead Size Estimation, Software
Design: Analysis Modeling, Functional modeling, Behavioral Modeling; Unified modeling language;
Software Architecture: Data Design: Data modeling, data structures; Software Maintenance: Maintenances
Characteristics, Maintainability, Maintenances Tasks, Maintenances Side Effects, Current trends- DevOps.
Books to refer

Text Book
• R. Mall, “Fundamental of Software Engineering”, 4th Edition, PHI, 2014
• Ian Summerville, “Software Engineering”, 9th Edition, Addition Wesley,
2002.
Reference Books
• Pankaj Jalote, “Software Engineering a Precise Approach”, Wiley, 2010.
• Roger S. Pressman, “Software Engineering: A Practitioners Approach”, 7th
Edition, TMH, 2016.
What is Software Engineering?
• Engineering approach to develop software.
• Building Construction Analogy.
• Systematic collection of past experience:
• techniques,
• methodologies,

• Software engineering is the application of a systematic, disciplined, quantifiable

approach to the development, operation, and maintenance of software. (Definition by
IEEE) That is the application of engineering to software.
•The term software engineering first appeared in the 1968 NATO Software Engineering
Conference, and was meant to provoke thought regarding the perceived "software crisis" at
the time.

4
Software Engineering
• Software engineering is:
• An engineering discipline that provides knowledge, tools, and methods for:
• Defining software requirements
• Performing software design
• Software construction
• Software testing
• Software maintenance tasks
• Software project management

5
Introduction: Software is Complex

• Complex  complicated

• Complex = composed of many simple parts

related to one another

• Complicated = not well understood, or explained

7
The Frog in Boiling Water
• Small problems tolerate complacency—
lack of immediate penalty leads to inaction
• Negative feedback accumulates subtly and
by the time it becomes painful, the
problem is too big to address
• Frog in gradually heated water analogy:
• The problem with little things is that
none of them is big enough to scare you
into action, but they keep creeping up
and by the time you get alarmed the
problem is too difficult to handle
• Consequently, “design smells” https://en.wikipedia.org/wiki/Design_smell
https://en.wikipedia.org/wiki/Technical_debt
accumulate, “technical debt” grows, and https://en.wikipedia.org/wiki/Software_rot
the result is “software rot”
8
The Role of Software Engg. (1)
A bridge from customer needs to programming implementation

Customer
Customer
Programmer

First law of software engineering

Software engineer is willing to learn the problem domain
(problem cannot be solved without understanding it first) 9
The Role of Software Engg. (2)
Customer:
Requires a computer system to achieve some business goals
by user interaction or interaction w ith the problem domain
in a specified manner

System-to-be
(includes hardware)

Problem Domain
Software-to-be
User

Software Engineer’s task:

To understand how the system-to-be needs to interact w ith
the user or the problem domain so that customer’s requirement is met
and design the software-to-be

May be the Programmer’s task:

same person To implement the software-to-be
designed by the software engineer

10
Example: ATM Machine
Understanding the money-machine problem:

Communication link
1
4 2
7 5 3
8 6
0 9

Bank’s
remote
ATM machine
datacenter
Bank
customer

11
Problem-solving Strategy
Divide-and-conquer:
• Identify logical parts of the system that each solves a part
of the problem
• Easiest done with the help of a domain expert who already
knows the steps in the process (“how it is currently done”)
• Result:
A Model of the Problem Domain
(or “domain model”)

12
How ATM Machine Might Work Domain Model

Transaction
How may I record
help you? Cash

Bookkeeper
Speakerphone Safe
Safe keeper
Phone

Window clerk

Datacenter
liaison

Dispenser

Bank’s
remote
datacenter 13
Customer
Cartoon Strip : How ATM Machine Works
A Enter B C Verify
account
D
your PIN
XYZ
Verify
this
account

Typing in XYZ valid. Account

PIN number Balance: valid.
… $100 Balance:
$100

E How may F Release

G Record
I help $60 $60 less
you?

Withdraw Dispense
H Dispensing!

$60 $60
Please take
your cash

14
Sub-disciplines of Software Engineering
• Software engineering can be divided into 11 sub disciplines. They are:
• Software requirements: The elicitation, analysis, specification, and validation of requirements for
software.
• Software architecture: The elicitation, analysis, specification, definition and design, and
validation and control of software architecture requirements.
• Software design: The design of software is usually done with Computer-Aided Software
Engineering (CASE) tools and use standards for the format, such as the Unified Modeling
Language (UML).
• Software development: The construction of software through the use of programming languages.
• Software testing
• Software maintenance: Software systems often have problems and need enhancements for a long
time after they are first completed. This subfield deals with those problems.
15
 16

Why is Software Engineering important?

Complex systems need a disciplined approach for designing, developing

and managing them.
 17

Software Development Crises

Projects were:
• Late.
• Over budget.
• Unreliable.
• Difficult to maintain.
• Performed poorly.
 18

Software errors….the cost

Errors in computer software can have

devastating effects.
 19

Software Crisis
Example 1: 2009,Computer glitch delays flights

Saturday 3rd October 2009-London, England (CNN)

• Dozens of flights from the UK were delayed Saturday after a

glitch in an air traffic control system in Scotland, but the problem
was fixed a few hours later.
• The agency said it reverted to backup equipment as engineering
worked on the system.
• The problem did not create a safety issue but could cause delays
in flights.
• Read more at:
http://edition.cnn.com/2009/WORLD/europe/10/03/uk.flights.del
ayed
 20

Software Crisis
Example 2: Ariane 5 Explosion

• European Space Agency spent 10 years and $7 billion to

produce Ariane 5.

• Crash after 36.7 seconds.

• Caused by an overflow error. Trying to store a 64-bit number

into a 16-bit space.

• Watch the video:

http://www.youtube.com/watch?v=z-r9cYp3tTE
 21

Software Crisis
Example 3: 1992, London Ambulance Service

• Considered the largest ambulance service in the world.

• Overloaded problem.

• It was unable to keep track of the ambulances and their

statuses. Sending multiple units to some locations and no
units to other locations.

• Generates many exceptions messages.

• 46 deaths.
 22

Therefore…
A well-disciplined approach to software
development and management is
necessary. This is called engineering.
 23

Software Engineering

 The term software engineering first appeared in the 1968 NATO

Software Engineering Conference and was meant to provoke
thought regarding what was then called the “software crisis”..

 “.. An engineering discipline that is concerned with all aspects of

software production from the early stages of system specification
to maintaining the system after it has gone into use.” Sommerville,
pg.7
 24

What is Software?

Programs

Software
System
Documentation
Data Documentation
User
Documentation
 25

Types of Software

• Generic products.
• Stand-alone systems that are marketed and sold to any customer who wishes to buy them.
• Examples – PC software such as graphics programs, project management tools; CAD software;
software for specific markets such as appointments systems for dentists.
• The specification of what the software should do is owned by the software developer and
decisions on software change are made by the developer.

• Customized or bespoke products.

• Software that is commissioned by a specific customer to meet their own needs.
• Examples – embedded control systems, air traffic control software, traffic monitoring systems.
• The specification of what the software should do is owned by the customer for the software and
they make decisions on software changes that are required.
 26

Software Engineering vs. Computer Science

“Computer science is no more about computers than

astronomy is about telescopes.” Edsger Dijkstra

Computer Science Software Engineering

• Theory. • Practicalities of software

• Fundamentals. design, development and
delivery.
 27

Software Engineering vs. Systems Engineering

Systems Engineering:
 Interdisciplinary engineering field (computer, software, and process eng.).
 Focuses on how complex engineering projects should be designed and managed.

Systems Engineering Software Engineering

• All aspects of computer- • Deals with the design,

based systems development and delivery
development: HW + SW + of SW.
Process. • Is part of Systems
• Older than SWE. Engineering.
 Sub-disciplines of Software Engineering
• Software configuration management: Since software systems are very complex, their
configuration (such as versioning and source control) have to be managed in a standardized and
structured method.
• Software engineering management: The management of software systems borrows heavily from
project management, but there are nuances encountered in software not seen in other management
disciplines.
• Software development process: The process of building software is hotly debated among
practitioners; some of the better-known processes are the Waterfall Model, the Spiral Model,
Iterative and Incremental Development, and Agile Development.
• Software engineering tools
• Software quality

28
Software products
• Generic products
• Stand-alone systems that are marketed and sold to any customer who wishes
to buy them.
• Examples – PC software such as editing, graphics programs, project
management tools; CAD software; software for specific markets such as
appointments systems for dentists.
• Customized products
• Software that is commissioned by a specific customer to meet their own
needs.
• Examples – embedded control systems, air traffic control software, traffic
monitoring systems.
29
 Software Applications
1. System software: such as compilers, editors, file management utilities
2. Application software: stand-alone programs for specific needs.
3.Engineering/scientific software: Characterized by “number crunching”algorithms. such as
automotive stress analysis, molecular biology, orbital dynamics etc
4. Embedded software resides within a product or system. (keypad control of a microwave oven,
digital function of dashboard display in a car)
5. Product-line software focus on a limited marketplace to address mass consumer market. (word
processing, graphics, database management)
6. WebApps (Web applications) network centric software. As web 2.0 emerges, more sophisticated
computing environments is supported integrated with remote database and business applications.
7. AI software uses non-numerical algorithm to solve complex problem. Robotics, expert system,
pattern recognition game playing.

30
Need for Software Engineering

• The Five Drivers of Software Engineering

• Manage complexity of large programs
• Reduce time and cost of development
• Reduce maintenance cost
• Address “Software crisis” (Unacceptable low quality of software, exceeds
deadline and budget.)
• Produce quality software

31
Software Characteristics
• Its characteristics that make it different from other things human being build.

Features of such logical system:

• Software is developed or engineered; it is not manufactured in the classical sense which
has quality problem.
• Software doesn't "wear out.” but it deteriorates (due to change). Hardware has bathtub
curve of failure rate ( high failure rate in the beginning, then drop to steady state, then
cumulative effects of dust, vibration, abuse occurs).
• Although the industry is moving toward component-based construction (e.g. standard
screws and off-the-shelf integrated circuits), most software continues to be custom-built.
Modern reusable components encapsulate data and processing into software parts to be
reused by different programs. E.g. graphical user interface, window, pull-down menus in
library etc.

32
FAQ about software engineering
Question Answer

What is software? Computer programs, data structures and associated documentation. Software
products may be developed for a particular customer or may be developed for a
general market.

What are the attributes of good Good software should deliver the required functionality and performance to the
software? user and should be maintainable, dependable and usable.

What is software engineering? Software engineering is an engineering discipline that is concerned with all
aspects of software production.
What is the difference between Computer science focuses on theory and fundamentals; software engineering is
software engineering and concerned with the practicalities of developing and delivering useful software.
computer science?
What is the difference between System engineering is concerned with all aspects of computer-based systems
software engineering and system development including hardware, software and process engineering. Software
engineering? engineering is part of this more general process.

33
Essential attributes of good software
Product Description
characteristic
Maintainability Software should be written in such a way so that it can evolve to meet the changing needs
of customers. This is a critical attribute because software change is an inevitable
requirement of a changing business environment.

Dependability and Software dependability includes a range of characteristics including reliability, security and
security safety. Dependable software should not cause physical or economic damage in the event
of system failure. Malicious users should not be able to access or damage the system.

Efficiency Software should not make wasteful use of system resources such as memory and
processor cycles. Efficiency therefore includes responsiveness, processing time, memory
utilisation, etc.

Acceptability Software must be acceptable to the type of users for which it is designed. This means that
it must be understandable, usable and compatible with other systems that they use.

34
Software Qualities
Pressman's definition of “Software Quality”
1. explicitly stated functional and performance requirements,
2. explicitly documented development standards, and
3. implicit characteristics that are expected of all professionally developed software.
IEEE Definition of “Software Quality”
4. The degree to which a system, component, or process meets specified
requirements.
5. The degree to which a system, component, or process meets customer or user
needs or expectations.

35
Software Qualities
• Software quality:
• Conformance to explicitly stated requirements and standards
• Quality assurance:
• is the activity that leads to “fitness of purpose”.
• Quality product:
• is the one that does what the customer expects it to do.
User satisfaction = compliant product + good quality + delivery within
budget and schedule

36
Software Qualities
Quality criteria include but are not limited to:

• Correctness • Evolvability
• Reliability • Reusability
• Robustness • Portability
• Performance • Understandability
• User friendliness • Productivity
• Verifiability • Size
• Maintainability
• Timeliness
• Reparability
• Safety • Visibility

Select the critical attributes and plan how to achieve them

37
Software Quality Factors
• Low defects level when deployed
• Zero defect most preferably
• High reliability
• Capability of running without crashes
• Majority of the user satisfy with software when conducted the survey
• Effective customer support
• Rapid defect repair

38
Benefits Of Software Quality
• Reduced maintenance cost
• Stable and useful product
• Satisfy customer needs
• Better chances for continuing releases
• Build corporate culture and identity
• Better chances for software and design reuse

39
McCall’s Quality Factors
• McCall’s quality factors were proposed in the early 1970s. They are as
valid today as they were in that time. It’s likely that software built to
conform to these factors will exhibit high quality well into the 21st
century, even if there are dramatic changes in technology.
M a i n t a i n a b ilit y P o r t a b ilit y

F l e x i b ili t y R e u s a b ilit y
T e s t a b ili t y
I n t e r o p e r a b ilit y

P R O D U C T R E V IS I O N P R O D U C T T R A N S IT I O N

P R O D U C T O P E R A T IO N

C o rre c tn e s s U s a b ilit y E ffic i e n c y

R e l i a b il i t y I n t e g r it y
40
McCall’s Software Quality Factors
• Product Operations
• Operational characteristics
• Product Revision
• Ability to undergo changes
• Product Transition
• Adaptability to new environments

41
McCall’s Quality Factors Model Tree

42
 McCall’s Software Quality Factors
Factor Criteria Description
Product Maintainability Can I fix it?
Revision Flexibility Can I change it?
Testability Can I test it?
Product Portability Will I be able to use it on another machine?
Transition Reusability Will I be able to reuse some of the other
software in other application?
Interoperability Will I be able to interface it with another
system?
Product Correctness Does it do what I want?
Operation Reliability Does it do it accurately all the time?
Efficiency Will it run as well as it can?
Integrity Is it secure?
Usability Is it easy to use?
43
McCall Quality Model and Alternative Models

Alternative factor models

No. Software quality McCall’s classic Evans and Deutsch and
factor model Marciniak model Willis model
1 Correctness + + +
2 Reliability + + +
3 Efficiency + + +
4 Integrity + + +
5 Usability + + +
6 Maintainability + + +
7 Flexibility + + +
8 Testability +
9 Portability + + +
10 Reusability + + +
11 Interoperability + + +
12 Verifiability + +
13 Expandability + +
14 Safety +
15 Manageability +
16 Survivability +

44
 45

What is a Software Process?

 Activities and results that produce a software product:

SW Process Activity What is going on there?

What does the customer need?

Specification
What are the constraints?

Development Design & programming.

Validation Checking whether it meets requirements.

Evolution Modifications (e.g. customer/market).

 46

What is a Software Process Model?

 Description of the software process that represents one view, such as the activities,
data or roles of people involved.

Examples of views Focus on…

Activities = human actions.

Workflow
What is input, output, and dependencies.

Activities = transformations of information.

Dataflow
How the input is transformed into output.

Role/Action What is the role of people involved in each step of the process?
 47

Software Process Models

Component-Based Software
Waterfall approach Iterative development
Engineering CBSE

assembled form existing components

 48

The Cost of Software Engineering

 Depends on:
 The process used, and
 The type of software being developed.

 Each generic approach has a different profile of cost distribution.

 Roughly 60% of costs are development costs, 40% are testing costs.

 For custom software, evolution costs often exceed development costs.

 49

Cost distribution
Custom software development (Bespoke)
Software Model Waterfall Model
Cost units 0 25 50 75 100
Cost distribution
Software development activity Specification Design Development Integration and testing

Iterative Development
0 25 50 75 100

Specification Iterative Development System testing

Component-based Software Engineering

0 25 50 75 100

Specification Development Integration and testing

Development and evolution costs for long-lifetime systems

0 100 200 300 400

System development System evolution

 50

Cost distribution
Generic software development

0 25 50 75 100

Specification Development System testing

Product development costs

 51

What is CASE?

 Computer Aided Software Engineering.

 Programs that support:


Requirements analysis.

System modeling.

Debugging.

Testing.
 52

Attributes of good software

 Functional attributes (performance; what the system does).

 Non-functional attributes (quality; how the system does it).

Product Characteristic Description

Maintainability Evolution qualities such as Testability, extensibility.
Dependability Reliability, security, safety.
Efficiency Response time, processing time, memory utilization.
Usability Easy to learn how to use the system by target users.
Efficient to use the system by users to accomplish a task.
Satisfying to use by intended users.
 53

Activity
 What are the key attributes for..

Interactive game Banking system Cardiac monitor in an ICU unit

Players, score, scenes, theme. Client accounts, stocks bonds, heart rate, temperature, blood
money transfers. pressure.
 54

Challenges facing software engineering

Challenge Why? Software needs to ..

Different computers, different platforms,

Heterogeneity different support systems.
Cope with this variability.

Businesses are more responsive  Be delivered in shorter time without

Delivery supporting software needs to evolve as rapidly. compromising quality.

Software is a part of many aspects of our lives

Demonstrate that it can be trusted by
Trust (work, study, leisure).
users.
Objects, Calling & Answering Calls
elmer.areCoprimes( Prime factorization:
905, 1988 905 = 5  181
) 1988 = 2  2  7  71

Result:
YES!

Stu Elmer

Prime factorization of 905:

5181 (2 distinct factors)
Prime factorization of 1988:
22771 (4 factors, 3 distinct)
Two integers are said to be coprime or relatively prime if they have no common
factor other than 1 or, equivalently, if their greatest common divisor is 1.
Objects Don’t Accept Arbitrary Calls
Acceptable calls are defined by object “methods”
(a.k.a. Operations, Procedures, Subroutines, Functions)

Object:
method-1: method-2: method-3:
ATM machine
Accept card Read code Take selection

1234
5678
12345

1
4 2
7 5 3
8 6
0 9
Object Interface
Interface defines method “signatures”
Method signature: name, parameters, parameter types, return type

Interface
attributes
method-1 Object hides its
state (attributes).
method-2 The attributes
are accessible
only through the
method-3 interface.
Clients, Servers, Messages
Client
Client Object
Object Server
Server
Object
Object

Message

• Objects send messages by calling methods

• Client object: sends message and asks for service

• Server object: provides service” and returns result

Interfaces

• An interface is a set of functional properties (services) that a software object

provides or requires.
• Methods define the “services” the server object implementing the interface
will offer
• The methods (services) should be created and named based on the needs of
client objects that will use the services
• “On-demand” design—we “pull” interfaces and their implementations into existence from the
needs of the client, rather than “pushing” out the features that we think a class should provide
Objects are Modules
Software Module

Inputs State Outputs

(e.g., force) (represented by (e.g., force)
state variables,
e.g.,
momentum,
mass, size, …)
Modules versus Objects
Modules are loose groupings of subprograms and data
“Promiscuous”
access to data
Subprograms often results in
(behavior) misuse

Data
(state)

Software Module 1 Software Module 2 Software Module 3

Objects encapsulate data

Attributes
/data
Methods (state)
(behavior)

Software Object 1 Software Object 2 Software Object 3

Software Development
Methodologies

62
Software Development Life Cycle
(SDLC)
• A (software/system) lifecycle model is a description of the sequence of activities
carried out in an SE project, and the relative order of these activities.
• Software Development Life Cycle (SDLC) is a process used by a systems
analyst to develop an information system, including requirements, validation,
training, and user (stakeholder) ownership.
• Any SDLC should result in a high quality software that meets or exceeds
customer expectations, reaches completion within time and cost estimates, works
effectively and efficiently in the current and planned Information Technology
infrastructure, and is inexpensive to maintain and cost-effective to enhance.
• It provides a sequence of activities for system designers and developers to follow.
• It consists of a set of steps or phases in which each phase of the SDLC uses the
results of the previous one.

63
Strength and Weaknesses of SDLC

64
Software Development Process Model
• A software development process model is an abstract
representation of a software process.
• The development process is the sequence of activities that will
produce high quality software.
• A software development process model is broken down into
distinct activities.
• A software development process model specifies how these
activities are organized in the entire software development
effort.

65
Types of Software Development Process
Model
• A software development process model is either a descriptive or
prescriptive characterization of how software is or should be
developed.
• A descriptive model describes the history of how a particular software
system was developed. Descriptive models may be used as the basis
for understanding and improving software development processes or
for building empirically grounded prescriptive models.
• A prescriptive model prescribes how a new software system should be
developed. Prescriptive models are used as guidelines or frameworks
to organize and structure how software development activities should
be performed, and in what order. Typically, it is easier and more
common to articulate a prescriptive life cycle model for how software
systems should be developed.
66
Waterfall Model
• Sometimes called the classic life cycle or the linear sequential
model.
• It suggests a systematic, sequential approach to software
development that begins at the system level and progresses through
analysis, design, coding, testing, and support.
• Waterfall model is the simplest & oldest prescriptive process model.
• It is a rigid and linear process model.
• Although the original waterfall model proposed by Winston Royce
made provision for “feedback loops,” the vast majority of
organizations that apply this process model treat it as if it were
strictly linear.
67
Stages of Waterfall Model

68
Waterfall Model
• In theory:
• Each phase produces documents that are:
• Verified and validated.
• Assumed to be complete.
• Each phase depends on the documents of the previous stage
to proceed → it has to wait for the completion of previous
stage.
• In practice:
• The phases overlap and feedback to each other (see the
feedback arrow in the diagram).

69
When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.

70
Advantages & Disadvantages
Advantages of the Waterfall Model:
• Easy to explain to the user.
• Stages and activities are well defined.
• Helps to plan and schedule the project.

Disadvantages of the Waterfall Model:

• Real projects rarely follow sequential flow.
• Difficult to state all requirements explicitly.
• The customer must have patience.
• Blocking states.
• Developers have very little interaction with the users.
• The project is not partitioned in phases in flexible way.
71
Incremental Process Model
• The incremental model combines elements of the linear sequential model
(applied repetitively) with the iterative philosophy of prototyping.
• Each linear sequence produces a deliverable “increment” of the software.
• For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document
production functions in the first increment; more sophisticated editing and
document production capabilities in the second increment; spelling and grammar
checking in the third increment; and advanced page layout capability in the
fourth increment.

72
Incremental Process Model
• Construct a partial implementation of a total system
• Then slowly add increased functionality
• The incremental model prioritizes requirements of the system and then
implements them in groups.
• Each subsequent release of the system adds function to the previous release, until
all designed functionality has been implemented.
• It combines the advantages of Waterfall and Evolutionary Model.
• Each increment is a mini-waterfall.

73
Stages of Incremental Model

74
When to use the Incremental Model
• Risk, funding, schedule, program complexity, or need for early realization of
benefits.
• Most of the requirements are known up-front but are expected to evolve over
time.
• A need to get basic functionality to the market early.
• On projects which have lengthy development schedules.
• On a project with new technology.

75
Advantages & Disadvantages
• Advantages of Incremental Model:
• Less Human Resources.
• Manage Technologies.
• Customer Evaluation and Satisfaction
• Customer gains experience.
• Low Project Failure Risk.
•
• Disadvantages of Incremental Model:
• Increments size should be neither too small nor too large.
• It is very difficult to categorize requirements as most important and least important.
76
Prototyping Model
• Prototyping is a technique for providing a reduced functionality or a limited performance
version of a software system early in its development.
• Prototyping can more directly accommodate early user participation in determining,
shaping, or evaluating emerging system functionality.
• Prototyping is the practice of building an early version of software.
• This model is built at the early stages of the software development. It is built very rapidly
and fast, so that it can be checked time-to-time by the customer. That is why, it is also
called as the “Rapid Prototyping”.
• Prototyping is well suited for projects where requirements are hard to determine and the
confidence in the stated requirements is low.

77
Prototyping Model

78
 Steps of Prototyping Model
• A preliminary project plan is developed
• An partial high-level paper model is created
• The model is source for a partial requirements specification
• A prototype is built with basic and critical attributes
• The designer builds
• the database
• user interface
• algorithmic functions
• The designer demonstrates the prototype, the user evaluates for problems and
suggests improvements.
• This loop continues until the user is satisfied

79
When to use Prototyping Model
• Requirements are unstable or have to be clarified
• As the requirements clarification stage of a waterfall model
• Develop user interfaces
• Short-lived demonstrations
• New, original development
• With the analysis and design portions of object-oriented development.

80
 Advantages of Prototyping Model
• Misunderstandings between software developer and users may be identified.
• Missing facilities and features may be found out.
• Any non-conform, hard or confusing facilities or characteristics may be identified.
• Software developer may be found the incomplete or inconsistent requirements as
the prototype is developed.
• Development effort is reduced because the resultant system is the right system.
• User-developer communication is enhanced.

81
 Disadvantages of Prototyping Model
• The customer will want the early version of the model which may not have good
quality concerns and maintainability.
• The developer often makes implementation compromises in order to get a
prototype working quickly. An inappropriate operating system or programming
language may be used simply because it is available and known; an inefficient
algorithm may be implemented simply to demonstrate capability. After a time, the
developer may become familiar with these choices and forget all the reasons why
they were inappropriate. The less-than-ideal choice has now become an integral
part of the system.

82
 Spiral Model
• The spiral model, originally proposed by Barry W. Boehm in his 1986 article "A
Spiral Model of Software Development and Enhancement“.
• It is an evolutionary software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the linear sequential
model.
• It provides the potential for rapid development of incremental versions of the
software.
• Using the spiral model, software is developed in a series of incremental releases.

83
Stages of Spiral Model

84
Spiral Model
• Process is represented as a spiral rather than as a sequence of activities with
backtracking.
• Each loop = One Iteration = A process phase.
• Each Loop passes through 4 quadrants (90°):
• Objective Setting.
• Risk Assessment and Reduction.
• Development and Validation.
• Planning.
• As loops move away from center → Time and Cost increase.
• Adds risk analysis, and RAD prototyping to the waterfall model.
• Each cycle involves the same sequence of steps as the waterfall process model.

85
When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to economic
priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)

86
Advantages of Spiral Model
• The software development indicates that the software remain active till it is retired.
• It is a realistic approach to be used.
• If the process is going to be old, and requires some type of change, then maintenance or
some enhancements can be done in the project.
• The main and most important feature of this model is risk analysis. The risk analyst will
try to reduce the risks arise. Prototyping can be used as risk reduction mechanism.

87
 Disadvantages of Spiral Model
• It is very hard to satisfy the customer.
• If the risks are not covered initially then they may arise at any time in later stages.
• This model can’t be used so frequently so the results are not available soon.
• It requires a large sum of money to be completed.
• Very difficult to implement.

88
Rapid Application Development Model
• RAD model is Rapid Application Development model.
• It is an adoption of the waterfall model.
• It targets at developing software in a short span of time.
• It is a type of incremental model.
• In RAD model, the components or functions are developed in parallel as if they were
mini projects.
• The developments are time boxed, delivered and then assembled into a working
prototype.
• RAD model has following phases
1. Business Modeling 4. Application Generation
2. Data Modeling 5. Testing and Turnover
3. Process Modeling
89
RAD Model

90
Different phases of RAD model
Phases of RAD Activities performed in RAD Model
model

Business Modeling •On basis of the flow of information and distribution between various business channels,
the product is designed

Data Modeling •The information collected from business modeling is refined into a set of data objects that
are significant for the business

Process Modeling •The data object that is declared in the data modeling phase is transformed to achieve the
information flow necessary to implement a business function

Application •Automated tools are used for the construction of the software, to convert process and data
Generation models into prototypes

Testing and •As prototypes are individually tested during every iteration, the overall testing time is
Turnover reduced in RAD.
91
When to use RAD Methodology?
• When a system needs to be produced in a short span of time (2-3 months)
• When the requirements are known
• When the user will be involved all through the life cycle
• When technical risk is less
• When there is a necessity to create a system that can be modularized in 2-3
months of time
• When a budget is high enough to afford designers for modeling along with the
cost of automated tools for code generation

92
RAD Examples

• Purchase Order
• Gather all the people who know the process best, starting with the procurement team. Bring
together current forms and a complete understanding of the workflow. Discuss how you want the
app to function. With purchase orders, it’s often helpful to also have a vendor database for quick
reference to call up information in the form.

• Employee Resignation
• Travel Request

93
RAD Model Vs Traditional SDLC
• The traditional SDLC follows a rigid process models with high emphasis on
requirement analysis and gathering before the coding starts. It puts pressure on the
customer to sign off the requirements before the project starts and the customer doesn’t
get the feel of the product as there is no working solution available for a long time.
• The customer may need some changes after he gets to see the software. However, the
change process is quite rigid and it may not be feasible to incorporate major changes in
the product in the traditional SDLC.
• The RAD model focuses on iterative and incremental delivery of working models to the
customer. This results in rapid delivery to the customer and customer involvement
during the complete development cycle of product reducing the risk of non-
conformance with the actual user requirements.

94
Advantages of the RAD Model
• Changing requirements can be accommodated.
• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.
• Productivity with fewer people in a short time.
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.
95
Disadvantages of the RAD Model
• Dependency on technically strong team members for identifying business requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on modeling skills.
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.

96
Agile Modeling
• Rapid development and delivery is now often the most important requirement for
software systems
• Businesses operate in a fast –changing requirement and it is practically impossible to produce
a set of stable software requirements
• Software has to evolve quickly to reflect changing business needs.

• Plan-driven development is essential for some types of system but does not meet
these business needs.
• Dissatisfaction with the overheads involved in software design methods of the
1980s and 1990s led to the creation of agile methods.
• Agile development methods emerged in the late 1990s whose aim was to radically
reduce the delivery time for working software systems.
97
Dynamic System Development Method
• The Dynamic Systems Development technique (DSDM) is an associate degree
agile code development approach that provides a framework for building and
maintaining systems.
• The DSDM philosophy is borrowed from a modified version of the sociologist
principle—80% of An application is often delivered in twenty percent of the time
it’d desire deliver the entire (100 percent) application.
• DSDM is a Rapid Application Development (RAD) approach to software
development and provides an agile project delivery framework.
• The important aspect of DSDM is that the users are required to be involved
actively, and the teams are given the power to make decisions.
• Frequent delivery of product becomes the active focus with DSDM.
98
DSDM Life Cycle
• DSDM life cycle that defines 3 different unvarying cycles, preceded by 2 further life cycle
activities:
• Feasibility Study: It establishes the essential business necessities and constraints related to the
applying to be designed then assesses whether or not the application could be a viable candidate
for the DSDM method.
• Business Study: It establishes the use and knowledge necessities that may permit the applying to
supply business value; additionally, it is the essential application design and identifies the
maintainability necessities for the applying.
• Functional Model Iteration: It produces a collection of progressive prototypes that demonstrate
practicality for the client. The intent throughout this unvarying cycle is to collect further
necessities by eliciting feedback from users as they exercise the paradigm.

99
 DSDM Life Cycle
• Design and Build Iteration: It revisits prototypes designed throughout useful
model iteration to make sure that everyone has been designed during a manner that
may alter it to supply operational business price for finish users. In some cases,
useful model iteration and style and build iteration occur at the same time.
• Implementation: It places the newest code increment (an “operationalized”
prototype) into the operational surroundings. It ought to be noted that:
(a) the increment might not 100% complete or,
(b) changes are also requested because the increment is placed into place.
• In either case, DSDM development work continues by returning to the useful model
iteration activity.

100
101
Requirement Engineering
 Requirement Engineering

• The process of establishing the services the system should provide and the
constraints under which it must operate’ - Roger S. Pressman Software Engineering
– A practitioner’s Approach European Adaptation, fifth edition

• The appropriate mechanism for understanding what the customer wants, analyzing
need, assessing feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the requirements as they
are transformed into an operational system.
- Thayer, R.H. and M. Dorfman, Software requirements engineering.

103
Requirements Engineering
• The process of establishing the services that a customer requires from a system and
the constraints under which it operates and is developed.
• Begins during the communication activity and continues into the modeling activity
• Builds a bridge from the system requirements into software design and construction
• Allows the requirements engineer to examine
• the context of the software work to be performed
• the specific needs that design and construction must address
• the priorities that guide the order in which work is to be completed
• the information, function, and behavior that will have a profound impact on the resultant design

104
Requirements Engineering Tasks
• Seven distinct tasks
• Inception
• Elicitation (Induction)
• Elaboration
• Negotiation
• Specification
• Validation
• Requirements Management
• Some of these tasks may occur in parallel and all are adapted to the needs of the
project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and construction of the
software
105
Inception Task
• During inception, the requirements engineer asks a set of questions to
establish…
• A basic understanding of the problem
• The people who want a solution
• The nature of the solution that is desired
• The effectiveness of preliminary communication and collaboration between the customer
and the developer
• Through these questions, the requirements engineer needs to…
• Identify the stakeholders
• Recognize multiple viewpoints
• Work toward collaboration
• Break the ice and initiate the communication

106
Elicitation Task
• Elicitation may be accomplished through two activities
• Collaborative requirements gathering
• Quality function deployment
• Eliciting requirements is difficult because of
• Problems of scope in identifying the boundaries of the system or specifying
too much technical detail rather than overall system objectives
• Problems of understanding what is wanted, what the problem domain is, and
what the computing environment can handle (Information that is believed to
be "obvious" is often omitted)
• Problems of volatility because the requirements change over time

107
Collaborative Requirements Gathering
• Meetings are conducted and attended by both software engineers, customers, and
other interested stakeholders
• Rules for preparation and participation are established
• An agenda is suggested that is formal enough to cover all important points but
informal enough to encourage the free flow of ideas
• A "facilitator" (customer, developer, or outsider) controls the meeting
• A "definition mechanism" is used such as work sheets, flip charts, wall stickers,
electronic bulletin board, chat room, or some other virtual forum
• The goal is to identify the problem, propose elements of the solution, negotiate
different approaches, and specify a preliminary set of solution requirements

108
Quality Function Deployment
• This is a technique that translates the needs of the customer into technical
requirements for software.
• It emphasizes an understanding of what is valuable to the customer and then
deploys these values throughout the engineering process through functions,
information, and tasks.
• It identifies three types of requirements
• Normal requirements: These requirements are the objectives and goals stated for a product
or system during meetings with the customer.
• Expected requirements: These requirements are implicit to the product or system and may
be so fundamental that the customer does not explicitly state them.
• Exciting requirements: These requirements are for features that go beyond the customer's
expectations and prove to be very satisfying when present.

109
Elicitation Work Products
The work products will vary depending on the system, but should include one or more
of the following items:
1. A statement of need and feasibility
2. A bounded statement of scope for the system or product
3. A list of customers, users, and other stakeholders who participated in requirements
elicitation
4. A description of the system's technical environment
5. A list of requirements (organized by function) and the domain constraints that
apply to each
6. A set of preliminary usage scenarios (in the form of use cases) that provide insight
into the use of the system or product under different operating conditions
7. Any prototypes developed to better define requirements
110
Elaboration Task
• During elaboration, the software engineer takes the information obtained during
inception and elicitation and begins to expand and refine it.
• Elaboration focuses on developing a refined technical model of software
functions, features, and constraints.
• It is an analysis modeling task
• Use cases are developed.
• Domain classes are identified along with their attributes and relationships.
• State machine diagrams are used to capture the life on an object.
• The end result is an analysis model that defines the functional, informational,
and behavioral domains of the problem.

111
Negotiation Task
• During negotiation, the software engineer reconciles the conflicts between what
the customer wants and what can be achieved given limited business resources.
• Requirements are ranked (i.e., prioritized) by the customers, users, and other
stakeholders.
• Risks associated with each requirement are identified and analyzed.
• Rough guesses of development effort are made and used to assess the impact of
each requirement on project cost and delivery time.
• Using an iterative approach, requirements are eliminated, combined and/or
modified so that each party achieves some measure of satisfaction .

112
 The Art of Negotiation
• Recognize that it is not competition
• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit

113
 Specification Task

• A specification is the final work product produced by the requirements engineer.

• It is normally in the form of a software requirements specification.
• It serves as the foundation for subsequent software engineering activities.
• It describes the function and performance of a computer-based system and the
constraints that will govern its development.
• It formalizes the informational, functional, and behavioral requirements of the
proposed software in both a graphical and textual format.

114
Validation Task
• During validation, the work products produced as a result of requirements
engineering are assessed for quality.
• The specification is examined to ensure that
• all software requirements have been stated unambiguously
• inconsistencies, omissions, and errors have been detected and corrected
• the work products conform to the standards established for the process, the project, and the
product
• The formal technical review serves as the primary requirements validation
mechanism.
• Members include software engineers, customers, users, and other stakeholders.

115
Questions to ask when Validating Requirements
• Is each requirement consistent with the overall objective for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do
some requirements provide a level of technical detail that is inappropriate at this
stage?
• Is the requirement really necessary or does it represent an add-on feature that may
not be essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a specific
individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the
system or product?

116
Requirements Management Task
• During requirements management, the project team performs a set of
activities to identify, control, and track requirements and changes to
the requirements at any time as the project proceeds
• Each requirement is assigned a unique identifier
• The requirements are then placed into one or more traceability tables
• These tables may be stored in a database that relate features, sources,
dependencies, subsystems, and interfaces to the requirements
• A requirements traceability table is also placed at the end of the
software requirements specification

117
Software Requirement Specification (SRS)
 Software Requirement Specification (SRS)
• A software requirements specification (SRS) is a complete description of the behavior
of the system to be developed.
• It may include a set of use cases that describe interactions the users will have with the
software.
• A document that clearly and precisely describes, each of the essential requirements of
the software and the external interfaces.
• (functions, performance, design constraint, and quality attributes)
• Each requirement is defined in such a way that its achievement is capable of being
objectively verified by a prescribed method; for example inspection, demonstration,
analysis, or test.
• Software requirements specification establishes the basis for agreement between
customers and contractors or suppliers on what the software product is to do as well as
what it is not expected to do.
119
An example organization of an SRS
• Introduction  Specific requirements
• Purpose  External interface requirements
• Definitions  Functional requirements
• System overview  Introduction
 Inputs
• References
 Processing
• Overall description  Outputs
• Product perspective  Performance requirements
• System Interfaces  Design constraints
• User Interfaces  Standards Compliance
• Hardware interfaces  Logical database requirement
• Software interfaces
 Software System attributes
• Communication Interfaces
 Reliability
• Memory Constraints
 Availability
• Operations
 Security
• Site Adaptation Requirements
 Maintainability
• Product functions  Portability
• User characteristics  Other requirements 120
• Constraints, assumptions and dependencies
Characteristics of a Good SRS (IEEE 830)
1. Unambiguous
2. Complete
3. Verifiable
4. Consistent
5. Modifiable
6. Traceable
7. Usable during the Operation and Maintenance Phase

121
IEEE Software Document Definitions
• SQAP – Software Quality Assurance Plan (IEEE 730)
• SCMP – Software Configuration Management Plan (IEEE 828)
• STD – Software Test Documentation (IEEE 829)
• SRS – Software requirements specification (IEEE 830)
• SVVP – Software Validation & Verification Plan IEEE 1012
• SDD – Software Design Description IEEE 1016
• SPMP – Software Project Management Plan IEEE 1058
• SUD – Software User Documentation IEEE 1063

122
Requirements vs. Design
Requirements Design

Describe what will be delivered Describe how it will be done

Primary goal of analysis: Primary goal of design:

UNDERSTANDING OPTIMIZATION
There is more than one solution There is only one (final) solution

Customer interested Customer not interested (Most of the

time) except for external

123
Types of Requirement
• User requirements
• Statements in natural language plus diagrams of the services the system
provides and its operational constraints. Written for customers.

• System requirements
• A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints. Defines what should be
implemented so may be part of a contract between client and contractor.

124
User and System Requirements

125
Functional and Non-functional Requirements
• Functional requirements
• Statements of services the system should provide, how the system should
react to particular inputs and how the system should behave in particular
situations.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
• Often apply to the system as a whole rather than individual features or
services.
• Domain requirements
• Constraints on the system from the domain of operation
126
Functional Requirements
• Describe functionality or system services.
• Depend on the type of software, expected users and the type
of system where the software is used.
• Functional user requirements may be high-level statements of
what the system should do.
• Functional system requirements should describe the system
services in detail.

127
Non-functional Requirements
• These define system properties and constraints e.g. reliability, response time and
storage requirements. Constraints are I/O device capability, system
representations, etc.
• Process requirements may also be specified mandating a particular IDE,
programming language or development method.
• Non-functional requirements may be more critical than functional requirements. If
these are not met, the system may be useless.

128
Types of Non-functional Requirement

129
Users of a requirements document

130
Types of Requirements
• Functional requirements
• Performance requirements
• Speed, accuracy, frequency, throughput
• External interface requirements
• Design constraints
• Requirements are usually about “what”, this is a “how”.
• Quality attributes
• i.e. reliability, portability, maintainability, supportability

131
System Analyst
• A systems analyst is an IT professional who specializes in analyzing, designing and
implementing software systems.

• System analysts assess the suitability of information systems in terms of their intended
outcomes and liaise with end users, software vendors and programmers in order to
achieve these outcomes.

• Requirements analysis allows the software engineer (called an analyst or modeler in this
role) to:
• elaborate on basic requirements established during earlier requirement engineering
tasks
• build models that depict user scenarios, functional activities, problem classes and
their relationships, system and class behavior, and the flow of data as it is
transformed.

132
System Analyst
A systems analyst may:
• Identify, understand and plan for organizational and human impacts of planned systems, and ensure that new technical
requirements are properly integrated with existing processes and skill sets.
• Plan a system flow from the ground up.
• Interact with internal users and customers to learn and document requirements that are then used to produce business
requirements documents.
• Write technical requirements from a critical phase.
• Interact with designers to understand software limitations.
• Help programmers during system development, ex: provide use cases, flowcharts or even database design.
• Perform system testing.
• Deploy the completed system.
• Document requirements or contribute to user manuals.
• Whenever a development process is conducted, the system analyst is responsible for designing components and providing
that information to the developer.
133
Knowledge and Qualities of System Analyst
• An analyst must process various skills to effectively carry out the job.
Specifically, they must be divided into two categories:

• Interpersonal skill: This skills deal with relationships and the interface of the
analyst with people in business. They are useful in establishing trust, resolving
conflict, and communicating information.

• Technical skills: On other hand, focus on procedures and techniques for

operations analysis, systems analysis ,and computer science.

134
Knowledge and Qualities of System Analyst
The Interpersonal skills include: -
• Communication: Communication is not just reports, telephone conversations, and
interviews. It is people talking, listening, feeling and reacting to one another, their
experience and reactions.
• Understanding: Identifying problems and assessing their ramifications, having a grasp of
company goals and objectives, and showing sensitivity to the impact of the system on
people at work.
• Teaching: Educating people in use of computer system, selling the system to user, and
giving support when needed.
• Selling: Selling ideas and promoting innovations in problem solving using computers.

135
Knowledge and Qualities of System Analyst
The technical skills include: -
• Creativity: Helping users model ideas into concrete plans and developing candidate systems to
match user requirements.
• Problem solving: Reducing problems to their elemental levels for analysis, developing
alternative solutions to a given problem, and delineating the pros and cons of candidate system.
• Project management: Scheduling, performing well under time constraints, coordinating team
efforts, and managing costs and expenditures.
• Dynamic interface: Blending technical and nontechnical consideration in functional
specifications and general design.
• Questioning attitude and inquiring mind: Knowing the what, when, why, where, who and how a
system works.
• Knowledge of the basics of the computer and the business function.
136
Role of a System Analyst
• The primary role of a systems analyst is to study the problems and needs of an
organization in order to determine how people, methods, and information
technology can best be combined to bring about improvements in the organization.
(Hoffer, George & Valachich, 1999).
• The systems analyst is a key person analyzing the business, identifying
opportunities for improvement, and designing information systems to implement
these ideas (Dennis, Wixom & Tegarden, 2002).
• Systems analysts are key to the systems development process. The analyst's
primary focus is on what not how. What data does the system produce and
consume, what functions must the system perform, what interfaces are defined and
what constrains apply?" (Pressman, 1997).

137
Role of a System Analyst
• The systems analyst must understand both the business requirements of an organization
and the workings of the various technologies - the systems analyst builds the bridges
between organizational needs and technology solutions.
• “When a system developer walks away from the successful implementation of a good
system, what has been achieved is the acceptance and efficient operation of a technical
computer system by a human community.
• The system has both a technical and a social dimension - it is a socio-technical system .
• The project plan will have allowed for the evolution of the technical aspects of the system
with the active involvement of the human community that will operate it" (Lejk and
Deeks, 1998).

138
Feasibility Study and It’s Types
• The feasibility study is an evaluation and analysis of the potential of a proposed project which is
based on extensive investigation and research to support the process of decision making.
• It is quantifying benefits and costs
• Payback analysis
• Net Present Value Analysis
• Return on Investment Analysis
Following are different components of the feasibility study:
• Operational feasibility
• Economic feasibility
• Technical feasibility
• Human factors feasibility
• Legal/Political feasibility
139
Feasibility Study Contents
1. Purpose & scope of the study 5. Possible alternatives
 Objectives (of the study)  …including ‘do nothing’.
 who commissioned it & who did it,
6. Criteria for comparison
 sources of information,  definition of the criteria
 process used for the study,
 how long did it take,…
7. Analysis of alternatives
 description of each alternative
2. Description of present situation  evaluation with respect to criteria
 organizational setting, current system(s).  cost/benefit analysis and special implications.
 Related factors and constraints.
8. Recommendations
3. Problems and requirements  what is recommended and implications
 What’s wrong with the present situation?  what to do next;
 What changes are needed?  E.g. may recommend an interim solution and a
permanent solution
4. Objectives of the new system.
 Goals and relationships between them 9. Appendices
 to include any supporting material.

140
User Transaction Requirement
• Each user view will involve certain transactions, stipulating how the
data is to be used
• There are three broad categories:
• Data entry: every data item needs to be created somewhere
• Data update and deletion
• Data queries
• Transactions should be related to the user view to ensure all functions
are supported
• Do transactions needed to be atomic
141
User Design Requirements
• There are tools for guiding the user design process and for discussing user
design requirements with users.
• Mostly, Use Cases are used for this.
• A design specification provides explicit information about the requirements for
a product and how the product is to be put together.

142
Structure Model / Class Model
Different Views of a System
• A view is a projection into the organization and structure of a
system’s model, focused on one aspect of a system.
• Five most important views :
• Use case view.
• Design view.
• Process view.
• Implementation view.
• Deployment view.

144
Diagrams
• A diagram is a graphical projection into the elements
that make up a system.
• Each diagram provides a view into the elements that
make up the system.
• Structural diagrams to view the static parts and
Behavioral diagrams to view the dynamic parts of a
system.

145
Structural Diagrams
• Structure models emphasize the things that must be present in the system being
modeled.
• Since structure diagrams represent the structure, they are used extensively in
documenting the software architecture of software systems.
• The UML’s structural diagrams are used to visualize, specify, construct, and
document the static aspects of a system.
• Static aspects: represent system’s relatively stable skeleton and scaffolding.
• UML’s four/six structural diagrams:
• Class diagrams
• Object diagrams
• Component diagrams • Composite Structure
• Deployment diagrams • Package
146
 Types of Structural Diagrams
• Class diagram: describes the structure of a system by showing the system's classes, their
attributes, and the relationships among the classes.
• Object diagram: shows a complete or partial view of the structure of a modeled system at a
specific time.
• Component diagram: describes how a software system is split up into components and shows the
dependencies among these components.
• Deployment diagram: describes the hardware used in system implementations and the execution
environments and artifacts deployed on the hardware.
• Composite structure diagram: describes the internal structure of a class and the collaborations
that this structure makes possible.
• Package diagram: describes how a system is split up into logical groupings by showing the
dependencies among these groupings.
147
Behavioral Model /
State Model

148
 Behavioral Model
• Behavioral models describe the internal dynamic aspects of a system that
supports the business processes in an organization.
• Dynamic aspects: represent a system’s changing parts.
• Behavior diagrams emphasize what must happen in the system being modeled.
• Since behavior diagrams illustrate the behavior of a system, they are used
extensively to describe the functionality of software systems.
• Diagrams interact by passing events and through side effects of guard conditions.
• Events and guard conditions must match across diagrams in the model.

149
• During the analysis phase, analysts use behavioral models to capture a basic
understanding of the dynamic aspects of the underlying business process.
• During the analysis phase, the structural model presents the logical organization of
data without indicating how the data are stored, created, or manipulated so that
analysts can focus on the business without being distracted by technical details.
• Later, during the design phase, the structural model is updated to reflect exactly
how the data will be stored in databases and files.
• Traditionally, behavioral models have been used primarily during the design phase
where analysts refine the behavioral models to include implementation details.

150
• Behavioral models that are used to represent the underlying details of a business
process portrayed by a use case model.
• In UML, interaction diagrams (sequence and communication) are used for this
type of behavioral model.
• Behavioral model that is used to represent the changes that occur in the
underlying data.
• UML uses behavioral state machines for this.

151
Types of Behavioural Diagrams
• UML’s three behavioural diagrams:
• Use case diagrams
• State Machine diagrams
• Activity diagrams
• Use case diagram: describes the functionality provided by a system in terms of actors,
their goals represented as use cases, and any dependencies among those use cases.
• State Machine diagram: describes the states and state transitions of the system.
• Activity diagram: describes the business and operational step-by-step workflows of
components in a system. An activity diagram shows the overall flow of control.

152
Creating Behavioral Model
• An iterative process
• iterating over the individual behavioral models (e.g., interaction (sequence and
communication) diagrams and behavioral state machines)
• iterating over the functional and structural models.
• As the behavioral models are created, making changes to the structural models
may be required.

153
Interaction Model

154
Interaction Diagram
• Interaction diagrams, a subset of behaviour diagrams, emphasize the flow of
control and data among the things in the system being modeled.
• Used to describe some type of interactions among the different elements in the
model. So this interaction is a part of dynamic behaviour of the system.
• Purposes of interaction diagram:
• To capture dynamic behaviour of a system.
• To describe the message flow in the system.
• To describe structural organization of the objects.
• To describe interaction among objects.

155
Types of Interaction Models
• Sequence diagram: shows how objects communicate with each other in terms of
a sequence of messages. Also indicates the lifespans of objects relative to those
messages.
• Communication diagram: shows the interactions between objects or parts in
terms of sequenced messages. They represent a combination of information taken
from Class, Sequence, and Use Case Diagrams describing both the static
structure and dynamic behavior of a system.
• Interaction overview diagram: provides an overview in which the nodes
represent interaction diagrams.
• Timing diagram: are a specific type of interaction diagram, where the focus is
on timing constraints.
156
Some Extra Points
• Primary purposes of behavioral models
• to show how the underlying objects in the problem domain will collaborate to support each of
the use cases.
• Structural models
• represent the objects and the relationships between them,

• Behavioral models
• depict the internal view of the business process that a use case describes.

• The process can be shown by the interaction

• taking place between the objects that collaborate to support a use case through the use of
interaction diagrams.
• It is also possible to show the effect that the set of use cases that make up the system has on the
objects in the system through the use of behavioral state machines.
157
158
Class Modelling
Class Modeling
• Class Modeling : - The process to visualize, specify, construct, and
document the static aspects of a system.
• Static View = Structure = Objects by which system is made of.
• That’s why, the purpose of class modeling is to describe objects.
• To complete the class modelling, you have to describe class diagram
and then object diagrams.

160
Steps during class modeling
• Steps during class modeling
• 1. Class identification
• Based on the fundamental assumption that we can find abstractions
• 2. Find the attributes
• 3. Find the methods
• 4. Find the associations between classes

161
Class Identification
1) Perform a grammatical parse of the problem statement or use cases
2) Classes are determined by underlining each noun or noun clause
3) A class should NOT have an imperative procedural name (i.e., a verb)
4) List the potential class names in a table and "classify" each class according to
some taxonomy and class selection characteristics

Potential classes General classification Selection Characteristics

162
Class Identification
• General classifications for a potential class
• External entity (e.g., another system, a device, a person)
• Thing (e.g., report, screen display)
• Occurrence or event (e.g., movement, completion)
• Role (e.g., manager, engineer, salesperson)
• Organizational unit (e.g., division, group, team)
• Place (e.g., manufacturing floor, loading dock)
• Structure (e.g., sensor, vehicle, computer)

163
Class Identification
• Six class selection characteristics
1) Retained information
– Information must be remembered about the system over time
2) Needed services
– Set of operations that can change the attributes of a class
3) Multiple attributes
– Whereas, a single attribute may denote an atomic variable rather than a class
4) Common attributes
– A set of attributes apply to all instances of a class
5) Common operations
– A set of operations apply to all instances of a class
6) Essential requirements
– Entities that produce or consume information

164
Class Identification - Example
• Manipal University Jaipur wants to make a library management system for
its library.
• Library has 10000 books.
• For memberships of library, there are 2 types : - Faculty & Students.
• Librarian should issue books.
• There should be functionality to deposit books.
• There are four types of books.
• Magazine
• E-Books
• Journals
• Text Books. 165
Class Identification - Example
Potential classes General classification Selection Characteristics
MUJ External Entity
Library Management Structure
System
Library Organizational Unit
Book External Entity
Membership Role
Faculty External Entity
Student External Entity
Librarian Role
Magazine External Entity
E-Books External Entity
Journals External Entity
Text Books External Entity
166
Defining Attributes of a Class
• Attributes of a class are those nouns from the grammatical parse that reasonably
belong to a class
• Attributes hold the values that describe the current properties or state of a class
• An attribute may also appear initially as a potential class that is later rejected
because of the class selection criteria
• In identifying attributes, the following question should be answered
• What data items (composite and/or elementary) will fully define a specific class in the
context of the problem at hand?
• Usually an item is not an attribute if more than one of them is to be associated
with a class

167
 Defining Operations of a Class
• Operations define the behavior of an object
• Four categories of operations
• Operations that manipulate data in some way to change the state of an object (e.g., add, delete,
modify)
• Operations that perform a computation
• Operations that inquire about the state of an object
• Operations that monitor an object for the occurrence of a controlling event
• An operation has knowledge about the state of a class and the nature of its
associations
• The action performed by an operation is based on the current values of the
attributes of a class
• Using a grammatical parse again, circle the verbs; then select the verbs that relate
to the problem domain classes that were previously identified .
168
 Class Diagram
• Recall: A class is a collection of objects with common structure, common
behavior, common relationships and common semantics
• A class diagram
• expresses class definitions to be implemented
• lists name, attributes, and methods for each class
• shows relationships between classes
• describes the structure of a system.
• Most common diagram.
• The main building block in object oriented modeling.

169
 Where do we use class diagrams
Class diagrams are used in:
• Analysis To build a conceptual domain model with semantic associations
between concepts
• Design Structural model of a design in terms of class interfaces
• Implementation Source code documentation, exposing the implementation

170
Class Diagram - Notation
• A class with three
sections. Produt

• The upper part holds the serialNumber

name of the class name
price
• The middle part contains Class Name
buy()
the attributes of the class display()
• The bottom part gives the Attributes
methods or operations the
class can take or Operations
undertake

171
Class Name - Signature
• Name should start with capital letter.
• It should be noun.

172
Attributes - Signature
[visibility] name [[multiplicity]] [: type] [=initial value] [{property}]

• First word of the name should start with small letter followed by capital letter for
next words.
• visibility: the access rights to the attribute
- multiplicity: how many instances of the attribute are they:
- middleName [0..1] : String, phoneNumber [1..*]

- Type: the type of the attribute (integer, String, Person, Course)

- initial value: a default value of the attribute
- salary : Real = 10000, position : Point = (0,0)

- property: predefined properties of the attribute

- Changeable, readOnly, addOnly, frozen (C++: const, Java: final)
Attributes - Examples
+ isLightOn : boolean = false
- numOfPeople : int
mySport
+ passengers : Customer[0..10]
- id : long {readOnly}
Operations - Signature
[visibility] name ([parameter-list]) [: return-type] [{property}]

• An operation can have zero or more parameters, each has the syntax:
• [direction] name : type [=default-value]
• Direction can be: in (input paremter - can’t be modified), out (output
parameter - may be modified), inout (both, may be modified)
• Property:
• {leaf} – concrete operation
• {abstract} – cannot be called directly
• {isQuery} – operation leaves the state of the operation unchanged
• …
• Omit return_type on constructors and when return type is void
Operations - Examples What’s the
difference?
+ isLightOn() : boolean
+ addColor(newColor : Color)
+ addColor(newColor : Color) : void
# convertToPoint(x : int, y : int) : Point
- changeItem([in] key : string, [out] newItem :
Item) : int
Class Diagram - Example

177
Scope & Visibility
• Instance Scope — each instance of the class holds its own value.
• Class Scope — one value is held for all instances of the class (underlined).

Instance scope
Frame

class scope
header : FrameHeader
uniqueID : Long

+ addMessage( m : Message ) : Status

public # setCheckSum()
- encrypt()
protected
- getClassName()

private

• visibility: + public; # protected; - private;

~ package; / derived
• Underline static attributes and methods
• By default, attributes are hidden and operations are visible. 178
Responsibilities
• Anything that a class knows or does (Contract or obligation)
• An optional 4th item carried out by attributes and operations.
• Free-form text.
• One phrase per responsibility.

Account

Responsibilities
-- handles deposits
-- reports fraud to managers

179
Multiplicity
• It specifies the number of instances of one class that
may relate to a single instance of the associated class.
• UML diagrams explicitly list multiplicity at the end of
association lines.
• Intervals are used to express multiplicity:
• 1 (exactly one)
• 0..1 (zero or one)
• 1..* (one or more)
• 0..* (zero or more)
• 3..5 (three to five inclusive)
Different levels of detail
Tips for modeling
Express as much or as little detail as needed
Often, a rectangle with a name is enough
write <<interface>> on top of interfaces' names
use italics for an abstract class name
Perhaps a method or an attribute clarifies
Simple is good
Sketches on paper or white board are effective

10
UML

The main purpose of UML is to

 support communication about the analysis and design of the system
being developed
 support the movement from the problem domain in the "world" to
the solution domain in the machine
 Two views of the same system
• one view has diagrams
• source code is another view
Sometimes it's nice to look at the overview
• Reverse engineer your code with a UML tool to see how your code looks
in UML
182 6-182
 UML is a Modeling Language
 UML
 graphical notation to describe software design
 has rules on how to draw models of
classes
associations between classes
message sends between objects
 has become the de facto industry standard
Not official, but everyone uses it
 like a blueprint to show what is going on during analysis, design
and implementation
Some Projects require UML documentation
183 6-183
 UML Defined by the Authors
The Unified Modeling Language User Guide, Booch,
Rumbaugh, Jacobson states:
The UML is a language for
 visualizing
 specifying
 constructing
 documenting
the artifacts of a software intensive system

184 6-184
 First up: Class Diagrams

A class diagram
 expresses class definitions to be implemented
 lists name, attributes, and methods for each class
 shows relationships between classes
UML allows different levels of detail on both the attributes
and the methods of one class
 could be just the the class name in a rectangle
 or like the general form shown on the next slide

185 6-185
 Software Specification (Class Name)

attribute
attribute : type
attribute : type = initial value
classAttribute
derivedAttribute
...

method1()
method2(parameter : Type) : return type
abstractMethod()
+publicMethod()
-privateMethod()
#protectedMethod()
classMethod()
...
186 6-186
 AccountCollection

- allAccounts : HashMap

+AccountCollection ()
+getAccountWithID (ID: String) : Account
+add(accountToAdd: Account) : boolean
+iterator() : Iterator

Note: iterator is needed by the

bank manager

187 6-187
Sterotypes

Stereotype is a UML element that allows

designers to extend the UML vocabulary
 Often used to distinguish an abstract class name
from an interface, both of which are written in
italic
<<interface>>
Iterator
+hasNext(): boolean
+next(): Object
+remove(): void

188 6-188
 Different levels of detail

Tips for modeling

 Express as much or as little detail as needed
 Often, a rectangle with a name is enough
perhaps a method or an attribute clarifies
 Simple is good
 Sketches on paper or white board are effective

189 6-189
Relationships

Three Relationships in UML

1) Dependency
2) Association
3) Generalization

190 6-190
1) Dependency: A Uses Relationship

Dependencies
 occurs when one object depends on another
 if you change one object's interface, you need to
change the dependent object
 arrows point from dependent to needed objects
CardReader
Jukebox
CDCollection

SongSelector
191 6-191
2) Association: Structural Relationship

Association
 a relationship between classes indicates some meaningful or
interesting connection
 Associations can be labeled getAccountWithID for example
 BTW: The box with association is an official UML comment, must have that fold 

association

getAccountWithID
Jukebox JukeboxAccountCollection
1 1

192 6-192
Associations

Associations imply
 our knowledge that a relationship must be preserved for some
time (0.01 ms to forever)
Between what objects do we need to remember a relationship?
• Does a Transaction need to remember Account?
• Would AccountCollection need to remember Accounts?

Stores
AccountCollection Account
1 0..*

193 6-193
Notation and Multiplicity Adornments
UML Association:
 a line between two concepts and a name
 they are bi-directional * T
zero or more;
"many"
 can have a multiplicity
 exist in class diagrams 1..*
T one or more

1..52
T one to fifty two

5
Multiplicity T exactly five

adornments
194 6-194
Association
Names • Read these Type-VerbPhrase-Type
• POST is a Point of Sale Terminal)
Store • Not shown here: Attributes and Methods
1
• This just shows associations between objects
C ontai ns

1. . *

POST C aptures Sal e Pai d- by Payment

1 1. . * 1 1

A i rl i ne

1
Empl oys

1. . *
A ssi gned- to A ssi gned- to
Person Fl i ght Pl ane
1 * * 1
1 *

Supervi ses
195 6-195
 Aggregation: A Special Association

Aggregation: whole/part relationships

 An association that models HAS-A relationships
 The objects can exist independently of each other
 No one object is more important than the other
 Place an open diamond on the whole
 School contains a collection of Student objects
School Student
1..* *

 In Java, this is the same as an association, an instance variable,

no special syntax 196 6-196
 Composition: A Special Association
Composition: Stronger relationship
 One can not exist without the other
 If the school folds, students live on
but the departments go away with the school
 If a department closes, the school can go on AIC* e.g.
School Department
1 1..*
1..*

*
Student
 Model aggregation or composition? When in doubt, use association (just a
simple line) don't sweat the diff in 335
197 6-197
Sequence Diagrams
 Interaction diagrams describe how groups of objects
collaborate in some behavior
 The UML defines several forms of interaction
diagram, the most common is the sequence diagram
 A class diagram shows a fixed view of a system
 A sequence diagram represents a dynamic view of a
system by capturing message sends over time
 Can document a scenario such as
Dealer deals cards to all players
Withdraw Money when there is enough balance
Withdraw Money when there is not enough balance
198 6-198
Sequence Diagrams

Not good at showing details of algorithms

such as loops and conditional
Good at showing the calls between
participants
Gives a good picture about which participants
are doing which processing

199 6-199
Syntax
Objects are lined up on top in rectangles
Object names :CardReader
Dashed lines represent lifetime of objects
Rectangles are activation lines
 When the object is "alive"
 Activation bar of the receivers of the message is
smaller than the sender's activation bar
Not much detail written

200 6-200
Example

Scenario: The user tries to use an ATM, but the account is not known
201 6-201
Scenario: The user
successfully withdraws
money from an ATM

202 6-202