Upload
phyllis-peters
View
228
Download
4
Tags:
Embed Size (px)
Citation preview
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