Transcript Data and Process Modeling

Data and Process Modeling
Overview
 What
the system does what an event occurs:
activities and interactions
 Traditional
structured approach to representing
activities and interactions
 Diagrams
and other models of the traditional
approach
 Customer
support system example shows how
each model is related
Data Flow Diagrams
 Graphical
system model that shows all main
requirements for an IS in one diagram

Inputs / outputs

Processes

Data storage
 Easy
to read and understand with minimal
training
Data Flow Diagram Symbols
DFD Fragment
DFD Integrates Event Table and ERD
DFD and Levels of Abstraction
 Data
flow diagrams (DFDs) are decomposed into
additional diagrams to provide multiple levels of
detail
 Higher
level diagrams provide general views of
the system
 Lower
level diagrams provide detailed views of
the system
 Differing
views are called levels of abstraction
Layers of DFD Abstraction
Context Diagrams
 DFD
that summarizes all processing activity
 Highest
 Shows
level (most abstract) view of system
system boundaries
 System
scope is represented by a single process,
external agents, and all data flows into and out of
the system
Identifying Events
 Can
be difficult to determine
 Often
 May
confused with conditions and responses
be useful to trace a transaction’s life cycle
 Certain

events left to design phase
Systems controls to protect system integrity
Sequence of Actions that Lead up to Only
One Event Affecting the System
Sequence of “Transactions”
for One Specific Customer
Resulting in Many Events
Events Deferred Until the Design Phase
Example Events
 Important

Customer checks item availability, customer places
order, customer changes or cancels order
 Other

external events involve departments
Shipping fulfills order, marketing sends promotion
to customer, merchandising updates catalog
 Temporal

external events involve customers
events include periodic reports
Time to produce order summary reports, Time to
produce fulfillment summary reports
Information about each Event
in an Event Table
DFD Fragments
 Created
for each event in the event table
 Represents
system response to one event within
a single process symbol
 Self
contained model
 Focuses
 Shows
events
attention on single part of system
only data stores required to respond to
DFD Fragments for Course
Registration System
Event-Partitioned System Model
 DFD
to model system requirements using single
process for each event in system or subsystem
 Decomposition
 Sometimes
 Used
of the context level diagram
called diagram 0
primarily as a presentation tool
 Decomposed
into more detailed DFD fragments
Combining DFD Fragments
Context Diagram for a
Customer Support System
Subsystems and Events
Context Diagram for an
Order-Entry Subsystem
DFD Fragments for an
Order-Entry System
Decomposing DFD Fragments
 Sometimes
DFD fragments need to be explored
in more detail
 Broken
 DFD
into subprocesses with additional detail
numbering scheme:

Does not equate to subprocess execution
sequence

It is just a way for analyst to divide up work
Physical and Logical DFDs
 Logical
model

Assumes implementation in perfect technology

Does not tell how system is implemented
 Physical
model

Describes assumptions about implementation
technology

Developed in last stages of analysis or in early
design
Detailed Diagram for Create New Order
Physical DFD for scheduling courses
Evaluating DFD Quality
 Readable
 Internally
consistent
 Accurately
 Reduces
represents system requirements
information overload: Rule of 7 +/- 2

Single DFD should have not more than 7 +/-2
processes

No more than 7 +/- 2 data flows should enter or
leave a process or data store on a single DFD
 Minimizes
required number of interfaces
Data Flow Consistency Problems
 Differences
in data flow content between a
process and its process decomposition
 Data
outflows without corresponding inflows
 Data
inflows without corresponding outflows
 Results
in unbalanced DFDs
Consistency Rules
 All
data that flows into a process must:

Flow out of the process or

Be used to generate data that flow out of the
process
 All
data that flows out of a process must:

Have flowed into the process or

Have been generated from data that flowed into
the process
Unnecessary Data Input: Black Hole
Process with Unnecessary Data Input
Process with Impossible Data Output
Documentation of DFD Components
 Lowest
level processes need to be described in
detail
 Data
flow contents need to be described
 Data
stores need to be described in terms of data
elements
 Each
data element needs to be described
 Various
options for process definition exist
Data Dictionary
 A data
dictionary, or data repository, is a central
storehouse of information about the system’s
data
 An
analyst uses the data dictionary to collect,
document, and organize specific facts about
the system
 Also
defines and describes all data elements
and meaningful combinations of data elements
Data Dictionary
 A data
element, also called a data item or field, is
the smallest piece of data that has meaning
 Data
elements are combined into records, also
called data structures
 A record
is a meaningful combination of related
data elements that is included in a data flow or
retained in a data store
Data Dictionary
 Documenting
the Data
Elements

You must document
every data element in
the data dictionary

The objective is the
same: to provide clear,
comprehensive
information about the
data and processes that
make up the system
Data Dictionary
 Documenting

the Data Elements
The following attributes usually are recorded and
described
 Data
element name or label
 Alias
 Type
and length
 Default
value
 Acceptable
values - Domain and validity rules
Data Dictionary
 Documenting

the Data Elements
The following attributes usually are recorded and
described
 Source
 Security
 Responsible
 Description
user(s)
and comments
Data Dictionary
 Documenting

the Data Flows
The typical attributes are as follows
 Data
flow name or label
 Description
 Alternate
name(s)
 Origin
 Destination
 Record
 Volume
and frequency
Data Dictionary
 Documenting
the Data
Stores

Typical characteristics
of a data store are
 Data
store name or
label
 Description
 Alternate
name(s)
 Attributes
 Volume
and
frequency
Data Dictionary
 Documenting
the
Processes

Typical characteristics
of a process
 Process
name or label
 Description
 Process
number
 Process
description
Data Dictionary
 Documenting

the Entities
Typical characteristics of
an entity include
 Entity
name
 Description
 Alternate
 Input
name(s)
data flows
 Output
data flows
Data Dictionary
 Documenting
the
Records

Typical characteristics
of a record include
 Record
or data
structure name
 Definition
or
description
 Alternate
 Attributes
name(s)
Data Dictionary
 Data

Dictionary Reports
Many valuable reports
 An
alphabetized list of all data elements by name
A
report describing each data element and
indicating the user or department that is
responsible for data entry, updating, or deletion
A
report of all data flows and data stores that use
a particular data element
 Detailed
reports showing all characteristics of data
elements, records, data flows, processes, or any
other selected item stored in the data dictionary
Structured English
 Method
of writing process specifications
 Combines
structured programming techniques
with narrative English
 Well
suited to lengthy sequential processes or
simple control logic (single loop or if-then-else)
 Ill-suited
for complex decision logic or few (or no)
sequential processing steps
Structured English Example
Process 2.1 and Structured
English Process Description
Decision Tables and Decision Trees
 Can
summarize complex decision logic better
than structured English
 Incorporates
logic into the table or tree
structure to make descriptions more readable
Decision Tree for Calculating
Shipping Charges
Data Flow Definitions
 Textual
description of data flow’s content and
internal structure
 Often
coincide with attributes of data entities
included in ERD
Components of a Traditional Analysis Model
Logical Versus Physical Models
 While
structured analysis tools are used to
develop a logical model for a new information
system, such tools also can be used to develop
physical models of an information system
 A physical
model shows how the system’s
requirements are implemented
Logical Versus Physical Models
 Sequence
of Models

Many systems analysts create a physical model of
the current system and then develop a logical
model of the current system before tackling a
logical model of the new system

Performing that extra step allows them to
understand the current system better
Logical Versus Physical Models
 Four-Model
Approach

Develop a physical model of the current system, a
logical model of the current system, a logical
model of the new system, and a physical model of
the new system

The only disadvantage of the four-model approach
is the added time and cost
Summary
 Data
flow diagrams (DFDs) used in combination
with event table and entity-relationship diagram
(ERD) to model system requirements
 DFDs
model system as set of processes, data
flows, external agents, and data stores
 DFDs
easy to read - graphically represent key
features of system using small set of symbols
 Many
types of DFDs: context diagrams, DFD
fragments, subsystem DFDs, event-partitioned
DFDs, and process decomposition DFDs
Summary (continued)
 Each
process, data flow, and data store requires
detailed definition
 Analyst
may define processes as structured
English process specification, decision table,
decision tree, or process decomposition DFD
 Process
decomposition DFDs used when internal
process complexity is great
 Data
flows defined by component data elements
and their internal structure