Transcript SE561 Formal Methods - Monmouth University

SE-565
Software System Requirements
IX. Data Flow Diagrams
Dr. Jiacun Wang
Department of Software Engineering
Monmouth University
7/16/2015
Jiacun Wang
1
Topics
 Requirements engineering methods
 Structured techniques for documenting and analyzing
requirements
 Data-Flow Diagrams
 Data Dictionaries
7/16/2015
Jiacun Wang
RE-9 2
Role of methods in RE
 Process of requirements engineering (RE) is usually guided by
a requirements method
 Requirement methods are systematic ways of producing
system models
 System models are important bridges between the analysis and
the design process
7/16/2015
Jiacun Wang
RE-9 3
Necessary properties for a RE
method
 Suitability for agreement with the end-user (using intuitive
notation)
 The precision of definition of its notation
 Assistance with formulating requirements
 Definition of the world outside
 Scope for malleability
 Scope for integrating other approaches
 Scope for communication
 Tool support
7/16/2015
Jiacun Wang
RE-9 4
No ideal RE method
 There is no ideal requirement method
 A number of methods use a variety of modelling techniques to
formulate system requirements
 System models can be enriched by modelling different aspects
of using modelling techniques
7/16/2015
Jiacun Wang
RE-9 5
SA and OOA
 Structured analysis (SA)
 focus on functionality
 focus on data

Object-oriented analysis (OOA)
 integrate data and functions
7/16/2015
Jiacun Wang
RE-9 6
Data-Flow Modeling
 One of the most popular structured methods
 The Data-Flow Diagram (DFD) method (DeMarco, 1979) provides
a description of a system based on modeling
 the transformational processes of a system,
 the collections (stores) of data that the system manipulates,
and
 the flows of data between the processes, stores and the
outside world.
 The DFD describes the functional viewpoint of the system e.g. it
describes the system in terms of its operation (tasks).
7/16/2015
Jiacun Wang
RE-9 7
Data-Flow Modeling (cont.)
 This method works well for transaction-processing systems and
other function-intensive applications.
 The DFD provides a way to represent the steps involved in a
business process or the operations of a proposed software
system.
 A DFD illustrates how the functional requirements in the SRS
combine to let the user perform specific tasks.
7/16/2015
Jiacun Wang
RE-9 8
The four basic elements of the
DFD notation
 The circle (the bubble)
 It denotes an operation and is labeled with a brief description of
the operation
 Transformation of data into other data
 Notation
3.
Reserve
seat
7/16/2015
Jiacun Wang
RE-9 9
 The box or rectangle (terminator)
 It denotes external entities - source or sink of information
outside the boundaries of the system
 The source/sink can be a human user or other system
 Notation
Customer
Source of
information
7/16/2015
Jiacun Wang
RE-9 10
 The paralleled bars or parallel lines
 It denotes a data store or file
 A place where data are held for later transformation or
reference.
 Notation
User database
Update
user
details
7/16/2015
Jiacun Wang
RE-9 11
 The arc (arrow)
 It denotes the flow of information between the other three
elements - data flow
 Notation
Customer’s card
details
PIN
Customer
Validate
customer
access
Access map
Network database
7/16/2015
Jiacun Wang
RE-9 12
The Data-Flow Diagram Notation
Summary
Data Transformation
Terminator
Input
Output
Terminator
Data dictionary
7/16/2015
Jiacun Wang
RE-9 13
Hierarchical/functional
decomposition
 The DFD can present the system at different levels of details.
(Hierarchical/functional decomposition)
details
•
•
•
•
•
Context level
Level 1
Level 2
……….
Level n
7/16/2015
The decomposition continues until
the lowest level diagram contains
only primitive process operations
that can be clearly represented in
narrative text, pseudocode,
activity diagram, etc.
Jiacun Wang
RE-9 14
Guidelines for building DFDs
1. All names should be unique.
2. Suppress logical decisions (no diamond shaped boxes!).
3. Don’t become bogged down in details. Defer error conditions
and error handling until the end of the analysis (not in the case
of a diagnostic system or patient monitoring system, for ex.).
4. Preserve the number of inputs and outputs between the levels.
5. As bubbles are decomposed into less abstract bubbles, the
corresponding data flows may also need to be decomposed.
7/16/2015
Jiacun Wang
RE-9 15
Rules of decomposition
A top level process
I1
I2
I
O3
O
A
A
O
I1
O3
O1
O2
I1
I
I2
is decomposed into
some number
of lower level processes
I2
7/16/2015
Jiacun Wang
RE-9 16
Guidelines for building DFDs
(cont.):
6. Place data stores only on the Level 1 and lower levels, not on
the context diagram.
7. Name each process as a concise action: verb + object
8. Number the processes uniquely and hierarchically. On level 1
diagram number each process with an integer. If you create a
child DFD for process 2, number the processes in that child
diagram 2.1, 2.2, etc.
9. Don’t show more than 10 processes on a single diagram
because it becomes harder to understand and change. Instead,
introduce another layer of abstraction by grouping related
processes into a higher-level process.
7/16/2015
Jiacun Wang
RE-9 17
Example: Simple library system
The context - level DFD for
Issue library item
Library card
Library
user
Requested item
Issued item
7/16/2015
Issue
library item
Jiacun Wang
Return date
Library
assistant
RE-9 18
Example: Simple library system
Level 1 of the DFD for the
Issue library item
User database
User
details
Library
card
Update
user
details
Check
user
User
status
Library
user
Requested
item
User
ID
Item
details
Item
status
Item database
7/16/2015
Item ID
Check
item
Issued
item
Updated
details
Jiacun Wang
Issue
Return
date
item
Library
assistant
Update
details
RE-9 19
Example: A Distribution System
Context level data flow diagram
Reply to be mailed
Greenbelt
Depts
Dept-Queries
Reports to
Depts
Mgmt-Queries
Greenbelt
Distribution
System
Customer
Correspondence
Customer
Response to
Customer
7/16/2015
Greenbelt
Mgmt
Mgmt-Reports
Correspondence
with Supplier
Supplier
Response
Supplier
Discarded
correspondence
Jiacun Wang
RE-9 20
Level 1 data flow diagram
Discarded
Correspondence
Customer
Correspondence
Reply to be mailed
Receiving
Correspondence
Supplier
Response
Preparing
Shipments
Response
to Customer
Order items
4
Invoice
1
Recorded
Customer
Order
Inventory File
Mgmt-Queries
supplies
Dept-Queries
Order Copy
Keeping
Accounts
Stocking
Supplies
3
2
Reports to Depts
Mgmt-Reports
Credit File
Correspondence
with Supplier
7/16/2015
Jiacun Wang
RE-9 21
Level 2 DFD: Receiving correspondence
Customer
Correspondence
Routed Correspondence
Record &
Route
Correspondence
Read &
Evaluate
Correspondence
1.2
Supplier
Response
1.1
Read &
Sign Draft
Discarded
Correspondence
Recorded
Customer Order
Correspondence
Demanding Reply
Correspondence
File
Draft of Reply
Draft Reply
1.4
1.3
Reply To Be Mailed
7/16/2015
Jiacun Wang
RE-9 22
Class exercise
Draw the context diagram, level 1 and one level 2 diagrams for
modeling the processing of an ATM.
7/16/2015
Jiacun Wang
RE-9 23
Data Dictionaries
 Repositories to store information about all data items or
attributes used in the application.
 Typical information include:
 Name of data item
 Aliases (other names for the item)
 Description/Purpose (meaning)
 Related data items (formulas)
 Range of values
 Data flows (generated_by/used_by)
 Data structure definition/form
7/16/2015
Jiacun Wang
RE-9 24
Data Dictionaries Notation
Meta Symbol
Meaning
+
And (concatenation)
()
Optional
{}
Iteration
[…..|…..|…..]
Selection of one alternative
“”
A literal string
7/16/2015
Jiacun Wang
RE-9 25
Simple Book Order DFD
Customer
database
Customer
Invoice
Create
Invoice
7/16/2015
Order
Credit Status
Verify
Order is
Valid
Jiacun Wang
RE-9 26
Data Dictionary for the Book Order DFD
Name
Credit Status
Data Flows
Generated By Used By
Customer
Verify Order
Data Base
Is Valid
Invoice
Create
Invoice
Customer
Customername
Description/Purpose
Form
An “okay” or “not okay ”
that defines the credit
worthiness of each customer
A bill indicating how
much the customer owes
[OK| NOTOK]
Unique customer identifier
Customer name +
+billing address+price
First-name
First-name +
(middle-name) +
last-name
Customer name +
{ item } +
customer address
[ shipping-address |
billing-address |
shipping-address+
billing-address ]
{legal character }
Legal character
[A-Z | a-z | 0-9 | ‘ | - | |]
Order
Customer
Verify order
is valid
A contract between customer
& book company
Customeraddress
7/16/2015
Jiacun Wang
RE-9 27
Data Dictionaries (cont.)
 Integration problems are reduced if all developers respect the
data dictionary definitions.
 The data dictionary complements the project glossary
 Begin collecting data definitions as you encounter them during
the elicitation
 If you keep the data dictionary current, it will remain a valuable
tool throughout the system’s maintenance life
7/16/2015
Jiacun Wang
RE-9 28
Class exercise: Create a 5 item data dictionary
for this DFD
User database
User details
Library
card
Check
Update
user
details
user
User status
Library
user
Requested
item
Update details
User ID
Item ID
Check
item
Item
status
Issued
item
Issue
Return
date
item
Item details
Library
assistant
Update details
Item database
7/16/2015
Jiacun Wang
RE-9 29