Chap 008

OBJECT-ORIENTED SYSTEM ANALYSIS AND DESIGN
C H A P T E R
8 PROCESS
MODELING
河北农业大学面向对象系统分析与设计课程组版权所有
Chapter Eight Process Modeling

• Define systems modeling and differentiate between logical and physical system
models.
• Define process modeling and explain its benefits.
• Recognize and understand the basic concepts and constructs of a process model.
• Read and interpret a data flow diagram.
• Explain when to construct process models and where to store them.
• Construct a context diagram to illustrate a system’s interfaces with its work
environment.
• Identify use cases, external and temporal business events for a system.
• Perform event partitioning and organize events in a functional decomposition
diagram.
• Draw event diagrams and merge those events into a system diagram.
• Draw primitive data flow diagrams and describe the elementary data flows and
processes in terms of data structures and procedural logic (Structured English and
decision tables), respectively.
• Document the distribution of processes to locations.
• Synchronize data and process models using a CRUD matrix.
Chapter Map
Models: Logical and Physical
A model is a representation of reality. Just as a

picture is worth a thousand words, most models are
pictorial representations of reality.
Logical models show Physical models show not

what a system is or does. only what a system is or
They are implementation does, but also how the
independent; that is, they system is (to be) physically
depict the system and technically implemented.
independent of any They are implementation
technical implementation. dependent because they
reflect technology choices.
Why Logical System Models
• Logical models remove biases that are the result of the

way the system is currently implemented, or the way
that any one person thinks the system might be
implemented.
• Logical models reduce the risk of missing business

requirements because we are too preoccupied with
technical results.
• Logical models allow us to communicate with end-

users in nontechnical or less technical languages.
Process Modeling and DFDs
Process modeling is a technique for organizing and

documenting the structure and flow of data through a
system’s processes, and/or the logic, policies, and
procedures to be implemented by a system’s processes.
A data flow diagram (DFD) is a tool (and type of process

model) that depicts the flow of data through a system and
the work or processing performed by that system.
DFDs have become a popular tool for business process

redesign.
Simple Data Flow Diagram
Differences Between DFDs and Flowcharts
• Processes on DFDs can operate in parallel (at-the-

same-time)
– Processes on flowcharts execute one at a time
• DFDs show the flow of data through a system

– Flowcharts show the flow of control (sequence and
transfer of control)
• Processes on one DFD can have dramatically different

timing
– Processes on flowcharts are part of a single program
with consistent timing
Systems Thinking
Systems thinking is the application of formal systems

theory and concepts to systems problem solving.
DFDs are a tool that supports systems thinking.
Process Concepts
A process is work A System is a Process

performed on, or
in response to,
incoming data
flows or i n p u t T h e o u t p u t
conditions. i n p u t
i n p u t
S y s
i s a
t e m o u t p u t
o u t p u t
P r o c e s s
F e e d a c k a n d
A C o n t r o l L o o p
P r o c e s s
T h e S y s t e m 's E n v i r o n m e n t
( c o n s t a n t l y c h a n g i n g )
Decomposition
System Decomposition
Decomposition is the
act of breaking a
system into its
component
subsystems,
processes, and
subprocesses. Each
level of abstraction
reveals more or less
detail.
Decomposition Diagrams
A decomposition
diagram or
hierarchy chart
shows the top-
down, functional
decomposition of
a system.
Types of Logical Processes
• A function is set of related and ongoing activities of a

business.
•
An event (or transaction) is a logical unit of work that
must be completed as a whole (as part of a function).
• An elementary process (or primitive process) is a

discrete, detailed activity or task required to respond to
an event. Usually, several such tasks must be
completed to respond to an event.
Common Process Errors on DFDs
Problems with Natural English

PROBLEMS WITH NATURAL ENGLISH 1
• Many of us do not write well, and we also tend not to question our writing abilities.
• Many of us are too educated! It’s often difficult for a highly educated person to communicate with an
audience that may not have had the same educational opportunities. For example, the average college
graduate (including most analysts) has a working vocabulary of 10,000 to 20,000 words; on the other hand,
the average non-college graduate has a working vocabulary of around 5,000 words.
• Some of us write everything like it was a program. If business procedures required such precision, we’d
write everything in a programming language.
• Too often, we allow the jargon and acronyms of computing to dominate our language.
• English statements frequently have an excessive or confusing scope. How would you carry out this
procedure: “If customers walk in the door and they do not want to withdraw money from their account or
deposit money to their account or make a loan payment, send them to the trust department.” Does this
mean that the only time you should not send the customer to the trust department is when he or she wishes
to do all three of the transactions? Or does it mean that if a customer does not wish to perform at least one
of the three transactions, that customer should not be sent to the trust department?
• We overuse compound sentences Consider the following procedure: “Remove the screws that hold the outlet
cover to the wall. Remove the outlet cover. Disconnect each wire from the plug, but first make sure the
power to the outlet has been turned off.” An unwary person might try to disconnect the wires prior to
turning off the power!
• Too many words have multiple definitions.
• Too many statements use imprecise adjectives. For example, an loan officer asks a teacher to certify that a
student is in good academic standing. What is good?
• Conditional instructions can be imprecise. For example, if we state that “all applicants under the age of 19
must secure parental permission,” do we mean less than 19, or less than or equal to 19?
• Compound conditions tend to show up in natural English. For example, if credit approval is a function of
several conditions: credit rating, credit ceiling, annual dollar sales for the customer in question, then
different combinations of these factors can result in different decisions. As the number of conditions and
possible combinations increases, the procedure becomes more and more tedious and difficult to write.
Source: Adapted from Matthies, Leslie, The New Playscript Procedure,
(Stamford, CT: Office Publications, Inc. 1977)
Structured English
Structured English is a language and syntax, based on the

relative strengths of structured programming and natural
English, for specifying the underlying logic of
elementary processes on DFDs.
1. For each CUSTOMER NUMBER in the data store CUSTOMERS:
a. For each LOAN in the data store LOANS that matches the above
CUSTOMER NUMBER:
1) Keep a running total of NUMBER OF LOANS for the
CUSTOMER NUMBER.
2) Keep a running total of thw ORIGINAL LOAN PRINCIPALfor the
CUSTOMER NUMBER.
3) Keep a running total of CURRENT LOAN BALANCE for the
CUSTOMER NUMBER.
4) Keep a running total of AMOUNTS PAST DUE for the
CUSTOMER NUMBER.
b. If the TOTAL AMOUNTS PAST DUE for the CUSTOMER NUMBER
is greater than $100.00 then:
1) Write the CUSTOMER NUMBER and all their data attributes
as described in the data flow LOANS AT RISK.
Else
1) Exclude the CUSTOMER NUMBER and data from the data
flow LOANS AT RISK.
Structured English Constructs (Part 1)
complex logic in which rows represent conditions
Policies and Decision Tables
A policy is a set of rules that governs some process of

the business.
A decision table is a tabular form of presentation that

specifies a set of conditions and their corresponding
actions (as required to implement a policy).
A Simple Decision Table
Data Flows & Control Flows
• A data flow represents an input of data to a process, or

the output of data from a process.
– A data flow may also be used to represent the
creation, reading, deletion, or updating of data in a file
or database (called a data store).
– A composite data flow is a data flow that consists of

other data flows.
• A control flow represents a condition or nondata event
that triggers a process.
– Used sparingly on DFDs.
Data Flow Packet Concept
Composite and Elementary Data Flows
Data Flows to and from Data Stores
Illegal Data Flows
Data Structures
Data flows can be defined by data structures.
A data structure is a specific arrangement of data

attributes that defines the organization of data contained
in a data flow.
A data attribute is the smallest piece of data that has

meaning to the end-users of a business.
A Data Structure for a Data Flow

DATA STRUCTURE ENGLISH ENTERPRETATION
ORDER= An instance of ORDER consists of:

ORDER NUMBER + ORDER NUMBER and
ORDER DATE+ ORDER DATE and
[ PERSONAL CUSTOMER NUMBER, Either PERSONAL CUSTOMER NUMBER
CORPORATE ACCOUNT NUMBER]+ or CORPORATE ACCOUNT NUMBER
SHIPPING ADDRESS=ADDRESS+ and SHIPPING ADDRESS (which is equivalent
(BILLING ADDRESS=ADDRESS)+ to ADDRESS)
1 {PRODUCT NUMBER+ and optionally: BILLING ADDRESS (which is
equivalent to ADDRESS)
PRODUCT DESCRIPTION+
and one or more instances of:
QUANTITY ORDERED+
PRODUCT NUMBER and
PRODUCT PRICE+ PRODUCT DESCRIPTION and
PRODUCT PRICE SOURCE+ QUANTITY ORDERED and
EXTENDED PRICE } N+ PRODUCT PRICE and
SUM OF EXTENDED PRICES+ PRODUCT PRICE SOURCE and
PREPAID AMOUNT+ EXTENDED PRICE
(CREDIT CARD NUMBER+EXPIRATION and SUM OF EXTENDED PRICES and
DATE) PREPAID AMOUNT and
(QUOTE NUMBER) optionally: both CREDIT CARD NUMBER and
EXPIRATION DATE
ADDRESS=
(POST OFFICE BOX NUMBER)+ An instance of ADDRESS consists of:
STREET ADDRESS+ optionally: POST OFFICE BOX NUMBER and
CITY+ STREET ADDRESS and
[STATE, MUNICIPALITY]+ CITY and
(COUNTRY)+ Either STATE or MUNICIPALITY
POSTAL CODE and optionally: COUNTRY
and POSTAL CODE
Data Structure Constructs
Data Structure Format by Example English Interpretation

(relevant portion is boldfaced) (relevant portion is boldfaced)
Sequence of Attributes - The WAGE AND TAX STATEMENT= An instance of WAGE AND TAX STATEMENTS
sequence data structure indicates one TAXPAYER IDENTIFICATION NUMBER+ consists of:
or more attributes that may (or must) TAXPAYER NAME+ TAXPAYER IDENTIFICATION NUMBER and
be included in a data flow. TAXPAYER ADDRESS+ TAXPAYER NAME and
WAGES, TIPS, AND COMPENSATION+ TAXPAYER ADDRESS and
FEDERAL TAX WITHHELD+… WAGES, TIPS AND COMPENSATION and
FEDERAL TAX WITHHELD and…
Selection of Attributes - The ORDER= An instance or ORDER consists of:

selection data structure allows you to (PERSONAL CUSTOMER NUMBER, Either PERSONAL CUSTOMER NUMBER or
show situations where different sets CORPORATE ACCOUNT NUMBER)+ CORPORATE ACCOUNT NUMBER; and
of attributes describe different ORDER DATE+… ORDER DATE and…
instances of the data flow.
Repetition of Attributes - The CLAIM= An instance of CLAIM consists of:

repetition data structure is used to set POLICY NUMBER+ POLICY NUMBER and
off a data attribute or group of data POLICYHOLDER NAME+ POLICYHOLDER NAME and
attributes that may (or must) repeat POLICY HOLDER ADDRESS+ POLICYHOLDER ADDRESS and
themselves a specific number of time 0 {DEPENDENT NAME+ zero or more instance of:
for a single instance of the data flow. DEPENDENT’S RELATIONSHIP} N+ DEPENDENT NAME and
The minimum number of repetitions 1 {EXPENSE DESCRIPTION+ DEPENDENT’S RELATIONSHIP and
is usually zero or one. SERVICE PROVIDER+ one or more instances of:
The maximum number of EXPENSE AMOUNT} N EXPENSE DESCRIPTION and
repetitions may be specified as “n” SERVICE PROVIDER and
meaning “many” where the actual EXPENSE ACCOUNT
number of instances varies for each
instance of the data flow.
Data Structure Constructs (concluded)
Data Structure Format by Example English Interpretation

(relevant portion is boldfaced) (relevant portion is boldfaced)
Optional Attributes - The optional CLAIM= An instance of CLAIM consists of:
notation indicates that an attribute, or POLICY NUMBER+ POLICY NUMBER and
group of attributes in a sequence or POLICYHOLDER NAME+ POLICYHOLDER NAME and
selection date structure may not be POLICYHOLDER ADDRESS+ POLICYHOLDER ADDRESS and
included in all instances of a data ( SPOUSE NAME+ optionally, SPOUSE NAME and
flow. DATE OF BIRTH)+… DATE OF BIRTH and...
Note: For the repetition data
structure, a minimum of “zero” is the
same as making the entire repeating
group “optional.”
Reusable Attributes - For groups of DATE= Then, the reusable structures can be included in other
attributes that are contained in many MONTH+ data flow structures as follows:
data flows, it is desirable to create a DAY+ ORDER=ORDER NUMBER…+DATE
separate data structure that can be YEAR+ INVOICE=INVOICE NUMBER…+DATE
reused in other data structures. PAYMENT=CUSTOMER NUMBER…+DATE
Data Types and Domains
Data attributes should be defined by data types and

domains.
A data type defines what class of data can be stored in an

attribute (e.g., character, integers, real numbers, dates,
pictures, etc.).
A domain defines what values or range of values an

attribute can legitimately take on.
Diverging and Converging Data Flows
• A diverging data flow is one that splits into multiple

data flows.
– Useful for illustrating data that starts out naturally as
one flow, but needs to be routed to parallel processes.
– Also useful for illustrating multiple copies of the same
output going to different destinations.
•
A converging data flow is the merger of multiple data
flows into a single packet.
– Useful for illustrating data from multiple sources that
must come back together for some subsequent
processing
Diverging and Converging Data Flows
External Agents
• An external agent defines a person, organization unit, or

other organization that lies outside of the scope of the
project but that interacts with the system being studied.
– External agents define the “boundary” or scope of a system
being modeled.
– As scope changes, external agents can become processes,
and vice versa.
– Almost always one of the following:
• Office, department, division inside the business but outside the
system scope.
• An external organization or agency.
• Another business or another information system.
External
• One of your system’s end-users or managers
Agent
Data Stores
• A data store is an inventory of data.

– Frequently implemented as a file or database.
– A data store is “data at rest” compared to a data flow that
is “data in motion.”
– Almost always one of the following:
• Persons
(or groups of persons)
• Places Data
• Objects Store
• Events
(about which data is captured)
• Concepts
(about which data is important)
– Data stores depicted on a DFD store all instances of data
entities (depicted on an ERD)
When to Draw Process Models
• Strategic systems planning

– Enterprise process models illustrate important business
functions.
• Business process redesign
– “As is” process models facilitate critical analysis.
– “To be” process models facilitate improvement.
• Systems analysis (primary focus of this course)
– Model the existing system including its limitations
– Model the target system’s logical requirements
(meaning processes and data flows needed regardless
of how the system will be implemented)
– Model candidate technical solutions (physical DFDs
only)
– Model the target technical solution (physical DFDs only)
Classical Structured Analysis
1. Draw top-down physical DFDs that represent the current physical

implementation of the system including its limitations.
2. Convert the physical DFDs to their logical equivalents.
3. Draw top-down logical DFDs that represent an improved system.
4. Describe all data flows, data stores, policies, and procedures in a
data dictionary or encyclopedia.
5. Optionally, mark up copies of the logical DFDs to represent
alternative physical solutions.
6. Draw top-down physical DFDs that represent the target solution.
THE ABOVE METHODOLOGY IS RARELY PRACTICED
ANYMORE BECAUSE IT IS VERY CUMBERSOME AND
TIME-CONSUMING.
Modern Structured Analysis
1. Draw a context DFD to establish initial project scope.

2. Draw a functional decomposition diagram to partition the
system into subsystems.
3. Create an event-response or use-case list for the system to
define events for which the system must have a response.
4. Draw an event DFD (or event handler) for each event.
5. Merge event DFDs into a system diagram (or, for larger
systems, subsystem diagrams).
6. Draw detailed, primitive DFDs for the more complex event
handlers.
7. Document data flows and processes in the data dictionary.
THE ABOVE METHODOLOGY, BASED ON EVENT
PARTITIONING, IS MORE COMMONLY PRACTICED.
Structured Analysis Diagram Progression (1 of 3)
CASE for DFDs (Sample Screen) from System Architect 2001
SoundStage Context DFD

Accounts
Club Promotion Receivable
Member Member
Credit
Member Order Status
Warehouse
various Inquiry Reponses Revised Packing Order

Potential New Subscription Member New Promotion
Member Services
Subscription Offer System Subscription Program
Subscription Renewal various Sales Reports
various
Promotion Reports Marketing
Department
various Subscription Reports
Past
Member Resubscription Offer
various Member Member
Reports Services
SoundStage Functional Decomposition Diagram

Member
Services
System
Subscription Promotion Order Operations

Subsystem Subsystem Subsystem Subsystem
Process Process Process Process

Subscription Promotion Order Membership
Transactions Transactions Transactions Transactions
Generate Generate Generate Process

Subscription Promotion Order Marketing
Reports Reports Reports Transactions
Process
Warehouse
Transactions
Events
• Events define processes needed to respond to those

events.
– External events are those initiated by external agents.
They result in an input transaction or data flow.
– Temporal events are those that are triggered by the
passage of time. They simply “happen” and are
indicated by a control flow.
– State events are those based on a system’s change
from one state to another.
Use Cases
• Use cases are based upon object-oriented concepts that

are essentially the same as events.
– Use case analysis is the process of identifying and
modeling business events and how the system
responds to them.
– An actor is anything that needs to interact with the
system (essentially, a synonym for external agent).
Use Case List
Actor Event (or Use Case) Trigger Responses
Marketing Establishes a new NEW MEMBER SUBSCRIPTION Generate SUBSCRIPTION

membership subscription plan PROGRAM PLAN CONFIRMATION.
to entice new members. Create AGREEMENT in the
database.
Marketing Establishes a new PAST MEMBER Generate SUBSCRIPTION
membership resubscription RESUBSCRIPTION PROGRAM PLAN CONFIRMATION.
plan to lure back former Create AGREEMENT in the
members. database.
Marketing Changes a subscription plan SUBSCRIPTION PLAN Generate AGREEMENT
for current members (e.g., CHANGE. CHANGE CONFIRMATION.
extending the fulfillment Update AGREEMENT in the
period) database.
(time) A subscription plan expires. (current date) Generate AGREEMENT
CHANGE CONFIRMATION.
Logically Delete (void)
AGREEMENT in the database.
Use Case List (continued)
Marketing Cancels a subscription plan Generate

before its planned expiration CANCELATION CHANGE CONFIRMATION.
Logically Delete (void)
AGREEMENT in the database.
Member Joins the club by subscribing. NEW SUBSCRIPTION Generate MEMBER

(“Take any 12 CDs for one DIRECTORY UPDATE
penny and agree to buy 4 CONFIRMATION.
more at regular prices within Create MEMBER in the
two years.”) database.
Create first MEMBER ORDER
MEMBER ORDERED
PRODUCTs in the database.
Member hanges address CHANGE OF ADDRESS Generate MEMBER

(including email and privacy DIRECTORY UPDATE
code) CONFIRMATION.
Update MEMBER in the
database.
Use Case List (continued)
Accounts Changes member’s credit CHANGE OF CREDIT STATUS Generate CREDIT

Receivable status DIRECTORY UPDATE
CONFIRMATION.
Update MEMBER in the
database.
(time) 90 days after a Marketing (current date) Generate CATALOG CHANGE
decides to no longer sell a CONFIRMATION.
product. Logically Delete
(deactivate) PRODUCT in the
database.
Member Wants to pick products for PRODUCT INQUIRY Generate CATALOG
possible purcase. DESCRIPTION.
(Logical requirement is driven
by vision of web-based access
Event Decomposition Diagram (partial)

Member
Services
System
Subscription Promotion Order Operations

Subsystem Subsystem Subsystem Subsystem
Process Generate Process Generate Process Generate Process Process Process

Subscription Subscription Promotion Promotion Order Order Membership Marketing Warehouse
Transactions Reports Transactions Reports Transactions Reports Transactions Transactions Transactions
Pg Pg Pg
2 3 4
Generate Generate Generate Generate Generate

Quarterly Inactive Agreement Membership Subscription
Subscription Member Compliance Directory Analysis
Report Report Report Report
Process Process Process Process Process Process New Process Process Process
New New Change Subscription Subscription Member Former Member Member
Subscription Resubscrip- to a Plan Expiration Plan Subscription Member Change of Change of
Plan tion Plan Subscription Cancelation Resubscrip- Address Preferences
Plan tion
External Event DFD
U p d a te d
C lu b M em ber C hange P ro c e s s M em ber
M em ber o f A d d re s s M em ber A d d re s s M e m b e rs
A d d re s s
C hange
M e m b e r U p d a te d A d d re ss C o n firm a tio n
External Event DFD (more complex)

Members Updated Member Accounts
from Order Receivable
Relevant
Member Transactions
Club Member Member Order Warehouse

Process
Member Packing Order
Order
Member
Order
Confirmation
New Inventory Commitment

Member Member
Orders Order
Product
New and Products
Member Availability
Ordered
Member Products
Ordered
Products
Temporal Event DFD
Members Agreements
Fulfillment Agreement
Progress
Agreement
Default
Calendar Exception Agreements
Identify
Report Manager
End of Month Agree-
ments
Near
Default
System DFD (see book for more readable copy)

Transactions Product and Availability
Products
Product and Inventory Commitment
Availability
Relevant
Transactions Member
Inventory Subscription Order
Commitmen
t
Member Member Order Warehouse
Process
Member Order Packing Order
Subscription
Order
Process Confirmation
Member Order Packing Order
Subscription
Confirmation Order
New Member Address

Ordered Products
New Member
Member Ordered
New
Member Products New Member Order
Order
Updated Member Members
from Order
Member Orders Deleted Updated
Members Member Orders Member Ordered Member Member
Products Orders Order
Updated
Member
Order
Updated Member Deleted Member
from Updated Order Ordered Products Member Order
Ordered Cancelation Member
Member Generate Process
Products
Order Member Order Analysis Member Order
Change Report Cancelation
Request Process Member
Member Order Updated Order
Member Order Confirmation Revision Member Cancelation
Ordered Notice
Products
Product and
Availability End of Day
Inventory
Commitment
Order
Revised Warehouse Time Analysis Club
Packing Order Report Directors
Products
Primitive DFD (see book for more readable copy)

Validate Member Members
Member
Member ID
and Address Updated Member from Order
Invalid Member ID
Invalid Invalid Product ID
Order
Validate
Ordered Product
Ordered Product
Product ID
Valid
Product Products
Ordered
Member Product Check Product Product Availability
Member Order Quantity Availability
Inventory Comittment
Available
Product
Bonus Product Price

Credits Calculate
Claimed Order Cost
Cost to
Member
Payment
Check Member Credit Details
Confirmed Member Order Credit
Transactions
Credit Problem and Instruction Relevant
Transactions
Order to be Filled Order to be Filled

Member Orders New
Member
Order Packing Warehouse
Record Order Release Order
Member Ordered Order
Products New Member
Ordered Products
Members Updated Credits
Data Structure for a Primitive Data Flow
Data Flow
Data
Structure
Logic for a Primitive Process
Process
Logic
8.30 Data to Process CRUD Matrix
8.31 Process to Location Association Matrix

Chap 008

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Chap 008

Enviado por

Direitos autorais:

Formatos disponíveis

OBJECT-ORIENTED SYSTEM ANALYSIS AND DESIGN

Chapter Eight Process Modeling

Models: Logical and Physical

A model is a representation of reality. Just as a

Logical models show Physical models show not

Why Logical System Models

• Logical models remove biases that are the result of the

• Logical models reduce the risk of missing business

• Logical models allow us to communicate with end-

Process Modeling and DFDs

Process modeling is a technique for organizing and

A data flow diagram (DFD) is a tool (and type of process

DFDs have become a popular tool for business process

Simple Data Flow Diagram

Differences Between DFDs and Flowcharts

• Processes on DFDs can operate in parallel (at-the-

• DFDs show the flow of data through a system

• Processes on one DFD can have dramatically different

Systems thinking is the application of formal systems

DFDs are a tool that supports systems thinking.

A process is work A System is a Process

Types of Logical Processes

• A function is set of related and ongoing activities of a

• An elementary process (or primitive process) is a

Common Process Errors on DFDs

Problems with Natural English

Structured English is a language and syntax, based on the

Structured English Constructs (Part 1)

Structured English Constructs (Part 2)

complex logic in which rows represent conditions

Structured English Constructs (Part 3)

Policies and Decision Tables

A policy is a set of rules that governs some process of

A decision table is a tabular form of presentation that

A Simple Decision Table

Data Flows & Control Flows

• A data flow represents an input of data to a process, or

– A composite data flow is a data flow that consists of

Data Flow Packet Concept

Composite and Elementary Data Flows

Data Flows to and from Data Stores

Illegal Data Flows

Data flows can be defined by data structures.

A data structure is a specific arrangement of data

A data attribute is the smallest piece of data that has

A Data Structure for a Data Flow

ORDER= An instance of ORDER consists of:

Data Structure Constructs

Data Structure Format by Example English Interpretation

Selection of Attributes - The ORDER= An instance or ORDER consists of:

Repetition of Attributes - The CLAIM= An instance of CLAIM consists of:

Data Structure Constructs (concluded)

Data Structure Format by Example English Interpretation

Data Types and Domains

Data attributes should be defined by data types and

A data type defines what class of data can be stored in an

A domain defines what values or range of values an

Diverging and Converging Data Flows

• A diverging data flow is one that splits into multiple

Diverging and Converging Data Flows

• An external agent defines a person, organization unit, or

• A data store is an inventory of data.

When to Draw Process Models