Importance of Software Engineering

Software
Capstone
Introduction to Project
Project
Management

Software Engineering

Computer Science Software Engineering Data Structures

Computer and Algorithms
Data Structures
 theory  the practicalities of Networks
and Algorithms
 fundamentals Design
developing projects
 delivering useful
SOFTWARE ENGINEERING
software
Programming
Database
Programming Management
System

Scope and Necessity of Software Example: Building a wall

Engineering
• Software engineering is an engineering approach for software
• Can be built with minimum knowledge
development.
• Much expertise not required
Systematic
Collection of
Past
Experiences

• A small program can be written without using software

engineering principles.

• But if one wants to develop a large software product, then

software engineering principles are indispensable to achieve a
good quality software cost effectively.
 Constructing a Multi-storeyed Building

requisite knowledge about

 the strength of materials,
 testing,
 planning,
 architectural design

Scope and Necessity of Software Contd...

Engineering
• Without using software engineering principles, it would be
difficult to develop large programs. In industry, it is usually
needed to develop large programs to accommodate

and Time taken to

Complexity, Effort
multiple functions.

• A problem with developing such large commercial

Develop
programs is the complexity and difficulty levels of the
programs increase exponentially with their sizes as
shown in Fig. 1.1 Size

Fig. 1.1: Increase in development time and effort with

problem size
 Scope and Necessity of Software
Engineering…
• For example , a program of size 1,000 Lines of Code
(LOC) has some complexity.
• So, a program with 10,000 LOC is not just 10 times
more difficult to develop, but may as well turn out to
be 100 times more difficult unless software engineering
principles are used.

• In such situations software engineering techniques

come to rescue.
• Software engineering helps to reduce the
programming complexity. Software engineering
principles use two important techniques to reduce
problem complexity:
abstraction and decomposition.

Evolving Role of Software Evolving Role of Software…

 IBM Data Compilation (2001)
Evolving Role of Software…
Managers and Technical Persons are asked:

Why does it take so long to Why cannot we find all

get the program finished? errors before release?

Why are costs so high? Why do we have difficulty in measuring

progress of software development ?

Factors Contributing to Software Crisis Some Software Failures

https://www.youtube.com/watch?v=EMVBLg2MrLs

Large Problems Lack of adequate training in software

Increasing skill shortage Low productivity improvements

Some Software Failures Some Software Failures…

Some Software Failures… Some Software Failures…

 Some Software Failures… Some Software Failures…

Some Software Failures… Some Software Failures…

Financial Software Windows XP
Many companies have experienced failures in
their accounting system due to faults in the • Microsoft released Windows XP on October 25, 2001.
software itself. The failures range from producing
the wrong information to the whole system • On the same day company posted 18 MB of compatibility
crashing. patches on the website for bug fixes, compatibility
updates, and enhancements.

• Two patches fixed important security holes.

The Worst Computer Bugs in History:
What is Software?
Race conditions in Therac-25
The product that software professionals build and then
support over the long term.
https://www.youtube.com/watch?v=uEvu2PlDhO0
Software encompasses:

(1) Instructions (computer programs) that when executed

provide desired features, function and performance.

(2) Data Structures that enable the programs to

adequately store and manipulate information and

(3) Documentation that describes the operation and use

of the programs.

Documentation consists of different Documentation consists of

types of manuals are different types of manuals are
 Software Products Types of Software Products

• Software product is defined as :

Computer programs and associated documentation • Developed to be sold to a range of different customers
• Sold on the open market to any customer who is able to
buy them.
Generic • For Example:
• Word processor – Word.
• Spreadsheet – Excel.

• Developed for a single customer or organization

according to their specification
Bespoke/Custom/ • Sold to a specific customer.
• Software products may be developed for a particular customer or • For Example:
may be developed for a general market tailor-made software • software for the cafe franchise
• Also called as COTS (Commercial Off The Shelf)

Software Products Software Process

• A set of activities whose goal is the development or evolution of

software
• Software product is a product designated • Generic activities in all software processes are:
for the delivery to the user.
Source Code/ People Test Results • Specification - what the system should do and its development constraints
Object Code
• Development - production of the software system
Plan Data
• Validation - checking that the software is what the customer wants
Documenta
tion Manuals • Evolution - changing the software in response to changing demands
 What is software engineering?
Software Characteristics
Software engineering is an engineering discipline
• Software is developed which is concerned with all aspects of software
It is not manufactured. It is not something that will automatically roll out of an
assembly line. It ultimately depend on individual skill and creative ability production
• Software does not Wear Out
Software is not susceptible to the
Burn in Phase Wear out phase Software engineers should
environmental melodies and it does Useful Life Phase
– adopt a systematic and organised approach to their
not suffer from any effects with time.
work
• Software is Highly Malleable – use appropriate tools and techniques depending on
In case of software one can modify the product itself rather easily without
necessary changes. • the problem to be solved,
• the development constraints and
• the resources available

SE history Why Software Engineering?

• SE introduced first in 1968 – conference about • Software development is hard !
“software crisis” when the introduction of third • Important to distinguish “easy” systems (one
generation computer hardware led more complex developer, one user, experimental use only) from
software systems then before “hard” systems (multiple developers, multiple users,
• Early approaches based on informal products)
methodologies leading to • Experience with “easy” systems is misleading
– Delays in software delivery – One person techniques do not scale up
– Higher costs than initially estimated
• Analogy with bridge building:
– Unreliable, difficult to maintain software
– Over a stream = easy, one person job
• Need for new methods and techniques to manage
– Over River Ganga … ? (the techniques do not scale)
the production of complex software.
 What are the attributes of good
Why Software Engineering ?
software?
• The problem is complexity The software should deliver the required functionality
• Many sources, but size is key: and performance to the user and should be
maintainable, dependable and usable
– UNIX contains 4 million lines of code
• Maintainability
– Windows 2000 contains 108 lines of code – Software must evolve to meet changing needs
• Dependability
– Software must be trustworthy
Software engineering is about managing • Efficiency
– Software should not make wasteful use of system resources
this complexity. • Usability
– Software must be usable by the users for which it was
designed

What are the costs of software Software Applications

engineering? System software
• System software is a collection of programs written
• Roughly 60% of costs are development costs, to service other programs.
40% are testing costs. For custom software,
evolution costs often exceed development costs • Some system software (e.g., compilers, editors, and
file management utilities)
• Costs vary depending on the type of system being
developed and the requirements of system • Other systems applications (e.g., operating system
attributes such as performance and system components, drivers, telecommunications the
reliability system software area is characterized by heavy
• Distribution of costs depends on the development interaction with computer hardware;
model that is used
Real-time software.
• Software that monitors/analyzes/controls Business software.
real-world events as they occur is called real time. • Business information processing is the largest
• Elements of real-time software include a data single software application area.
gathering component that collects and formats
information from an external environment • Discrete "systems" (e.g., payroll, accounts
• An analysis component that transforms information receivable/payable, inventory) have evolved
as required by the application into management information system (MIS)
• a control/output component that responds to the software that accesses one or more large
external environment databases containing business information.
• and a monitoring component that coordinates all
other components so that real-time response
(typically ranging from 1 millisecond to 1 second)
can be maintained.

Engineering and scientific software.

Embedded software
• Engineering and scientific software have been
• Intelligent products have become
characterized by "number crunching"
commonplace in nearly every consumer and
algorithms.
industrial market.
• Applications range from astronomy to
volcanology, from automotive stress analysis
to space shuttle orbital dynamics, and from • Embedded software resides in read-only
molecular biology to automated memory and is used to control products and
manufacturing. systems for the consumer and industrial
markets.
Personal computer software Web-based software
• The personal computer software market has • The Web pages retrieved by a browser are
burgeoned over the past two decades. software that incorporates executable
instructions
• Word processing, spreadsheets, computer
• (e.g., CGI, HTML, Perl, or Java), and data (e.g.,
graphics, multimedia, entertainment,
hypertext and a variety of visual and audio
database management, personal and business formats).
financial applications, external network, and • In essence, the network becomes a massive
database access are only a few of hundreds of computer providing an almost unlimited
applications. software resource that can be accessed by
anyone with a modem.

Artificial intelligence software.

• Artificial Intelligence (AI) software makes use Chapter 2
of non-numerical algorithms to solve complex
problems that are not amenable to ■ Process Models
computation or straightforward analysis. Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
• Expert systems, also called knowledge based by Roger S. Pressman

systems, Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

• Pattern recognition (image and voice), For non-profit educational use only

artificial neural networks, theorem proving,

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

and game playing are representative of All copyright information MUST appear if these slides are posted on a website for student
use.
applications within this category.
Slide Set - 3
 A Layered Technology
A Generic Process Model
Software Engineering

tools

methods

process model

a “quality” focus

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

A Process Framework
Framework Activities
■ Communication
Process framework
■ Planning
Framework activities ■ Modeling
work tasks ■ Analysis of requirements
work products ■ Design
milestones & deliverables ■ Construction
■ Code generation
QA checkpoints ■ Testing
Umbrella Activities ■ Deployment

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
 Process Flow
Umbrella Activities
■ Software project management
■ Formal technical reviews
■ Software quality assurance
■ Software configuration management
■ Work product preparation and production
■ Reusability management
■ Measurement
■ Risk management

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Identifying a Task Set Process Assessment and Improvement

Standard CMMI Assessment Method for Process Improvement
■ A task set defines the actual work to be done to ■
(SCAMPI) — provides a five step process assessment model that incorporates
accomplish the objectives of a software engineering five phases: initiating, diagnosing, establishing, acting and learning.
CMM-Based Appraisal for Internal Process Improvement (CBA
action. ■
IPI)—provides a diagnostic technique for assessing the relative maturity of a
■ A list of the task to be accomplished software organization; uses the SEI CMM as the basis for the assessment
[Dun01]
■ A list of the work products to be produced ■ SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements
■ A list of the quality assurance filters to be applied for software process assessment. The intent of the standard is to assist
organizations in developing an objective evaluation of the efficacy of any
defined software process. [ISO08]

■ ISO 9001:2000 for Software—a generic standard that applies to any

organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies. [Ant06]
Software life cycle Software Life Cycle
▪ identifies all the activities required for product
Series of identifiable stages that a development,
software product undergoes during its ▪ establishes a precedence ordering among the different
activities,
life time:
▪ Divides life cycle into phases.
• Feasibility study
• Requirements analysis and specification,
• Design,
• Coding,
• Testing
• maintenance.

Life Cycle Model is Adhered to, Attention to Specific models

■ the project manager can at any time fairly ■ Classical waterfall model
accurately tell, ■ Iterative waterfall,
• at which stage (e.g., design, code, test, etc. ) of the ■ Evolutionary,
project is. ■ Prototyping, and
■ Otherwise, it becomes very difficult to track the ■ Spiral model
progress of the project
• the project manager would have to depend on the
guesses of the team members.
The Waterfall Model The V-Model

The Incremental Model The RAD Model

Evolutionary Models: Prototyping Evolutionary Models: The Spiral

Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

Iterative vs Incremental Model Evolutionary Models: Concurrent

Source: Scrum Guide 6; 7 at slideshare.net

Still Other Process Models The Unified Process (UP)
■ Component based development—the process to apply elaboration
when reuse is a development objective
inception
■ Formal methods—emphasizes the mathematical
specification of requirements
■ AOSD—provides a process and methodological approach
for defining, specifying, designing, and constructing
aspects
■ Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely
aligned with the Unified Modeling Language (UML)

UP Phases UP Work Products

Agile Video Links
■ https://www.youtube.com/watch?v=yagk8a5w_4U ■ Waterfall Model
https://www.youtube.com/watch?v=Y_A0E1ToC_I
■ Scrum
https://www.youtube.com/watch?v=WxiuE-1ujCM ■ Prototyping Model
https://www.youtube.com/watch?v=dlxxXF0wrdc
https://www.youtube.com/watch?v=v8WzC5bCqY0

■ Spiral Model
https://www.youtube.com/watch?v=6gMgXP1Sa9I

Requirements Gathering
( 7 Step Model )
Inception

Elicitation

Requirement Gathering Elaboration

Negotiation

Specification

Validation

Requirements
Management
 Inception Task The First Set of Questions
These questions focus on the customer, other stakeholders, the overall
• During inception, the requirements engineer asks a set of questions to goals, and the benefits
establish…
– A basic understanding of the problem
– The people who want a solution
– The nature of the solution that is desired • Who is behind the request for this work?
– The effectiveness of preliminary communication and collaboration between the
customer and the developer
• Who will use the solution?
• Through these questions, the requirements engineer needs to… • What will be the economic benefit of a successful solution?
– Identify the stakeholders • Is there another source for the solution that you need?
– Recognize multiple viewpoints
– Work toward collaboration
– Break the ice and initiate the communication

Requirements Gathering Elicitation Task

(Elicitation)
Inception
• Eliciting requirements is difficult because of
– Problems of scope in identifying the boundaries of the
system or specifying too much technical detail rather than
Elicitation overall system objectives
– Problems of understanding what is wanted, what the
Elaboration problem domain is, and what the computing environment
can handle (Information that is believed to be "obvious" is
Negotiation
often omitted)
– Problems of volatility because the requirements change
over time
Specification
• Elicitation may be accomplished through two activities
– Collaborative requirements gathering
Validation
– Quality function deployment
Requirements
Management
 QFD identifies three Types of Requirements
Quality Function Deployment (QFD) • Normal Requirements. The objectives and goals that are stated for a
product
• Function deployment determines the “value” (as perceived or system during meetings with the customer. If these requirements are present,
the customer is satisfied. Examples of normal requirements might be requested
by the customer) of each function required of the system types of graphical displays, specific system functions, and defined levels of
performance. e.g Customer requested Notepad Editor i.e EDIT function

• Information deployment identifies data objects and events • Expected Requirements. These requirements are implicit to the product or
system and may be so fundamental that the customer does not explicitly state
them. Their absence will be a cause for significant dissatisfaction.
Examples of expected requirements are: ease of human/machine
• Task deployment examines the behavior of the system interaction, overall operational correctness and reliability, and ease of software
installation.
e.g: CUT, COPY, PASTE, REPLACE,DELETE
• Value analysis determines the relative priority of • Exciting Requirements. These features go beyond the customer’s
expectations and prove to be very satisfying when present. For example, word
requirements processing software is requested with standard features. The delivered product
contains a number of page layout capabilities that are quite pleasing and
unexpected.
E,g. Software provide more fuctionality like CUT, COPY, PASTE, REPLACE and
DELETE Graphic content, SPELL Checker
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright
2009 by Roger Pressman.

Elicitation Work Products Use-Cases

• A collection of user scenarios that describe the thread of usage of
The work products will vary depending on the system, but should a system
include one or more of the following items • Each scenario is described from the point-of-view of an “actor”—a
person or device that interacts with the software in some way
• A statement of need and feasibility • Each scenario answers the following questions:
• A bounded statement of scope for the system or product – Who is the primary actor, the secondary actor (s)?
• A list of customers, users, and other stakeholders who participated in – What are the actor’s goals?
requirements elicitation – What preconditions should exist before the story begins?
• A description of the system's technical environment – What main tasks or functions are performed by the actor?
• A list of requirements (organized by function) and the domain – What extensions might be considered as the story is described?
constraints that apply to each – What variations in the actor’s interaction are possible?
• A set of preliminary usage scenarios (in the form of use cases) that – What system information will the actor acquire, produce, or change?
provide insight into the use of the system or product under different – Will the actor have to inform the system about changes in the external environment?
operating conditions – What information does the actor desire from the system?
• Any prototypes developed to better define requirements – Does the actor wish to be informed about unexpected changes?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger
Pressman.
 Building the Analysis Model
• Elements of the analysis model State Diagram
– Scenario-based elements
• Functional—processing narratives for software functions
Reading
• Use-case—descriptions of the interaction between an “actor” Command
State name
s
and the system System status = “ready”
Display msg = “enter cmd”

– Class-based elements
Display status = steady
State variables

• Implied by scenarios Entry/subsystems ready

Do: poll user input panel
Do: read user input
– Behavioral elements Do: interpret user input State activities

• State diagram
– Flow-oriented elements
• Data flow diagram

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright
copyright 2009 by Roger Pressman. 2009 by Roger Pressman.

Requirements Gathering Elaboration Task

(Elaboration)
• During elaboration, the software engineer takes the information
Inception obtained during inception and elicitation and begins to expand and
refine it
Elicitation • Elaboration focuses on developing a refined technical model of
software functions, features, and constraints
Elaboration
• It is an analysis modeling task
– Use cases are developed
– Domain classes are identified along with their attributes and relationships
Negotiation
– State machine diagrams are used to capture the life on an object
• The end result is an analysis model that defines the functional,
Specification informational, and behavioral domains of the problem

Validation

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

Requirements
Management

Requirements Gathering
The Art of Negotiation
(Specification)
Inception

• Recognize that it is not competition Elicitation

• Map out a strategy
• Listen actively Elaboration
• Focus on the other party’s interests
Negotiation
• Don’t let it get personal
• Be creative
Specification
• Be ready to commit
Validation

Requirements
Management
 Typical Contents of a Software
Specification Task
Requirements Specification
• Requirements
• A specification is the final work product produced by the – Required states and modes
requirements engineer – Software requirements grouped by capabilities (i.e., functions, objects)
• It is normally in the form of a software requirements specification – Software external interface requirements
• It serves as the foundation for subsequent software engineering – Software internal interface requirements
activities – Software internal data requirements
• It describes the function and performance of a computer-based – Other software requirements (safety, security, privacy, environment,
hardware, software, communications, quality, personnel, training, logistics,
system and the constraints that will govern its development etc.)
• It formalizes the informational, functional, and behavioral – Design and implementation constraints
requirements of the proposed software in both a graphical and • Qualification provisions to ensure each requirement has been met
textual format – Demonstration, test, analysis, inspection, etc.
• Requirements traceability
– Trace back to the system or subsystem where each requirement applies

Requirements Gathering (Validation) Validation Task

Inception • During validation, the work products produced as a result of
requirements engineering are assessed for quality
Elicitation • The specification is examined to ensure that
– all software requirements have been stated unambiguously
– inconsistencies, omissions, and errors have been detected and
Elaboration
corrected
– the work products conform to the standards established for the
Negotiation process, the project, and the product
• The Formal Technical Review serves as the primary requirements
validation mechanism
Specification
– Members include software engineers, customers, users, and other
stakeholders
Validation

Requirements
Management
 Requirements Gathering
Requirements Management Task
(Requirement Management)
Inception • 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
Elicitation proceeds

• Each requirement is assigned a unique identifier

Elaboration
• The requirements are then placed into one or more traceability
Negotiation tables

Specification • These tables may be stored in a database that relate features,

sources, dependencies, subsystems, and interfaces to the
requirements
Validation
• A requirements traceability table is also placed at the end of the
Requirements software requirements specification
Management

Process Modeling
Process Modeling • Modeling a system’s process

and – Utilize information

determination
gathered during requirements

– Structure of the data is also modeled in addition to the

Data Flow Diagrams processes

• Graphically represent the processes that capture,

manipulate, store and distribute data between a system
and its environment and among system components

• Data flow diagrams (DFD)

– Graphically illustrate movement of data between external
entities and the processes and data stores within a system
 Data Flow Diagramming Mechanics:
Data Flow Diagramming Mechanics Data Store
• Drawn as two horizontal
• Drawn as an arrow parallel lines

• Depicts data at rest

• Depicts data that are
in motion and moving • May represent data in
as a unit from one – File folder
place to another in the – Computer-based file
system. – Notebook

• The name of the store as

• Select a meaningful well as the number are
name to represent the recorded in between lines
data

Data Flow Diagramming Mechanics: Data Flow Diagramming Mechanics:

Process Source/Sink
• Drawn as a square
• Drawn as a circle symbol
• Depicts the origin
• Depicts work or action and/or destination of
performed on data so the data
that they are • Sometimes referred
transformed, stored or to as an external
entity
distributed
• Because they are
external, many
• Number of process as characteristics are
well as name are not of interest to us
recorded
 Data Flow Diagramming Definitions: Data Flow Diagramming Definitions:
Coupled
Context Diagram Level-1 Diagram
A data flow diagram (DFD)
of the scope of an A data flow
organizational system that
shows the
diagrams (DFD)
that represents
• system boundaries  system’s major
processes
• external entities that
interact with the system  data flows
and
 data stores at Decoupled
• the major information a higher level
flows between the
entities and the system

Decomposition of DFDs Decomposition of DFDs

• Functional decomposition
– Act of going from one single system to many
component processes
– Repetitive procedure
– Lowest level is called a primitive DFD

• Level-N Diagrams
– A DFD that is the result of n nested
decompositions of a series of subprocesses
from a process on a level-0 diagram
 Balancing DFDs: An unbalanced
Balancing DFDs example
• Here we have the • In context
same inputs and diagram, we
output, that is no new have one input
inputs or outputs have to the system,
been introduced A and one
output, B
• We can say that the
context diagram and • Level 1
level-1 DFD are diagram has
balanced one additional
data flow, C

Data Flow Diagramming Rules Data Flow Diagramming Rules: Process

Basic rules that apply to all DFDs
A. No process can
• Inputs to a process are always have only
different than outputs outputs (a
miracle)

B. No process
can have
• Objects always have a only inputs
unique name (black hole)
– In order to keep the
C. A process
diagram uncluttered,
has a verb
you can repeat data phrase
stores and data flows on label
a diagram (except
for context
diagram)
 Data Flow Diagramming Rules: Data Data Flow Diagramming Rules:
Store Source/Sink
D. Data cannot be
moved from
one store to
another. H. Data cannot move
directly from a source to
E. Data cannot a sink
move from an
outside source
to a data store
F. Data cannot
move directly
from a data I. A source/sink has a
store to a data noun phrase label
sink

G. Data store has a

noun phrase
label

Data Flow Diagramming Rules: Data Data Flow Diagramming Rules: Data
Flow Flow (Continued)
J. A data flow L. A join means that exactly the
same data come from any two
has only one
or more different processes,
direction of data stores or sources/sinks to a
flow between common location
symbols.

M. A data flow cannot go directly

K. A fork means back to the same process it
that exactly the leaves
same data go
from a
common N. A data flow to a data store means update (delete or change)
location to two
or more
processes, O. A data flow from a data store means retrieve or use
data stores or
sources/sinks
P. Data flow has a noun phrase label
 DFD Errors: Representing process as Data Flow Diagramming Rules:
sink/source Advanced Rules
Q. A composite data flow on one level can be split into
component data flows at the next level, BUT no new
data can be added and all data in the composite must
be accounted for in one or more sub-flows.

Data Flow Diagramming Rules:

Advanced Rules
R. The inputs to a process must be sufficient to produce the outputs from
the process.

S. At the lowest level of DFDs, new data flows may be added to

Top- Down Functional
represent data that are transmitted under exceptional conditions (e.g.,
error messages). Decomposition
T. To avoid having data flow lines cross each other, you may repeat data
stores or sources / sinks on a DFD.
Module Structure Chart
 Module Structure Chart Control Flow

• Chart which shows the breakdown of a system to its lowest Data Flow
manageable levels.
• Program modules are arranged in a tree structure.
• Each module is represented by a box, which contains the module's
name.
• The tree structure visualizes the relationships between modules.

What is USE CASE diagram?

• A use case diagram establish the capability of the
system as a whole.

• Components of use case diagram:

Actor
Use case
System boundary
Relationship
Actor relationship

• Semantic of the components is followed.

9
 ACTOR: ACTOR:

What is an actor? More about an actor:

• An actor is some one or something that must interact • It is role a user plays with respect to system.
with the system under development • Actors are not part of the system they represent anyone
• UML notation for actor is stickman, shown below. or anything that must interact with the system.
• Actors carry out use cases and a single actor may
perform more than one use cases.
• Actors are determined by observing the direct uses of
the system,
Customer Manager Cashier

10 11

ACTOR: ACTOR:
How do we find the actor?
Contd…
• Ask following questions to find the actors:
– Who uses the system?
• Those are responsible for its use and maintain as well as
other systems that interact with the developed system. – Who installs the system?
– Who Starts up the system?
• An actor may – What other systems use this system?
- input information to the system. – Who gets the information from the system?
- receive information from the system. – Who provides information to the system?
- input to and out from the system.
• Actor is always external to the system. They are never
part of the
12 system to be developed. 13
 ACTOR: USE CASE:
What is USE case?
• A use case is a pattern of behavior, the system exhibits
4-Categories of an actor:
• Each use case is a sequence of related transactions
performed by an actor and the system in dialogue.
• Primary Actor : Who uses the main system functions. • USE CASE is dialogue between an actor and the
• Secondary Actor: Who takes care of administration & system.
maintenance. • Examples:
• External h/w : The h/w devices which are part of
application domain and must be used.
• Other system: The other system with which the system
must interact. Open new account Withdrawal of cash
from ATM

14 15

RELATIONSHIP between Use Cases

SYSTEM BOUNDARY:
• Relationship between two use cases is refereed as
What is System Boundary? either include or extends.
<<includes>> Arrow is towards secondary use case
• It is shown as a rectangle.
• It helps to identify what is external verses internal, and
what the • Multiple use cases share a piece of same functionality.
responsibilities of the system are.
• This functionality is placed in a separate use case rather
• The external environment is represented only by actors.
than

documenting in every use case that needs it.

• <<includes>> relationship shows behavior that is

16 common to one or more use cases 17
 RELATIONSHIP between Use Cases
Generalisation
<<extends>> Arrow is towards primary use case
• Actors and use cases can be generalised, showing that one
• It is used to show optional behavior, which is required is simply a special case of the other
only – This is like inheritance in object-oriented design
– Suppose that to borrow a CD, users must have additional
under certain condition. registration and pay per CD.
• e.g. Order and Rush Order: Rush Order is a
borrow book
special/optional case of order.
Borrower : books only
• Here Order is a normal order which is served within 30
borro
minutes and user can select Rush Order instead, which wer borrow CD
means meal will be served within 10 minutes and user
will have to pay Rs. 100 extra. Borrower : books and CDs
18

Typical Course of Events/ Successful Scenario/

USE CASE Diagram for Withdraw Cash Normal Scenario
( To be written in related Use Case Template )
For withdrawal of cash:
• 1.(SR) The ATM asks the user to insert a card.
• 2.(AA) The user inserts a cash card.
Balance status
report • 3.(SR) The ATM accepts the card and reads its serial
<<extends>> number.
• 4.(SR) The ATM requests the password.
Clerk Withdraw cash
Customer • 5.(AA) The user enters 1234.
<<includes>>
• 6.(SR) The ATM verifies the serial number and password
with the
Validation bank and gets the notification accordingly.
ATM DB • 7.(SA)The ATM asks the user to select the kind of
Manager transaction.
20
• 8.(AA)User selects the withdrawal. 21
 Normal Flow of Events:
• 9.(SR)The ATM asks for the amount of cash; user enters Rs.
Alternative Flow of Events:
2500/-
• 10.(SR)The ATM verifies that the amount of cash is within For withdrawal of cash use case:
predefined policy limits and asks the bank, to process the
transaction which eventually confirms success and returns the
new account balance. • 9. The ATM asks for the amount of cash; the user has
• 11.(SR) The ATM dispenses cash and asks the user to take it. change of mind and hits the “cancel”.
• 12.(AA) The user takes the cash.
• 13.(SR) The ATM asks whether the user wants to continue.
• 14.(AA) The user indicates no.
• 15.(SR) The ATM prints a receipt, ejects the card and asks the
user to take them
• 16.(AA) The user takes the receipt and the card.
• 17.(SR) The ATM asks a user to insert a card.
22 23

USE CASE Template

Exceptional Flow of Events: • Generic format for documenting the use case:

For withdrawal of cash use case: - Pre condition: If any

– Use case: Name of the case.

• 3 Suspicious pattern of usage on the card.
– Actors : List of actors(external agents),
• 10 The machine is out of cash.
indicating who initiates the use case.
• 11 Money gets stuck in the machine.
– Purpose : Intention of the use case.

– Overview : Description.

– Type : primary / secondary.

24 25
 Another Example – Library Management
USE CASE Template Contd. System
• Typical Course of Events/ Successful Scenario/
Normal Scenario Pls Note: Use
<<extends>>
ACTOR ACTION(AA) : Numbered actions of the
instead of
actor.
<<extend>> and
SYSTEM RESPONSE(SR): Numbered description of <<includes>>
system responses. instead of
SYSTEM ACTION(SA): Numbered description of <<include>>
system responses.
• Exceptional Flow of Events/ Extension points
• Alternate Flow
• Post Condition( if any)

Sample Use Case Template– Class diagram

Library Management System
• Used for describing structure and behavior in the use
cases
• Provide a conceptual model of the system in terms of
entities and their relationships
• Used for requirement capture, end-user interaction
• Detailed class diagrams are used for developers
 Class Diagram Class
• A Class Diagram shows the existence of classes and
their relationships in the logical view of a system
• UML modelling elements in class diagram are:
– Classes, their structure an behaviour
– Relationship components among classes such as
association, aggregation, composition, dependency
and inheritance
– Multiplicity and navigation indicators
• Association
• Aggregation
• Composition
• Dependency

Relationships Relationships
(1) Association
(2) Aggregation
• These are most general type of relationship: • This is a special type of association
• The association with label “contains “ or “is part of” is
– It denotes a semantic connection between two
an aggregation
classes
• It represents “has a” relationship
– It is a weak coupling as associated classes remain • It is used when one object logically or physically contains
somewhat independent of each other. other
– Example: • The container is called as aggregate
• It has a diamond symbol at its end
• It expresses a whole – part relationship
 Relationships Relationships
(3) Composition (4) Dependency
• This is a strong form of aggregation • Dependency is a semantic relationship between two
• It expresses the stronger coupling between the things in which a change to one thing (independent
classes thing) may affect the semantics of other thing (the
• The owner is explicitly responsible for creation and dependent thing)
deletion of the part
• Any deletion of whole is considered to cascade its part • Graphically, a dependency is represented as a directed
• The aggregate has a filled diamond symbol at its end dashed line,

Class Diagram - Example Good Practice: CRC Card

(Class Responsibility Collaborator)
• Benefits: It is easy to describe how classes
work by moving cards around; allows to
quickly consider alternatives.