Chapter 9: Analyzing Systems Using Data Flow Diagrams - PowerPoint PPT Presentation

Loading...

PPT – Chapter 9: Analyzing Systems Using Data Flow Diagrams PowerPoint presentation | free to download - id: 1d19b1-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Chapter 9: Analyzing Systems Using Data Flow Diagrams

Description:

Function Hierarchy Diagram. Manage RFC. Manage Membership. records. Manage Food item ... Identifies all net input and output data flows on the context diagram. ... – PowerPoint PPT presentation

Number of Views:254
Avg rating:3.0/5.0
Slides: 30
Provided by: paul53
Learn more at: http://www.circusoflife.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com