9 Process Modeling

Overview

Chapter 9 is a “technique” chapter that teaches the still important skill of process modeling. The focus is on drawing logical data flow diagrams. After teaching system and process modeling concepts to introduce DFD constructs, the chapter presents a contemporary approach to structured analysis based upon event partitioning.

Chapter to Course Sequencing

Students are encouraged to read Chapter 5 to provide perspective for logical system modeling. Adopters wishing to focus on object-oriented analysis techniques may want to skip this chapter in favor of Chapter 10. However, DFDs will not go away overnight. This is especially true given that DFDs have enjoyed something of a renaissance in new forms directed to business process redesign. For the time being, we recommend that this chapter be at least surveyed prior to introducing our object-oriented analysis coverage.

Given non-object-oriented analysis, there has always been disagreement concerning the sequencing of the modeling chapters. Classical structured analysis always sequenced process modeling before data modeling. Information engi- neering and modern structured analysis reversed that trend—data models were drawn first and their existence drove process modeling. Although we prefer the latter more contemporary approach, the chapters were designed to be covered in either sequence at the instructor’s preference.

What’s Different Here and Why?

This chapter did not necessitate many content changes from the sixth edition, but significant changes were made in the order in which that content is presented. The following changes have been made to this chapter in the sev- enth edition: 1. As with all chapters, we have streamlined the SoundStage episode into a quick narrative introduction to the concepts presented the chapter. 2. Several topics were rearranged in the chapter for better flow. This was based on actual field experience in teaching the concepts to students. • We begin with an introduction to process modeling. 9-2 Chapter Nine

• We next discuss system concepts for processing modeling, which quickly introduces the external agent, data stores, and processes. Processes are saved to last so that we can move into process concepts, such as decomposition, functions, events, etc. without students for- getting the overall relationship of processes to agents and data stores. • Data flow concepts are discussed next, which finishes laying the groundwork for drawing DFDs. • We next discuss the process of logical process modeling, including strategic systems planning, process modeling for BPR, and process modeling for systems analysis. We lay out the sets of the various systems analysis DFDs: context, decomposition, event-response list and event handlers, event diagram, system diagram, primitive diagrams. We also discuss fact-finding for process modeling and the role of CASE. • Next we walk through the process of constructing process models. • Now that the students have seen a completed DFD and know what it can tell them and what it cannot, then they are ready to learn about specifying process logic with structured English or decision tables. • The last topic, as in earlier editions, is synchronizing process models with data models and locations.

Lesson Planning Notes for Slides

The following instructor notes, keyed to slide images from the PowerPoint repository, are intended to help instructors integrate the slides into their individual lesson plans for this chapter.

Slide 1 This repository of slides is intended to support the named chapter. The slide repository should be Chapter 9 used as follows: Copy the file to a unique name for your course and unit. Edit the file by deleting those slides you don’t want to cover, editing other slides as appropriate to your course, and adding slides as desired. Process Modeling Print the slides to produce transparency masters or print directly to film or present the slides using a computer image projector.

Each slide includes instructor notes. To view those notes in PowerPoint, click-left on the View Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill/Irwin Menu; then click left on Notes View sub-menu. You may need to scroll down to see the instructor slide appearance after initial mouse click notes. in slide show mode The instructor notes are also available in hardcopy as the Instructor Guide to Accompany Sys- tems Analysis and Design Methods, 6/ed.

Slide 2 Chapter 9 objectives. Objectives

• Define systems modeling and differentiate logical and physical models. • Define process modeling and explain its benefits. • Recognize and understand 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 environment. • Identify use cases, external and temporal business events. • Perform event partitioning and organize events in a functional decomposition diagram. • Draw event diagrams and merge them into a system diagram. • Draw primitive data flow diagrams and describe the elementary data flows in terms of data structures and procedural logic. • Document the distribution of processes to locations. • Synchronize data and process models using a CRUD matrix.

Slide 3 Teaching Notes This slide shows the how this chapter's content fits with the building blocks framework used throughout the textbook. The emphasis of this chapter is upon PROCESSES. It also reflects the fact that process modeling may be performed during certain analysis phases and involves not only systems analysts…but owners and users.

9-3

Slide 4 Teaching Notes Models: Logical and Physical In some books, the term logical is called a conceptual or essential. The term essential comes Model – a pictorial representation of reality. from the notion that the model represents the Just as a picture is worth a thousand words, most “essence” of the system. models are pictorial representations of reality. For database-oriented instructors, the term logical in the world of systems analysis is NOT Logical model –a Physical model –a equivalent to the term logical in the world of data- nontechnical pictorial technical pictorial base. In the database world, a “logical schema” is representation that depicts representation that depicts what a system is or does. what a system is or does and already constrained by the choice of a database Synonyms or essential how the system is technology, which runs contrary to the systems model, conceptual model, implemented. Synonyms are and business model. implementation model and analysis expectation that a logical model is tech- technical model. nology-independent. 9-4 In some books, the term physical is called implementation or technical. Emphasize that there are nearly always multiple technical solutions for any given set of business requirements. In most projects, there is one logical model that represents the mandatory and desirable business requirements, regardless of how those requirements might be implemented. On the other hand, given that one logical model, there are multiple candidate physical models that could represent alternative, technical implemen- tations that could fulfill the business requirements (although analysts rarely draw more than one or two of those physical models).

Slide 5 No additional notes 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.

9-5

Slide 6 Teaching Notes Process Modeling and DFDs Many, if not most students have drawn or seen process models in the form of program flow- Process modeling – a technique used to organize and charts. document a system’s processes. • Flow of data through processes Unfortunately, flowcharts are control-flow process • Logic models as opposed to data flow process models. • Policies This can cause some students trouble because • Procedures they want to illustrate structured flow of control Data flow diagram (DFD) – a process model used to (nonparallel processing) in their early DFDs. depict the flow of data through a system and the work or Most introductory information systems books at processing performed by the system. Synonyms are bubble chart, transformation graph, and process model. least introduce, with one or two examples, DFDs. • The DFD has also become a popular tool for business process redesign.

9-6

Slide 7 Teaching Notes Simple Data Flow Diagram We have found it useful to walk through this first DFD. Don’t be alarmed if students take excep- tion to some of the oversimplification of the illustrated problem—it can actually contribute to the learning experience.

9-7

Slide 8 Differences Between DFDs No additional notes 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 a DFD can have dramatically different timing (daily, weekly, on demand) • Processes on flowcharts are part of a single program with consistent timing 9-8

Slide 9 Teaching Notes External Agents It is very important to emphasize the external agents on DFDs are not the same as entities on External agent – an outside person, unit, ERDs (from Chapter 7)—especially if the instruc- system, or organization that interacts with a system. Also called an external entity. tor prefers the more traditional term “external • External agents define the “boundary” or entity.” scope of a system being modeled. This is true even though you could have both an • As scope changes, external agents can become processes, and vice versa. entity (on an ERD) with the same name as an • Almost always one of the following: external agent/entity on a DFD. Consider the Gane and Sarson shape • Office, department, division. entity CUSTOMER and the external agent CUS- • An external organization or agency. • Another business or another TOMER: information system. The entity CUSTOMER indicates the requirement • One of system’s end-users or managers to store data about customers. • Named with descriptive, singular noun DeMarco/Yourdon shape 9-9 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.

Slide 10 Teaching Notes Data Stores Emphasize that a data store contains all instances of a data entity (from the data model). Data store – stored data intended for later use. Synonyms are file and database. That is why data store names are plurals (as • Frequently implemented as a file or database. contrasted to data entity names that are singular). • A data store is “data at rest” compared to a data Although we don’t prefer it, some analysts desig- flow that is “data in motion.” • Almost always one of the following: nate a data store to contain all instances of sev- • Persons (or groups of persons) eral entities and relationships from a data model. •Places •Objects For example, an ORDERS data store might in- • Events (about which data is captured) Gane and Sarson shape clude all instances of the data entities ORDER • Concepts (about which data is important) • Data stores depicted on a DFD store and ORDERED PRODUCT, and all instances of all instances of data entities the relationship between ORDER and ORDERED (depicted on an ERD) • Named with plural noun PRODUCT—We prefer the simplicity of repre- DeMarco/Yourdon shape 9-10 senting 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.

Slide 11 No additional notes Process Concepts

Process – work performed by a system in response to incoming data flows or conditions. A synonym is transform. • All information systems include processes - usually many of them • Processes respond to business events and conditions and transform Gane and Sarson shape data into useful information • Modeling processes helps us to understand the interactions with the system's environment, other systems, and other processes. • Named with a strong action verb followed by object clause describing what the work is performed on/for . 9-11

Slide 12 No additional notes. The System is Itself a Process

9-12

Slide 13 No additional notes. Process Decomposition

Decomposition – the act of breaking a system into sub-components. Each level of abstraction reveals more or less detail.

9-13

Slide 14 Teaching Notes Decomposition Diagrams Decomposition is a top-down problem-solving approach. Decomposition It might be useful to point out the numbering diagram –a tool scheme. This scheme is common, but we do not used to depict the like it because if the system is restructured, it decomposition of a forces renumbering all processes. system. Also Some instructors like to do a quick example using called hierarchy a small but realistic problem. chart.

9-14

Slide 15 No additional notes Types of Logical Processes

Function – a set of related and ongoing activities of a business. • A function has no start or end.

Event – a logical unit of work that must be completed as a whole. Sometimes called a transaction. • Triggered by a discrete input and is completed when process has responded with appropriate outputs. • Functions consist of processes that respond to events.

Elementary process – a discrete, detailed activity or task required to complete the response to an event. Also called a primitive process. • The lowest level of detail depicted in a process model.

9-15

Slide 16 Common Process Errors on Teaching Notes Idea: Correct this diagram as an in-class exer- DFDs cise. 3.1.1: To correct the diagram, a data flow, AC- COUNTING DATA, should be added from the data store, MEMBER ACCOUNTS, to process 3.1.1. 3.1.2: To fix the black hole, we might add an output data flow called NEW MEMBER AC- COUNT from process 3.1.2 to the data store MEMBER ACCOUNTS. 3.1.3: To fix the miracle, you would need to at least add a data flow such as ACCOUNTING 9-16 DATA from the data store, MEMBER AC- COUNTS, to process 3.1.3. In all likelihood, you also need some type of triggering data flow, such as ACCOUNT FREEZE AUTHORIZATION, from a new external agent, such ACCOUNTING DE- PARTMENT, to process 3.1 3.

Slide 17 Teaching Notes Data Flows & Control Flows Most books do not teach “control flows.” The were initially proposed by Paul Ward in his books Data flow – data that is input to or that extended structured analysis techniques to output from a process. cover real-time systems. They are especially • A data flow is data in motion Data flow name useful in contemporary information systems • A data flow may also be used to represent the creation, reading, deletion, analysis because they are as close as structured or updating of data in a file or database (called a data store). analysis gets to illustrating “messages” in an Composite data flow – a data flow object-oriented world. that consists of other data flows. Make sure students do not confuse data flows Control flow name Control flow – a condition or with flowchart arrows. Flowchart arrows are not nondata event that triggers a process. named because they merely indicate “the next • Used sparingly on DFDs. step.” Data flows pass actual data attributes to 9-17 and from processes. CRUD is a useful acronym from the database world to remember the basic data flows as they relate to data stores: Create, Read, Update (or change), and Delete. One of the most common uses of composite data flows is to combine many reports into a single data flow on a high-level DFD. They can also be used to combine similar transactions on a higher level DFD before differentiating between those flows on lower-level DFDs. Use case diagrams, an object-oriented analysis tool that also describes interfaces are taught in Chapter 7.

Slide 18 No additional notes. Data Flow Packet Concept

• Data that should travel together should be shown as a single data flow, no matter how many physical documents might be included.

9-18

Slide 19 Composite and Elementary No additional notes. Data Flows

Composite flow

Elementary flows

Junction indicates that any given order is an instance of only one of 9-19 the order types.

Slide 20 Composite and Elementary Teaching Notes Some DFD methodologies suggest that data Data Flows flows to and from data stores not be named. We think this confuses the end-users when they try to read the diagrams. Also, we believe that it is Composite flow easier to have DFD errors of omission if the rules state that some flows are named while others are Elementary not. flows Some DFD notations actually use the CRUD letters only to name flows to and from data stores. We consider this an acceptable alternative. CRUD is a useful acronym from the data- Junction indicates that any given order is an base world to remember the basic data flows as instance of only one of 9-19 the order types. they relate to data stores: Create, Read, Update (or change), and Delete.

Slide 21 No additional notes. Rules for Data Flows

• A data flow should never go unnamed. • In logical modeling, data flow names should describe the data flow without describing the implementation • All data flows must begin and/or end at a process.

9-21

Slide 22 No additional notes. Data Conservation

Data conservation – the practice of ensuring that a data flow contains only data needed by the receiving process. • Sometimes called starving the processes. • New emphasis on business process redesign to identify and eliminate inefficiencies. • Simplifies the interface between those processes. • Must precisely define the data composition of each data flow, expressed in the form of 9-22 data structures.

Slide 23 Conversion Notes Data Structures Many structured analysis books do not specifically use the term data structure, but the rela- Data attribute – the smallest piece of data that tional algebraic notation is very common in both has meaning to the users and the business. books and CASE tools. Data structure – a specific arrangement of data Some books refer to data attributes as data ele- attributes that defines an instance of a data flow. ments. Some also call them data fields, but some would argue that field is a very technical-, • The data attributes that comprise a data flow are organized into data structures. implementation-, or physical-oriented term (that is • Data flows can be described in terms of the following not consistent with our emphasis on logical types of data structures: DFDs). • A sequence or group of data attributes that occur one after another. • The selection of one or more attributes from a set of attributes. • The repetition of one or more attributes. 9-23

Slide 24 Teaching Notes Data Structure for a Data Flow Bring several “physical” business forms to class.

DATA STRUCTURE ENGLISH ENTERPRETATION Transform one form into its relational algebraic ORDER= An instance of ORDER consists of: ORDER NUMBER and data structure. Then, divide students into teams ORDER NUMBER + ORDER DATE and ORDER DATE+ Either PERSONAL CUSTOMER NUMBER [ PERSONAL CUSTOMER NUMBER, or CORPORATE ACCOUNT and ask them to perform the same exercise on a CORPORATE ACCOUNT NUMBER NUMBER]+ and SHIPPING ADDRESS (which is SHIPPING ADDRESS=ADDRESS+ equivalent to ADDRESS) form and present their solutions to the class. and optionally: BILLING ADDRESS (BILLING ADDRESS=ADDRESS)+ (which is equivalent to 1 {PRODUCT NUMBER+ 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 PRODUCT PRICE SOURCE and SUM OF EXTENDED PRICES+ EXTENDED PRICE PREPAID AMOUNT+ and SUM OF EXTENDED PRICES and (CREDIT CARD PREPAID AMOUNT and NUMBER+EXPIRATION DATE) optionally: both CREDIT CARD NUMBER (QUOTE NUMBER) and EXPIRATION DATE ADDRESS= An instance of ADDRESS consists of: optionally: POST OFFICE BOX NUMBER (POST OFFICE BOX NUMBER)+ and STREET ADDRESS+ STREET ADDRESS and CITY+ CITY and [STATE, MUNICIPALITY]+ Either STATE or MUNICIPALITY (COUNTRY)+ and optionally: COUNTRY 9-24 and POSTAL CODE POSTAL CODE

Slide 25 Teaching Notes Data Structure Constructs Point out that the same basic structures of sequence, selection, and iteration—that we applied Data Structure Format by Example English Interpretation (relevant portion is boldfaced (relevant portion is boldfaced) to procedures using Structured English—are Sequence of Attributes -The WAGE AND TAX STATEMENT= An instance of WAGE AND TAX sequence data structure TAXPAYER IDENTIFICATION STATEMENTS consists of: being applied here to describe data structures. indicates one or more attributes NUMBER+ TAXPAYER IDENTIFICATION that may (or must) be included in TAXPAYER NAME+ NUMBER and We have never found any form or file structure a data flow. TAXPAYER ADDRESS+ TAXPAYER NAME and that could not be described using this notation! WAGES, TIPS, AND TAXPAYER ADDRESS and COMPENSATION+ WAGES, TIPS AND FEDERAL TAX COMPENSATION and WITHHELD+… FEDERAL TAX WITHHELD and… Selection of Attributes -The ORDER= An instance or ORDER consists selection data structure allows (PERSONAL CUSTOMER of: you to show situations where NUMBER, Either PERSONAL different sets of attributes CORPORATE ACCOUNT CUSTOMER NUMBER or describe different instances of NUMBER)+ CORPORATE the data flow. ORDER DATE+… ACCOUNT NUMBER; and 9-25 ORDER DATE and…

Slide 26 Data Structure Constructs Teaching Notes (continued) Point out that the same basic structures of se- Data Structure Format by Example English Interpretation quence, selection, and iteration—that we applied (relevant portion is boldfaced (relevant portion is boldfaced) to procedures using Structured English—are Repetition of Attributes - The POLICY NUMBER+ An instance of CLAIM consists being applied here to describe data structures. repetition data structure is used POLICYHOLDER NAME+ of: to set off a data attribute or POLICY HOLDER POLICY NUMBER and We have never found any form or file structure group of data attributes that may ADDRESS+ POLICYHOLDER NAME and (or must) repeat themselves a 0 {DEPENDENT NAME+ POLICYHOLDER ADDRESS that could not be described using this notation! specific number of time for a DEPENDENT’S and single instance of the data flow. RELATIONSHIP} N+ zero or more instance of: The minimum number of 1 {EXPENSE DESCRIPTION+ DEPENDENT NAME and repetitions is usually zero or SERVICE PROVIDER+ DEPENDENT’S one. EXPENSE AMOUNT} N RELATIONSHIP and The maximum number of one or more instances of: repetitions may be specified as EXPENSE DESCRIPTION “n” meaning “many” where the and actual number of instances SERVICE PROVIDER and varies for each instance of the EXPENSE ACCOUNT data flow. 9-26

Slide 27 Data Structure Constructs Teaching Notes (concluded) Point out that the same basic structures of se- Data Structure Format by Example English Interpretation quence, selection, and iteration—that we applied (relevant portion is boldfaced (relevant portion is boldfaced) to procedures using Structured English—are Optional Attributes -The CLAIM= An instance of CLAIM consists optional notation indicates that POLICY NUMBER+ of: an attribute, or group of POLICYHOLDER NAME+ POLICY NUMBER and being applied here to describe data structures. attributes in a sequence or POLICYHOLDER ADDRESS+ POLICYHOLDER NAME and selection date structure may not ( SPOUSE NAME+ POLICYHOLDER ADDRESS We have never found any form or file structure be included in all instances of a DATE OF BIRTH)+… and data flow. optionally, SPOUSE NAME that could not be described using this notation! Note: For the repetition data and structure, a minimum of “zero” is DATE OF BIRTH and… the same as making the entire repeating group “optional.” Reusable Attributes -For DATE= Then, the reusable structures groups of attributes that are MONTH+ can be included in other data contained in many data flows, it DAY+ flow structures as follows: is desirable to create a separate YEAR+ ORDER=ORDER data structure that can be NUMBER…+DATE reused in other data structures. INVOICE=INVOICE NUMBER…+DATE PAYMENT=CUSTOMER 9-27 NUMBER…+DATE

Slide 28 Teaching Notes Data Types and Domains The same concepts with the same names were used in chapter 8. Data attributes should be defined by data types and domains.

Data type - a class of data that be stored in an attribute. • Character, integers, real numbers, dates, pictures, etc.

Domain – the legitimate values for an attribute. 9-28

Slide 29 Diverging and Converging No additional notes. Data Flows

Diverging data flow – a data flow that splits into multiple data flows. • Indicates data that starts out naturally as one flow, but is routed to different destinations. • Also useful to indicate multiple copies of the same output going to different destinations.

Converging data flow – the merger of multiple data flows into a single packet. • Indicates data from multiple sources that can (must) come together as a single packet for subsequent processing. 9-29

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

9-30

Slide 31 Teaching Notes When to Draw Process Models This is a context slide only. In this chapter, our demonstration of DFDs is exclusively for • Strategic systems planning “systems analysis,” specifically “require- • Enterprise process models illustrate important ments modeling.” 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 existing system including its limitations • Model target system’s logical requirements • Model candidate technical solutions

9-31 • Model the target technical solution

Slide 32 Teaching Notes Classical Structured Analysis It might be best NOT to show this slide to Rarely practiced anymore because cumbersome & time-consuming students. It is primarily intended to help instructors understand the differences between 1. Draw top-down physical DFDs that represent current original structured analysis and contempo- physical implementation of the system. rary structured analysis (the latter is shown 2. Convert physical DFDs to logical equivalents. on the next slide). 3. Draw top-down logical DFDs that represent improved system. This approach to systems analysis is rarely 4. Describe all data flows, data stores, policies, and practiced and is no longer recommended procedures in data dictionary or encyclopedia. even by its original evangelists, Tom DeMarco 5. Optionally, mark up copies of the logical DFDs to and Ed Yourdon. Yourdon officially updated represent alternative physical solutions. the methodology based on the seminal work, 6. Draw top-down physical DFDs representing target solution. Essential Systems Analysis, by McMenamin 9-32 and Palmer. The revised approach is shown on the next slide.

Slide 33 Modern Structured Analysis Teaching Notes (More Commonly Practiced) Although this process may not be as familiar to some adopters as the top-down, fully lev- 1. Draw context DFD to establish initial project scope. eled, classical “physical-logical-logical- 2. Draw functional decomposition diagram to partition the physical” approach in the 1976 DeMarco system into subsystems. methodology, this is the more contemporary 3. Create event-response or use-case list for the system approach and is taught in our book. The to define events for which the system must have a response. original approach is rarely, if ever, practiced 4. Draw an event DFD (or event handler) for each event. because it is so labor intensive and time con- 5. Merge event DFDs into a system diagram (or, for larger suming. systems, subsystem diagrams). 6. Draw detailed, primitive DFDs for the more complex event handlers. 7. Document data flows and processes in data dictionary. 9-33

Slide 34 Structured Analysis Diagram Teaching Notes The numbers in red correspond to the num- Progression (1 of 3) bers on the previous slide.

9-34

Slide 35 Structured Analysis Diagram Teaching Notes The numbers in red correspond to the num- Progression (2 of 3) bers on the slide 33.

9-35

Slide 36 Structured Analysis Diagram Teaching Notes The numbers in red correspond to the num- Progression (3 of 3) bers on the slide 33.

9-36

Slide 37 No additional notes. CASE for Process Modeling

9-37

Slide 38 Teaching Notes Context Data Flow Diagram This may be review from chapter 5.

• Context data flow diagram - a process model used to document the scope for a system. Also called the environmental model.

1. Think of the system as a "black box." 2. Ask users what business transactions the system must respond to. These are inputs, and the sources are external agents. 3. Ask users what responses must be produced by the system. These are outputs, and the destinations are external agents. 4. Identify any external data stores, if any. 5. Draw a context diagram. 9-38

Slide 39 Teaching Notes SoundStage Context DFD Emphasize that a context DFD does not have to show every net data flow. For most systems, that would overwhelm the reader. Triv- ial or less common flows can be omitted until later diagrams, and composite data flows can be created to combine multiple flows. As a result, and in the strictest sense, not all primitive data flows may “balance” up to the context DFD, but we sacrifice that balancing to improve readability and validation. All data flows on the context DFD will balance down to the lower-level DFDs (although composite 9-39 data flows will be replaced by their separate component data flows).

Slide 40 SoundStage Functional No additional notes. Decomposition Diagram

• Break system into sub-components to reveal more detail. • Every process to be factored should be factored into at least two child processes. • Larger systems might be factored into subsystems and functions. 9-40

Slide 41 Teaching Notes Events and Use Cases Events are very similar to use cases in object- oriented analysis. • External events are initiated by external agents. They Events are represented on DFDs as data flows result in an input transaction or data flow. (for external events) or control flows (for tem- • Temporal events are triggered on the basis of time, poral and state events). or something that merely happens. They are indicated by a control flow.

• State events trigger processes based on a system’s change from one state or condition to another. They are indicated by a control flow.

• Use case – an analysis tool for finding and identifying business events and responses.

• Actor – anything that interacts with a system. 9-41

Slide 42 SoundStage Partial Use Case Teaching Notes Walk through this so that students under- List stand what goes in a use case list for DFDs. Actor/ Event Trigger Response External Agent (or Use Case) This is an abbreviated list from what is shown Marketing Establishes a new New Member Generate Subscription Plan membership Subscription Confirmation. in the text. subscription plan to Program Create Agreement in the entice new members. database. Marketing Establishes a new Past Member Generate Subscription Plan membership Resubscription Confirmation. resubscription plan to Program Create Agreement in the lure back former database. members. (time) A subscription plan (current date) Generate Agreement Change expires. Confirmation. Logically delete Agreement in database. Member Joins club by New Generate Member Directory subscribing. Subscription Update Confirmation. Create Member in database. Create first Member Order and Member Ordered Products in 9-42 database.

Slide 43 SoundStage Partial Teaching Notes Most event decomposition diagrams will re- Event Decomposition Diagram quire multiple pages (or one very large plot- ter-style page) because most systems are required to respond to many events (possibly dozens or hundreds).

9-43

Slide 44 No additional notes. Event Diagrams

Event diagram – data flow diagram that depicts the context for a single event. • One diagram for each event process • Depicts • Inputs from external agents • Outputs to external agents • Data stores from which records must be "read." Data flows should be added and named to reflect the data that is read. • Data stores in which records must be created, deleted, or updated. Data flows should be named to reflect the update. 9-44

Slide 45 No additional notes. Simple Event Diagram

9-45

Slide 46 No additional notes. Event Diagram (more complex)

9-46

Slide 47 No additional notes. Temporal Event Diagram

9-47

Slide 48 Teaching Notes System DFD 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.

9-48

Slide 49 No additional notes. System DFD (concluded)

9-49

Slide 50 Teaching Notes Balancing Discuss balancing with the class, the concept that requires that data flow diagrams at different levels of detail reflect consistency and Balancing - a concept that requires that completeness. data flow diagrams at different levels of

detail reflect consistency and completeness

• Quality assurance technique • Requires that if you explode a process to another DFD to reveal more detail, you must include the same dta flows and data stores

9-50

Slide 51 Teaching Notes Primitive Diagrams It is important to recognize that not all events require a primitive DFD to be drawn. This is especially true of most report-writing and • Some (not necessarily all) event inquiry response event processes. Drawing processes may be exploded into primitive detailed DFDs for such processes is usually diagrams to reveal more detail. little more than “busy work.” • Complex business transaction processes • Process decomposed into multiple elementary processes • Each elementary process is cohesive - it does only one thing • Flow similar to computer program structure

9-51

Slide 52 No additional notes. Primitive DFD (see book for more readable copy)

9-52

Slide 53 Specifying a Data Flow Teaching Notes The screen capture demonstrates the dia- Using a CASE Tool logue box used to insert the data structure for a data flow on a DFD. Each data flow would require a similar data structure to be specified.

9-53

Slide 54 No additional notes. Process Logic

• Data Flow Diagrams good for identifying and describing processes • Not good at showing logic inside processes • Need to specify detailed instructions for elementary processes • How to do it? • Flowcharts & Pseudocode - most end users do not understand them • Natural English - imprecise and subject to interpretation

9-54

Slide 55 Conversion Notes Problems with Natural English The text on this slide has been shortened for the sake of readability. Refer to Figure 9-6 in •Many do not write well and do not the text for fuller explanations and examples. question writing abilities. •Many too educated to communicate with general audience •Some write everything like it was a program. •Can allow computing jargon, acronyms to dominate language. Source: Adapted from Matthies, Leslie, The New Playscript Procedure, 9-55 (Stamford, CT: Office Publications, Inc. 1977) •Statements frequently have

Slide 56 Teaching Notes Structured English On the diagram, we recorded the Structured English inside the process box to reinforce Structured English – a language syntax the fact that the Structured English specifies for specifying the logic of a process. the underlying procedure being executed by the process. In practice, the procedural • Based on the relative strengths of structured programming and natural English. specification is recorded in a data dictionary/encyclopedia that is separate from the actual diagram (but linked to/associated with the process “name” on the DFD). If students are familiar with pseudocode, point out the similarities and differences between Structured English and pseudocode. 9-56

Slide 57 Structured English Constructs No additional notes. (Part 1)

9-57

Slide 58 Structured English Constructs Teaching Notes Decision tables are useful for simplifying very (Part 2) complex combinations of conditions. They replace complex, nested if-then-else selection structures.

9-58

Slide 59 Structured English Restrictions No additional notes. on Process Logic

• Only strong, imperative verbs may be used. • Only names that have been defined in project dictionary may be used. • Formulas should be stated clearly using appropriate mathematical notations. • Undefined adjectives and adverbs are not permitted. • Blocking and indentation are used to set off the beginning and ending of constructs. • User readability should always take priority. 9-59

Slide 60 No additional notes. Policies and Decision Tables

Policy – a set of rules that govern show a process is to be completed.

Decision table – a tabular form of presentation that specifies a set of conditions and their corresponding actions. • As required to implement a policy.

9-60

Slide 61 No additional notes. A Simple Decision Table

9-61

Slide 62 Describing an Elementary No additional notes. Process Using a CASE Tool

9-62

Slide 63 Data & Process Model No additional notes. Synchronization CRUD Matrix

9-63

Slide 62 No additional notes. Process Distribution

9-64

Answers to End of Chapter Questions and Exercises

Review Questions

1. A logical model is a non-technical design shows what a system is and/or what it does. Logical models are independent of any technical implementation issues and do not show how the system will do something, only what it will do. Common synonyms for logical model are essential model, conceptual model, and business model.

2. Logical models help encourage creativity and reduce stakeholder biases by focusing only on business issues, not technical implementation concerns. As a result, there is less risk that stakeholders will lose sight of the core business issues and miss critical business requirements. Logical models, because they are not technical in nature, also provide an excellent method for systems analysts to communicate with system owners and users in a language they are comfortable with.

3. A data flow diagram is a graphic tool that illustrates how data moves through a system, and what processing is performed by the system as the data flows through it. Common synonyms include bubble chart, transformation graph, and process model.

4. There are three major differences between data flow diagrams and flowcharts.

1) On a data flow diagram, multiple processes can operate concurrently. On a flowchart, only one process at a time can execute.

2) Data flow diagrams show the paths through which data moves through the system; and looping and/or branching are typically not shown. Flowcharts show the sequence of processes through the system, and include looping and branching.

3) Data flow diagrams are time-independent; the processes shown on data flow diagrams can occur at widely different times. Flowcharts are the opposite, i.e., they are time-dependent.

5. A system is considered to be process because it performs work on or in response to inputs from the environment, and has a feedback and control loop

6. Decomposition is the technique of breaking a system into subsystems and subprocesses, which in turn are broken down into smaller subsystems and subprocesses, until a manageable subset is achieved. Because an entire system is usually too complex or large to view and understand as a single

process, the purpose of decomposition is to promote understanding by being able to view a process as a whole. The tool used to show the decomposition of a system is a decomposition diagram, also called hierarchy chart.

7. a. Function: a set of related and ongoing activities of a business which have no beginning or end, but which operate continuously as needed. For example, an accounting system may have functions such as account receivable systems, account payable systems, and payroll systems, etc.

b. Event: a logical unit of work that is triggered by a specific, separate input, and which must by completed as a whole with appropriate outputs. For example, for the payroll function, there may be events such as print checks, calculate salary, and calculate tax withheld.

c. Elementary process: Also called a primitive process, it is the specific lowest level of activity or task needed to complete the response to an. For example, in the calculate tax withheld event, there may be processes such as validate salary input and update employees’ information.

8. a. A process that has inputs but no outputs (often called a black hole).

b. A process whose inputs are not able to produce the output shown, because the inputs and/or outputs are misnamed, or because the facts are not complete. (often called a gray hole)

c. A process that has outputs, but no inputs.

9. Structured English is a language syntax based upon a combination of structured programming and natural English that is used to specify process logic in data flow diagrams and other process models. Structured English is an effective method of communicating in a consistent and coherent manner with both non-technical end-users, who must be able to understand whether the logic is correct, and with technical developers, who must build and implement the business logic in the system

10. The convention for data flow names is to use nouns and noun phrases that are singular, descriptive and unique. Adjectives and adverbs can be used to help describe how a data flow has been changed or transformed by processing. For example, for data flow concerning checking out a product, it should be named CHECKOUT, which is singular. Also, in order to make it unique, it could add adjectives or adverbs to the data flow name. In this case, CHECKOUT can be changed to VALIDATE CHECKOUT, SUCCESSFUL CHECKOUT, or CHECKOUT FAILED.

11. Data conservation is a technique that ensures a data flow does not contain excess data, but only the data actually needed by the process receiving the input. Data conservation is used to simplify the interfaces between different processes and to eliminate inefficiencies in processing data.

12. External agents or external entities are people, organizations, units of an organization and systems outside the system boundary that that interact with the system inside the boundary. External agents can change because as project scope and goals change, the boundaries of the information system can grow or shrink. External agents formerly outside the boundary may now be inside the boundary, and vice versa

13. Context data flow diagram: this is used in the very beginning of the analysis to set up the initial scope of the project. This diagram is often about one page in length, and it shows the major interaction between the system and its environment.

Functional decomposition diagram: this diagram is used to divide the system into smaller logical functions. If the system is small, this diagram can be omitted.

Event-Response or Use case list: either one of the list will be constructed to make sure the business events that the system must respond.

Event decomposition diagram: event handlers may be added to the decomposition diagram for each of the event. Until now, the outline of the system is established.

Event diagram: this is an optional diagram used to validate for each of the event.

System diagram: this diagram is used to combine all the event diagrams.

Primitive diagram: this is used specially for event processes that need additional processing details. It will show all the elementary processes, data stores, and data flows for an event.

14. A context data flow diagram, also called an environmental model, is used. (Add an explanation of what is depicted.)

15. Even though data and process models are showing different perspectives of the system, they are closely related. Therefore, we should make sure both kinds of models are synchronized so that consistency and completeness can be achieved for the system.

Problems and Exercises

1. Your responses may vary, but a basic response should include the following logical processes and data flows:

Entities: Data Stores: Employee Payroll Transactions Employee’s Supervisor Employer bank account Employer’s Bank Employee bank account Payroll Department

Logical Processes: Data Flows: Prepare time sheet Time sheet Review and approve time sheet Approved time sheet Prepare bi-weekly payroll Bi-weekly payroll list Authorize and disburse funds Electronic fund transfer Deposit funds E-mail notifications

2. 1F, 2J, 3G, 4K, 5L, 6H, 7C, 8A, 9B, 10M, 11D, 12, 13E

3. In a decomposition diagram, there is no such thing as a single child, because it would not show any additional detail. A parent must always have two or more children.

For different reasons, a child may have only one parent – it cannot be a decomposition of more than one process.

Arrowheads are not shown on the connections of a decomposition diagram because the diagram shows structure, not flow.

The connections are not named because they implicitly all have the same name – CONSISTS OF. If all the child processes were added together, the sum would be the parent process.

4. Car Pool Lane Policy Decision Table Conditions Rule 1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6 Rule 7 and Actions Passen- Passen- Passen- Motor- All All C1: Type of ger ger ger cycle Hybrid Others Others Vehicle Vehicle Vehicle Vehicle Doesn’t Doesn’t Doesn’t Doesn’t C2: At least Yes No No matter matter matter matter

2 people C3: During Doesn’t Doesn’t Doesn’t carpool re- matter Yes No matter matter Yes No stricted times and days

A1: Let ve- X X X X X hicle pass A2: Stop X X vehicle and write ticket

5. a. Use the “black box” approach, i.e., visualize the system you are building as a container. At this point, it doesn’t matter how things that are inside work, you just want to identify what is out and what is in.

b. Determine your net inputs, i.e., the business events your system must respond to. The sources of these net inputs are external agents.

c. Determine your net outputs, i.e., the responses that your system must produce to the business events. The destination of each of these net outputs is also an external agent.

d. Identify each data store your system uses. Can your system change the database or file structure? If the answer is no, the database or file is an external data store and outside the project scope.

6. a. Net inputs: Request For Investigation form, Completed Investigation Re- port

b. Net outputs: New Case Folder, Completed Investigation Report, Open/Close/In Progress Case Listing Report, Closed Investigation Report

c. External agents: Other Divisions, Field Offices

d. External data stores: State Criminal Justice Database, Federal Criminal Justice Database

7. Your context diagram should have: a. One and only one process, labeled “HQ Case Tracking System” or something similar. b. Two Net Inputs from two sources (external agents): a. Request for Investigation Form from Other Divisions

b. Completed Investigation Report from Field Office c. Three Net Outputs to two destinations (external agents) a. New Case Folder to Field Offices b. Closed Investigation Report to Other Divisions c. Open/Closed/In Progress Case Listing Report to Field Offices d. Two external agents (Other Divisions, Field Offices) e. Two external data stores: Federal Criminal Justice Database, State Criminal Justice Database

8. The Structured English should look something like this:

1. For each INVESTIGATION CASE NUMBER in the data store CASES a. For each FIELD OFFICE in the data store FIELD OFFICES that matches the above INVESTIGATION CASE 1) Keep a running total of CASES OPENED DURING PAST WEEK for the FIELD OFFICE 2) Keep a running total of CASES COMPLETED DURING PAST WEEK for the FIELD OFFICE 3) Keep a running total of CASES IN PROGRESS for the FIELD OF- FICE 4) Keep a running total of CASES IN PROGRESS OVER 6 MONTHS for the FIELD OFFICE

9. The root process is the entire system – the Case Tracking System

The subsystems and their processes may vary. One basic example might be as follows:

1.0 Operations Subsystem 1.1 Process incoming Requests for Service 1.2 Process incoming Completed Investigation Reports 1.3 Process outgoing Closed Investigation Reports

2.0 Reports Subsystem 2.1 Generate Opened/Closed/In Progress Case Listing Report 2.2 Generate New Case Folder

3.0 Table Maintenance Subsystem 3.1 Update Division Office Table 3.2 Update Field Office Table 3.3 Update Investigator Table

10. The partial use-case table should look something like this:

Actor Event (or Use Case) Trigger Responses

Other Divi- Requests that an inves- REQUEST FOR Generate NEW sion tigation be initiated INVESTIGATION CASE FOLDER form Create INVESTI- GATION in the database Field Office Notifies headquarters COMPLETED IN- Generate CLOSED office that an investiga- VESTIGATION INVESTIGATION tion has been com- REPORT REPORT pleted and the case can be closed Update INVESTI- GATION in the database (time) New work week begins (current date) Generate OPEN/CLOSED/IN PROGRESS CASE LISTING REPORT

11. The diagram for the selected event should depict one process. The input sources and output destinations should be shown as external agents. If a data store record is read as part of the event, the data store and data flow should be shown in the diagram. The data flow should be appropriately named re the data that is read. Any other data stores in which CRUD activity takes place should also be included in the diagram, along with named data flows.

12. A8, B5, C7, D6, E1, F9, G10, H12, I11, J3, K2, L13, M4

13. Your matrix should resemble the one used in Figure 9-30. Every entry should have at least one Create, Read, Update or Delete entry.

Project and Research

1. Response is open-ended, but should reference points made in this chapter and Chapter 5 as to the value of design modeling. For example, would expect to see references made to the value of data flow diagrams in business process redesign, the value of Structured English in helping users and developers come to a common understanding, etc.

2. Depending on the methodologies chosen, response may indicate the differences are mainly cosmetic or may find significant differences. Response should examine not only notation methods, but also high-level approaches,

conceptual bases, modeling processes and sequences, modeling diagrams used, and related tools and techniques.

3. Response should show data flow diagrams that are consistent with the textbook templates. Data flow diagrams for the two methods of renewing a subscription should be roughly similar, but the DFD for the digital version should have fewer tasks since it does not require manual key data entry by the publishing company, nor does it require any manual handling or delivery of the hardcopy versions. For the publisher, the online renewal and digital format would probably be preferred since it is far less costly. Advan- tages from the perspective of the subscriber should include quicker delivery and no physical storage problem for old issues. Disadvantages should include that even with current technology, readability is less than with a printed version, and portability is inherently limited!

4. Response is open-ended, but should be insightful and well-reasoned. Fur- ther, response should indicate that all these authors have and/or are very visionary, and are still highly respected by their peers as leading thinkers, (although they are sharing the field with more competitors than in years past).

5. Open-ended as to choice of system, but response should be complete and thorough. Further, should use the data flow diagrams, data structures, and other tools and techniques described in the textbook to produce a cohesive and convincing set of documentation diagrams.

6. Open-ended, with a wide variety of viewpoints, depending upon currency and position of articles that referenced in the response. But in general, would expect a response to the effect that many leaders in systems design feel that data and process modeling are being absorbed into and/or inte- grated with OOA and modeling, rather than being replaced.

Mini-Cases

1. Note to professor: This task and the open-ended ones like it can be a great learning tool. Focus students on determining what the current system par- ticulars are rather than what students want them to be. Encourage students to document existing business processes without judgment. As for the actual diagrams: students usually are able to get the majority of processes in the systems level diagram. They do usually miss an external input/output or data stores (internal and external) – so keep your eye out.

2. Note to professor: Have students be aware of scope creep. Are they adding functionality that they think is “cool,” or are they creating a system that has a richness of functionality for the business? Remind students that these

are very different things. Also, be careful to make sure that students streamline the use of information and the input of said information – their goal should be for input to happen one time only.

3. Note to professor: Most probably, the students will not have gotten enough information from their initial interview to complete this task. Remind them that this is an iterative process. I.e. as system analysts, they will be return- ing to their customer many times to fully understand the customer’s needs for a new system.

4. Note to professor: They will probably state that there is a large difference between what they think the system should have and do, and what it actually does. Many departments have cumbersome and somewhat outdated business processes that are not efficient. Why is that?

Team and Individual Exercises

There are no answers to this section.