Chapter 9: Analyzing Systems Using Data Flow Diagrams

1
Chapter 9 Analyzing Systems Using Data Flow
Diagrams

• Instructor Paul K Chen

2
Topics

• Process Model What is it? Objectives
• Process Model When?
• Process Model Principles (How)
• Process Model Tools
• DFD Usage
• Components Naming
• Partitioning Principles-Leveling and Balancing
• Guidelines to Develop a DFD

3
What is it?

• A process model is a collection of business
  functions or
• tasks that are to be carried out by a system.
• 1. Constructs Data Flow Diagrams
• Functional Hierarchy
  Diagrams
• 2. Business solutions transformation analysis
  showing
• external inputs, through operations and
  internal data stores, to external outputs. (DFD
  does not show control information)

4
Objectives of Process Modeling

• To better understand the functional needs of the
• organization via an accurate model, which
  will then act as a framework for development of
  new or enhanced systems.
• To describe what your business does independent
  of any mechanism or processing methods, thus
  allowing objective decisions to be made relative
  to implementation release strategy.
• To facilitate program internal logic (algorithm)
  design.

5
When Should it be Done?

• Planning
• Identify process requirements via WBS.
• Analysis
• Interviewing the user to gather process
  requirements.
• Logical process modeling (defining the
  clerical and mechanical operations and processing
  in the users working environment)
• Deriving functional specifications from unit
  functions (function primitive)

6
When Should it be Done?

• Design
• Defining processing standards (audit rules,
  security rules, edit and error rules), common
  processes, data flow standards (screen
  navigation, person/machine dialog, protocols for
  data exchange)
• Structured English to describe the processing
  .
• Code Test
• Physical process model (program logic and
  coding)
• Implementation and Maintenance

7
Process Modeling Principles

• Based on the following structured principles
• Functional Decomposition (Function Hierarchy
• Diagram) analyzing a system by breaking
  into smaller
• pictures until a clear , complete, and
  finite picture is
• drawn.
• Transaction Analysis (Functional dependency
  diagram) describing under what rules determine
  the next function to be invoked.
• Transformation Analysis (DFD) defining how
  output values in a computation are derived from
  input value

8
Process Partitioning
(How)
(What, Why, Who, where)
System
Conceptual Level
Technical considerations
Subsystem
Data flow standards Processing standards Control
Standards Common processes
Data transformation

Operating responsibility
Logical Level
Function primitive
Program specification
Programming and algorithm
Sequential constructs decision constructs
repetition constructs
9
Process Modeling Tools

• At the analysis level
• Task Structure Charts used for task breakdown
  structure (TBS)
• Function Hierarchy Diagram
• Function Dependency Diagram
• Data Flow Diagram

10
Task Breakdown Structure
System
Task Component A
Task Component B
Task A
Task B
Task C
Task D
Task E
11
Function Hierarchy Diagram
Manage RFC
Manage Membership records
Manage Food item Ordered by members
Enter Orders
Fill Orders
Ship orders
Manage Information Regarding Venors
12
Function Dependency Diagram
Enter Orders
Fill Orders
Ship Orders
Trigger Point
Key results
13
DFD Usage

• Unexploded DFD are used to identify information
  requirements.
• Exploded DFD can be used for presentations and
  gathering feedback from users.
• DFD can be used for system documentation.
• DFD primarily be used to analyze the system to
  ensure that the design is complete.

14
Components (Notations)
Process representing the Transformation of data

Entity, External actor, data source Sink
submitting data to processes, or Receiving
results, or both
File and Data Store representing the storage of
data required by the processes
15
Naming

• External entities should be named with a noun.
• Processes could be
• A system name
• A subsystem
• Unit Function
• Data store should be named with a noun

16
Leveling Balancing

• Concept of leveling
• When a single process on a higher level diagram
  is partitioned to show the level of detail
• When several processes on a data flow diagram are
  grouped together as a single process on a higher
  level diagram

17
Leveling Balancing

• Concept of balancing
• The inputs and outputs of a child diagram must
  exactly match those of its parent diagram
• Every flow must have a place to come from and a
  place to go to.

18
DFDParent Child Relationship
A (H2)
Process
C (Water)
B (O)
A (H2)
C (Water)
B (O)
19
Guidelines to Develop a DFD

• Identifies all net input and output data flows on
  the context diagram.
• Work from the outside in, and put a process
  wherever data flows must be changed or combined.
• Portray data flow, not control flow or control
  information.
• Make sure each flow and each process is namable -
  weak names are signs of poor partitioning.
• Be sure you know the composition of each data
  flow. Establish connections between inputs and
  outputs.

20
Guidelines to Develop a DFD

• Label all interface data flows carefully.
• Limit the number of processes on each level to
  seven, plus or minus two.
• Minimize the number of data stores.
• Respect data conservation. No process can produce
  an output for which the required input(s) are not
  processed.

21
Technical Considerations in Process Modeling

• Data Flow Standards
• Menu hierarchies GUI
• Protocols or data exchanges between systems
• Protocols for data exchange between unit
  functions (function primitive).
• Processing Standards
• Processing description (text and graphic)
• Transformation rules Edit and error rules
  Audit rules Security rules.

22
Technical Considerations in Process Modeling

• Control Standards
• User Logs
• Logon procedure
• Privileges (user profile).
• Common processes
• GUI
• Applications
• Data communications API.

23
Transaction Analysis

• A Transaction is a collection of database
  operations grouped into a unit of work that is
  either completely executed or completely
  abandoned
•  
• TM (Transaction Monitors) are a class of
  transaction-processing applications that were
  originally designed to manage very large numbers
  of simultaneous transactions against mainframe
  database mgt systems.
•  
• MTS (Microsoft Transaction Server) brings the
  robustness and scalability to the client-server
  arena.

24
Transaction Analysis

• Transactions can be classified as either implicit
  or explicit. Implicit transactions are single SQL
  statements that execute as an atomic unit.
  Explicit transactions are groupings of SQL
  statements surrounded by transaction delimiters
  Begin Transaction, Commit Transaction, Rollback
  Transaction.

25
Transaction Analysis

• Use SQL Server ISQL to insert and commit a new
  department into the Department Table.
•  
• 1. Start the ISQL application
• 2. Select the target database from the
  DB-drop-list.
• 3. Type the following lines in the Query window
•  
• Begin Transaction
• Insert into department values (med, Medicine)
• Commit Transaction
•  
• 4. Click the Execute Query button in the ISQL
  window.
•  

26
Managing Transactions in MTS Components

• Every instance of a component under MTS control
  has an associated context object which holds
  information about the requested object and serves
  as the objects communication link to MTS. MTS
  manages transactions through this context object.
•  
• To obtain a reference to this object within a
  Visual Basic MTS component, call the
  GetObjectContext method
•   Dim ObjContext as ObjectContext
• Set ObjContext GetObjectContext ()

27
Managing Transactions in MTS Components

• To provide component-based transactions, MTS must
  manage state information about every single
  instance of all components under its control. It
  does so by intercepting the instantiation of a
  component and creating a sibling object at the
  creation time of the original object. This
  second object is known as a context object and
  its job is to maintain information about the
  context of the newly created object. Some of the
  information in a context object includes
•  
•       Transaction participation
•       Thread of execution information
• Security information, such as the
  components creator

28
Managing Transactions in MTS Components

• You must build all MTS components as in-process
  COM DLLs, also called ActiveX DLLs.
•  
• Logically group your components into packages for
  process isolation and performance.
•  
• Use existing data access APIs
• ADO (Active Data Objects)
• RDO (Remote Data Objects)
• DAO (Data Access Objects)
• to access data.

29
Final Words

• Transform data into information by understanding
  the process
• Transform information into decisions with
  knowledge
• Transform decisions into results with actions