Chapter 9: Analyzing Systems Using Data Flow Diagrams

Instructor: Paul K Chen

TopicsTopics

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

What is it?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)

Objectives of Process ModelingObjectives 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.

When Should it be Done?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)

When Should it be Done?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

Process Modeling PrinciplesProcess 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

Process PartitioningProcess Partitioning

System

Subsystem

Data transformation

Operating responsibility

Program specificationProgramming and algorithm

Sequential constructs; decision constructs; repetition constructs

Conceptual Level

Logical Level

Technical considerations

(What, Why, Who, where)(How)

Data flow standardsProcessing standardsControl StandardsCommon processes

Function primitive

Process Modeling ToolsProcess Modeling Tools

At the analysis level

Task Structure Charts used for task breakdown structure (TBS)

Function Hierarchy Diagram

Function Dependency Diagram

Data Flow Diagram

Task Breakdown StructureTask Breakdown Structure

System

Task Component

A

Task Component

B

Task A Task B Task C Task D Task E

Function Hierarchy DiagramFunction Hierarchy Diagram

Manage RFC

Manage Membershiprecords

Manage Food itemOrdered by members

Enter Orders

Fill Orders

Manage InformationRegarding Venors

Ship orders

Function Dependency DiagramFunction Dependency Diagram

Enter Orders Fill Orders Ship Orders

Trigger Point

Key results

DFD UsageDFD 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.

Components (Notations)Components (Notations)

Process representing theTransformation of data

File and Data Store representing the storage of data required by the processes

Entity, External actor, data source &Sink submitting data to processes, or Receiving results, or both

NamingNaming

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

Leveling & BalancingLeveling & 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

Leveling & BalancingLeveling & 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.

DFD—Parent & Child DFD—Parent & Child RelationshipRelationship

Process

A (H2)

B (O)

C (Water)

A (H2)

B (O)

C (Water)

Guidelines to Develop a Guidelines to Develop a DFDDFD

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.

Guidelines to Develop a Guidelines to Develop a DFDDFD

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.

Technical Considerations in Technical Considerations in Process ModelingProcess 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.

Technical Considerations in Technical Considerations in Process ModelingProcess Modeling

Control Standards User Logs; Logon procedure; Privileges (user profile).

Common processes GUI; Applications; Data communications API.

Transaction AnalysisTransaction 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.

Transaction AnalysisTransaction 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.

Transaction AnalysisTransaction Analysis

Use SQL Server ISQL to insert and commit a new department into the Department Table.

 1. Start the ISQL application2. 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.

 

Managing Transactions in MTS Managing Transactions in MTS ComponentsComponents

Every instance of a component under MTS control has an associated context object which holds information about the requested object and serves as the object’s 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 ()

Managing Transactions in MTS Managing Transactions in MTS ComponentsComponents

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 component’s creator

Managing Transactions in MTS Managing Transactions in MTS ComponentsComponents

You must build all MTS components as in-process COM DLL’s, 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.

Final WordsFinal Words

Transform data into information by understanding the process

Transform information into decisions with knowledge

Transform decisions into results with actions