1. Lesson-22 Process Modeling(2)
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.

2. 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.
Teaching Notes
In previous editions, we tried to distinguish between “information systems” and “computer applications” (the latter being a subset of the former). This created more confusion with students than it was worth.
Some books use the term “computer technology.” We prefer the more contemporary term “information technology” as a superset of computer technology.

3. 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
Teaching Notes
In previous editions, we tried to distinguish between “information systems” and “computer applications” (the latter being a subset of the former). This created more confusion with students than it was worth.
Some books use the term “computer technology.” We prefer the more contemporary term “information technology” as a superset of computer technology.

4. Diverging and Converging Data Flows
Conversion Notes
Different CASE tools use different notations to illustrate converging and diverging data flows. In fact, some CASE tools do not even support this concept.

5. 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.
One of your system’s end-users or managers
Conversion Notes
Most books refer to external agents by the name of external entities. Eventually, we expect to borrow the object-oriented term “actors.”
Teaching Tips
It is very important to emphasize the external agents on DFDs are not the same as entities on ERDs (from Chapter 7)—especially if the instructor prefers the more traditional term “external entity.”
This is true even though you could have both an entity (on an ERD) with the same name as an external agent/entity on a DFD. Consider the entity CUSTOMER and the external agent CUSTOMER:
The entity CUSTOMER indicates the requirement to store data about customers.
The external agent CUSTOMER indicates the requirement for an interaction (inputs and/or outputs) with customers.
It is very important for students to understand that external agents are “processes” outside of the scope of the system or business. As such, as scope “increases,” external agents can become processes. Conversely, if scope “decreases,” processes can become external agents.

6. 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
Objects
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)
Teaching Tips
Emphasize that a data store contains all instances of a data entity (from the data model). That is why data store names are plurals (as contrasted to data entity names that are singular).
Although we don’t prefer it, some analysts designate a data store to contain all instances of several entities and relationships from a data model. For example, an ORDERS data store might include all instances of the data entities ORDER and ORDERED PRODUCT, and all instances of the relationship between ORDER and ORDERED PRODUCT—We prefer the simplicity of representing each data entity from the data model as its own data store on the process models.
Emphasize that because data stores are shared resources available to many processes, it is acceptable to duplicate them on several DFDs—The duplication does NOT indicate redundant storage (on logical DFDs); it merely represents the sharing of the data store by several processes.

7. 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)
Teaching Tips
This is a context slide only. In this chapter, our demonstration of DFDs is exclusively for “systems analysis,” specifically “requirements modeling.”

8. Classical Structured Analysis
Draw top-down physical DFDs that represent the current physical implementation of the system including its limitations.
Convert the physical DFDs to their logical equivalents.
Draw top-down logical DFDs that represent an improved system.
Describe all data flows, data stores, policies, and procedures in a data dictionary or encyclopedia.
Optionally, mark up copies of the logical DFDs to represent alternative physical solutions.
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.
Conversion Notes
It might be best NOT to show this slide to students. It is primarily intended to help instructors understand the differences between original structured analysis and contemporary structured analysis (the latter is shown on the next slide).
This approach to systems analysis is rarely practiced and is no longer recommended even by its original evangelists, Tom DeMarco and Ed Yourdon. Yourdon officially updated the methodology based on the seminal work, Essential Systems Analysis, by McMenamin and Palmer. The revised approach is shown on the next slide.

9. Modern Structured Analysis
Draw a context DFD to establish initial project scope.
Draw a functional decomposition diagram to partition the system into subsystems.
Create an event-response or use-case list for the system to define events for which the system must have a response.
Draw an event DFD (or event handler) for each event.
Merge event DFDs into a system diagram (or, for larger systems, subsystem diagrams).
Draw detailed, primitive DFDs for the more complex event handlers.
Document data flows and processes in the data dictionary.
THE ABOVE METHODOLOGY, BASED ON EVENT PARTITIONING, IS MORE COMMONLY PRACTICED.
Conversion Notes
Although this process may not be as familiar to some adopters as the top-down, fully leveled, classical “physical-logical-logical-physical” approach in the 1976 DeMarco methodology, this is the more contemporary approach and is taught in our book. The original approach is rarely, if ever, practiced because it is so labor intensive and time consuming.

10. Structured Analysis Diagram Progression
No additional notes.
Structured Analysis Diagram Progression

11. CASE for DFDs (Sample Screen)
No additional notes.

12. 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.
Conversion Notes
For instructors not familiar with event-driven structured analysis, see the Yourdon book, Modern Structured Analysis.
Events are very similar to use cases in object-oriented analysis.
Teaching Tips
Events are represented on DFDs as data flows (for external events) or control flows (for temporal and state events).

13. 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).
Conversion Notes
Why teach use cases in a DFD chapter? Simple! We recognized the similarity of concept between Yourdon’s event-response structured analysis paradigm and Jacobsen’s use case object-oriented analysis paradigm.
Note that DFDs are included in at least one early object-oriented analysis methodology, namely, OMT (Rumbaugh, et al.).
Teaching Tips
Agents are essentially equivalent to DFD external agents.

14. Use Case List Actor Event (or Use Case) Trigger Responses Marketing
Establishes a new
NEW MEMBER SUBSCRIPT
ION
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 PROGR AM
PLAN CONFIRMATION .
plan to lure back former
Create
AGREEMENT
in the
members.
database.
Marketing
Changes a subscription plan
SUBSCRIPTION PLAN
Generate
AGREEMENT
No additional notes.
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 da
tabase.

15. System DFD (see book for more readable copy)
Generate
Order Analysis
Report
Process
Member Order
Cancelation
Revision
Subscription
Order
Club
Directors
Time
Warehouse
Member
Member Ordered
Products
Transactions
Member Orders
Members
Inventory Commitment
Product and Availability
Address
New Member Order
New Member
Ordered Products
Notice
Updated
Deleted
Deleted Member
Analysis
End of Day
Orders
Ordered
Packing Order
Member Order Confirmation
Inventory
Commitment
Product and
Availability
Updated Member
from Updated Order
Relevant
Commitmen t
New
from Order
Confirmation
Revised
Change
Request
Subscription Order
Teaching Tips
Most system DFDs will not fit on one or two pages—too many event processes. Instead they must be illustrated in a series of system diagrams that correspond to the structure originally depicted in the functional decomposition diagram.

16. Data to Process CRUD Matrix
No additional notes.

17. Process to Location Association Matrix
No additional notes.