C H A P T E R

1. This repository of slides is intended to support the named chapter. The slide repository should be 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. 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 Menu; then click left on Notes View sub-menu. You may need to scroll down to see the instructor notes. The instructor notes are also available in hard copy as the Instructor Guide to Accompany Systems Analysis and Design Methods, 5/ed. This repository of slides is intended to support the named chapter. The slide repository should be 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. 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 Menu; then click left on Notes View sub-menu. You may need to scroll down to see the instructor notes. The instructor notes are also available in hard copy as the Instructor Guide to Accompany Systems Analysis and Design Methods, 5/ed.

2. Chapter Nine 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. 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. No additional notesNo additional notes

3. Chapter Map No additional notesNo additional notes

4. Models: Logical and Physical Logical models show what a system is or does. They are implementation independent; that is, they depict the system independent of any technical implementation. Physical models show not only what a system is or does, but also how the system is (to be) physically and technically implemented. They are implementation dependent because they reflect technology choices. Conversion Notes In some books, the term logical is called a conceptual or essential. The term essential comes from the notion that the model represents the �essence� of the system. For database-oriented instructors, the term logical in the world of systems analysis is NOT equivalent to the term logical in the world of database. In the database world, a �logical schema� is already constrained by the choice of a database technology, which runs contrary to the systems analysis expectation that a logical model is technology-independent. In some books, the term physical is called implementation or technical. Teaching Tips 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 implementations that could fulfill the business requirements (although analysts rarely draw more than one or two of those physical models).Conversion Notes In some books, the term logical is called a conceptual or essential. The term essential comes from the notion that the model represents the �essence� of the system. For database-oriented instructors, the term logical in the world of systems analysis is NOT equivalent to the term logical in the world of database. In the database world, a �logical schema� is already constrained by the choice of a database technology, which runs contrary to the systems analysis expectation that a logical model is technology-independent. In some books, the term physical is called implementation or technical. Teaching Tips 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 implementations that could fulfill the business requirements (although analysts rarely draw more than one or two of those physical models).

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

6. 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. Teaching Tips Many, if not most students have drawn or seen process models in the form of program flowcharts. Unfortunately, flowcharts are control-flow process models as opposed to data flow process models. This can cause some students trouble because they want to illustrate structured flow of control (nonparallel processing) in their early DFDs. Most introductory information systems books at least introduce, with one or two examples, DFDs.Teaching Tips Many, if not most students have drawn or seen process models in the form of program flowcharts. Unfortunately, flowcharts are control-flow process models as opposed to data flow process models. This can cause some students trouble because they want to illustrate structured flow of control (nonparallel processing) in their early DFDs. Most introductory information systems books at least introduce, with one or two examples, DFDs.

7. Simple Data Flow Diagram Teaching Tips We have found it useful to walk through this first DFD. Don�t be alarmed if students take exception to some of the oversimplification of the illustrated problem�it can actually contribute to the learning experience.Teaching Tips We have found it useful to walk through this first DFD. Don�t be alarmed if students take exception to some of the oversimplification of the illustrated problem�it can actually contribute to the learning experience.

8. 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 No additional notesNo additional notes

9. Systems Thinking Systems thinking is the application of formal systems theory and concepts to systems problem solving. Systems theory and concepts help us understand how systems are organized and work DFDs are a tool that supports systems thinking. Teaching Tips We like to emphasize to students that the problems typically solved in college are much smaller and simpler than those encountered in the real world. Systems thinking is a technique that will pay off as problem size and complexity grow. All system models taught in this book (including ERDs and object models) are based upon system thinking.Teaching Tips We like to emphasize to students that the problems typically solved in college are much smaller and simpler than those encountered in the real world. Systems thinking is a technique that will pay off as problem size and complexity grow. All system models taught in this book (including ERDs and object models) are based upon system thinking.

10. Process Concepts A process is work performed on, or in response to, incoming data flows or conditions. A System is a Process Teaching Tips The nebulous �system environment� was intended to represent the constantly changing reality that characterizes all systems. The trick is to design systems to adapt to such change, or to be easily adapted to such change. Feedback and control is included to monitor the system and adapt to change.Teaching Tips The nebulous �system environment� was intended to represent the constantly changing reality that characterizes all systems. The trick is to design systems to adapt to such change, or to be easily adapted to such change. Feedback and control is included to monitor the system and adapt to change.

11. 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. No additional notesNo additional notes

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

13. Decomposition Diagrams Each process is either a parent process or a child process A parent must have two or more children In most cases a child may have only one parent A child process may be a parent process as well

14. Types of Logical Processes A function is set of related and ongoing activities of a business (ie. Order Processing) An event (or transaction) is a logical unit of work that must be completed as a whole - as part of a function (ie. Process Customer Order) 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 (Validate Customer Number)  No additional notesNo additional notes

15. Functions Processes that respond to Events Each event is represented by a respond process Genreate ______________ Process _______________ Respond to ____________

16. Logical Process Models Omit Any process that simply moves data from one location to another Include Processes that Perform computations Make decisions Sort, filter, or summarize data Organize data into useful information Use stored data (CRUD)

17. Common DFD Errors Black Holes Inputs to a process but no output Miracles Creating output with no input Gray Hole Insufficient inputs to create the desired results

18. Common Process Errors on DFDs Teaching Tips Idea: Correct this diagram as an in-class exercise. 3.1.1: To correct the diagram, a data flow, ACCOUNTING 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 ACCOUNT 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 DATA from the data store, MEMBER ACCOUNTS, 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 DEPARTMENT, to process 3.1 3.Teaching Tips Idea: Correct this diagram as an in-class exercise. 3.1.1: To correct the diagram, a data flow, ACCOUNTING 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 ACCOUNT 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 DATA from the data store, MEMBER ACCOUNTS, 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 DEPARTMENT, to process 3.1 3.

19. Process Logic Decomposition diagrams and data flow diagrams are effective tools for identifying processes, but are not good at showing the logic inside those processes. Eventually need to specify detailed instructions. Should effectively communicate with both users and programmers. Flowcharts and pseudocode are difficult for users to understand. Natural English is no imprecise (see Figure 9-6). Structured English has advantages of natural English with some of the rigor of programming logic. No additional notes.No additional notes.

20. Problems with Natural English Many of us do not write well,  Many of us are too educated a graduate has a working vocabulary of around 5,000 words. Some of us write everything like it was a program.  Too often, we allow the jargon and acronyms of computing to dominate our language. English statements frequently have an excessive or confusing scope.  We overuse compound sentences  Too many words have multiple definitions. Too many statements use imprecise adjectives.  Conditional instructions can be imprecise.  Compound conditions tend to show up in natural English. No additional notesNo additional notes

21. 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. Teaching Tips On the diagram, we recorded the Structured English inside the process box to reinforce the fact that the Structured English specifies the underlying procedure being executed by the process. In practice, the procedural 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.Teaching Tips On the diagram, we recorded the Structured English inside the process box to reinforce the fact that the Structured English specifies the underlying procedure being executed by the process. In practice, the procedural 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.

22. Structured English Constructs Teaching Tips Decision tables are useful for simplifying very complex combinations of conditions. They replace complex, nested if-then-else selection structures.Teaching Tips Decision tables are useful for simplifying very complex combinations of conditions. They replace complex, nested if-then-else selection structures.

23. Structured English Constructs Teaching Tips Finally, iteration is also based on classic flow-of-control structures from structured programming. We have found it appropriate to at least review the basic difference �repeat until� (= do at least once) and �do while� (do only if and until) iterations.Teaching Tips Finally, iteration is also based on classic flow-of-control structures from structured programming. We have found it appropriate to at least review the basic difference �repeat until� (= do at least once) and �do while� (do only if and until) iterations.

24. 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). Teaching Tips Do the poker chip problem as a fun, in-class exercise to illustrate the potential and value of decision tables.Teaching Tips Do the poker chip problem as a fun, in-class exercise to illustrate the potential and value of decision tables.

25. A Simple Decision Table No additional notesNo additional notes

26. Structured English Constructs Teaching Tips The notion of sequence and selection is based on classic flow-of-control structures in structured programming.Teaching Tips The notion of sequence and selection is based on classic flow-of-control structures in structured programming.

27. 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 � used in high level DFDs A control flow represents a condition or nondata event that triggers a process. Used sparingly on DFDs. Data Flows & Control Flows Conversion Notes Most books do not teach �control flows.� The were initially proposed by Paul Ward in his books that extended structured analysis techniques to cover real-time systems. They are especially useful in contemporary information systems analysis because they are as close as structured analysis gets to illustrating �messages� in an object-oriented world. Teaching Tips Make sure students do not confuse data flows with flowchart arrows. Flowchart arrows are not named because they merely indicate �the next step.� Data flows pass actual data attributes to 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. Context diagrams are taught in Chapter 8. Use case diagrams, an object-oriented analysis tool that also describes interfaces, will be taught in Part Five, Module A. Context diagrams are taught in Chapter 8. Use case diagrams, an object-oriented analysis tool that also describes interfaces, will be taught in Part Five, Module A.Conversion Notes Most books do not teach �control flows.� The were initially proposed by Paul Ward in his books that extended structured analysis techniques to cover real-time systems. They are especially useful in contemporary information systems analysis because they are as close as structured analysis gets to illustrating �messages� in an object-oriented world. Teaching Tips Make sure students do not confuse data flows with flowchart arrows. Flowchart arrows are not named because they merely indicate �the next step.� Data flows pass actual data attributes to 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. Context diagrams are taught in Chapter 8. Use case diagrams, an object-oriented analysis tool that also describes interfaces, will be taught in Part Five, Module A. Context diagrams are taught in Chapter 8. Use case diagrams, an object-oriented analysis tool that also describes interfaces, will be taught in Part Five, Module A.

28. Data Flow Packet Concept No additional notesNo additional notes

29. Composite and Elementary Data Flows No additional notesNo additional notes

30. Data Flows to and from Data Stores Conversion Notes Some DFD methodologies suggest that data 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 easier to have DFD errors of omission if the rules state that some flows are named while others are not. 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 database world to remember the basic data flows as they relate to data stores: Create, Read, Update (or change), and Delete.Conversion Notes Some DFD methodologies suggest that data 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 easier to have DFD errors of omission if the rules state that some flows are named while others are not. 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 database world to remember the basic data flows as they relate to data stores: Create, Read, Update (or change), and Delete.

31. Data flow � data that is input to or output from a process. A data flow is data in motion 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). Composite data flow � a data flow that consists of other data flows. Control flow � a condition or nondata event that triggers a process. Used sparingly on DFDs. Data Flows & Control Flows Conversion Notes Most books do not teach �control flows.� The were initially proposed by Paul Ward in his books that extended structured analysis techniques to cover real-time systems. They are especially useful in contemporary information systems analysis because they are as close as structured analysis gets to illustrating �messages� in an object-oriented world. Teaching Notes Make sure students do not confuse data flows with flowchart arrows. Flowchart arrows are not named because they merely indicate �the next step.� Data flows pass actual data attributes to 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.Conversion Notes Most books do not teach �control flows.� The were initially proposed by Paul Ward in his books that extended structured analysis techniques to cover real-time systems. They are especially useful in contemporary information systems analysis because they are as close as structured analysis gets to illustrating �messages� in an object-oriented world. Teaching Notes Make sure students do not confuse data flows with flowchart arrows. Flowchart arrows are not named because they merely indicate �the next step.� Data flows pass actual data attributes to 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.

32. Illegal Data Flows No additional notesNo additional notes