9 Process Modeling Overview Chapter 9 is a “technique” chapter that teaches the still important skill of proc- ess modeling. The focus is on drawing logical data flow diagrams. After teach- ing 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 tech- niques 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 con- cerning 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 edi- tion, 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.
Transcript
9
Process Modeling
Overview
Chapter 9 is a “technique” chapter that teaches the still important skill of proc-ess modeling. The focus is on drawing logical data flow diagrams. After teach-ing 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 tech-niques 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 con-cerning 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 edi-tion, 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.
• 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 sys-tems 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 re-pository, are intended to help instructors integrate the slides into their individ-ual lesson plans for this chapter. Slide 1
slide appearance after initial mouse click in slide show mode
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 Sys-tems Analysis and Design Methods, 6/ed.
Slide 2 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.
Chapter 9 objectives.
Slide 3
9-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.
Slide 4
9-4
Models: Logical and Physical
Logical model – a nontechnical pictorial representation that depicts what a system is or does. Synonyms or essential model, conceptual model, and business model.
Physical model – a technical pictorial representation that depicts what a system is or does and how the system is implemented. Synonyms are implementation model and technical model.
Model – a pictorial representation of reality. Just as a picture is worth a thousand words, most models are pictorial representations of reality.
Teaching Notes In some books, the term logical is called a con-ceptual or essential. The term essential comes from the notion that the model represents the “essence” of the system. For database-oriented instructors, the term logi-cal in the world of systems analysis is NOT equivalent to the term logical in the world of data-base. 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 tech-nology-independent. In some books, the term physical is called imple-mentation or technical. Emphasize that there are nearly always multiple technical solutions for any given set of business requirements. In most projects, there is one logi-cal 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).
• 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 notes
Slide 6
9-6
Process Modeling and DFDsProcess modeling – a technique used to organize and document a system’s processes.
• Flow of data through processes• Logic• Policies• Procedures
Data flow diagram (DFD) – a process model used to depict the flow of data through a system and the work or processing performed by the system. Synonyms are bubble chart, transformation graph, and process model.
• The DFD has also become a popular tool for business process redesign.
Teaching Notes Many, if not most students have drawn or seen process models in the form of program flow-charts. 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.
Slide 7
9-7
Simple Data Flow Diagram
Teaching Notes 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 illus-trated problem—it can actually contribute to the learning experience.
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 a DFD can have dramatically different timing (daily, weekly, on demand)• Processes on flowcharts are part of a single program
with consistent timing
No additional notes
Slide 9
9-9
External AgentsExternal agent – an outside person, unit, system, or organization that interacts with a system. Also called an external entity. • 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.• An external organization or agency.• Another business or another
information system.• One of system’s end-users or managers
• Named with descriptive, singular noun
Gane and Sarson shape
DeMarco/Yourdon shape
Teaching Notes 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 instruc-tor 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 CUS-TOMER: The entity CUSTOMER indicates the requirement to store data about customers. The external agent CUSTOMER indicates the requirement for an interaction (inputs and/or out-puts) 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
9-10
Data StoresData store – stored data intended for later use. Synonyms are file and database. • 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)
• Named with plural noun
Gane and Sarson shape
DeMarco/Yourdon shape
Teaching Notes Emphasize that a data store contains all in-stances 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 desig-nate a data store to contain all instances of sev-eral entities and relationships from a data model. For example, an ORDERS data store might in-clude 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 repre-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 ac-ceptable 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 proc-esses.
Decomposition diagram – a tool used to depict the decomposition of a system. Also called hierarchy chart.
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.
Slide 15
9-15
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.
No additional notes
Slide 16
9-16
Common Process Errors on DFDs
Teaching Notes Idea: Correct this diagram as an in-class exer-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 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.
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
Data flow name
Control flow name
Teaching 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. 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.
Slide 18
9-18
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.
Teaching 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 alterna-tive. CRUD is a useful acronym from the data-base world to remember the basic data flows as they relate to data stores: Create, Read, Update (or change), and Delete.
Slide 21
9-21
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.
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 data structures.
No additional notes.
Slide 23
9-23
Data Structures
• The data attributes that comprise a data flow are organized into data structures.
• Data flows can be described in terms of the following types of data structures:• 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.
Data attribute – the smallest piece of data that has meaning to the users and the business.
Data structure – a specific arrangement of data attributes that defines an instance of a data flow.
Conversion Notes Many structured analysis books do not specifi-cally use the term data structure, but the rela-tional algebraic notation is very common in both books and CASE tools. Some books refer to data attributes as data ele-ments. Some also call them data fields, but some would argue that field is a very technical-, implementation-, or physical-oriented term (that is not consistent with our emphasis on logical DFDs).
Slide 24
9-24
Data Structure for a Data FlowDATA STRUCTURE
ORDER=ORDER NUMBER +ORDER DATE+[ PERSONAL CUSTOMER NUMBER,
An instance of ORDER consists of:ORDER NUMBER andORDER DATE andEither PERSONAL CUSTOMER NUMBER
or CORPORATE ACCOUNT NUMBERand SHIPPING ADDRESS (which is equivalent to ADDRESS)and optionally: BILLING ADDRESS (which is equivalent to ADDRESS)and one or more instances of:
and SUM OF EXTENDED PRICES andPREPAID AMOUNT andoptionally: both CREDIT CARD NUMBER and EXPIRATION DATE
An instance of ADDRESS consists of:optionally: POST OFFICE BOX NUMBER andSTREET ADDRESS andCITY andEither STATE or MUNICIPALITYand optionally: COUNTRYand POSTAL CODE
Teaching Notes Bring several “physical” business forms to class. Transform one form into its relational algebraic data structure. Then, divide students into teams and ask them to perform the same exercise on a form and present their solutions to the class.
Selection of Attributes - The selection data structure allows you to show situations where different sets of attributes describe different instances of the data flow.
An instance of WAGE AND TAX STATEMENTS consists of:
TAXPAYER IDENTIFICATION NUMBER and
TAXPAYER NAME andTAXPAYER ADDRESS andWAGES, TIPS AND
COMPENSATION andFEDERAL TAX WITHHELD
and…
WAGE AND TAX STATEMENT=TAXPAYER IDENTIFICATION
NUMBER+TAXPAYER NAME+TAXPAYER ADDRESS+WAGES, TIPS, AND
COMPENSATION+FEDERAL TAX
WITHHELD+…
Sequence of Attributes - The sequence data structure indicates one or more attributes that may (or must) be included in a data flow.
English Interpretation(relevant portion is boldfaced)
Format by Example(relevant portion is boldfaced
Data Structure
Teaching Notes Point out that the same basic structures of se-quence, selection, and iteration—that we applied to procedures using Structured English—are being applied here to describe data structures. We have never found any form or file structure that could not be described using this notation!
Slide 26
9-26
Data Structure Constructs (continued)
An instance of CLAIM consists of:
POLICY NUMBER andPOLICYHOLDER NAME andPOLICYHOLDER ADDRESS
andzero or more instance of:
DEPENDENT NAME andDEPENDENT’S
RELATIONSHIP andone or more instances of:
EXPENSE DESCRIPTION and
SERVICE PROVIDER andEXPENSE ACCOUNT
POLICY NUMBER+POLICYHOLDER NAME+POLICY HOLDER
ADDRESS+0 {DEPENDENT NAME+
DEPENDENT’S RELATIONSHIP} N+
1 {EXPENSE DESCRIPTION+SERVICE PROVIDER+EXPENSE AMOUNT} N
Repetition of Attributes - The repetition data structure is used to set off a data attribute or group of data attributes that may (or must) repeat themselves a specific number of time for a single instance of the data flow.
The minimum number of repetitions is usually zero or one.
The maximum number of repetitions may be specified as “n” meaning “many” where the actual number of instances varies for each instance of the data flow.
English Interpretation(relevant portion is boldfaced)
Format by Example(relevant portion is boldfaced
Data Structure
Teaching Notes Point out that the same basic structures of se-quence, selection, and iteration—that we applied to procedures using Structured English—are being applied here to describe data structures. We have never found any form or file structure that could not be described using this notation!
Slide 27
9-27
Data Structure Constructs (concluded)
Then, the reusable structures can be included in other data flow structures as follows:
ORDER=ORDER NUMBER…+DATE
INVOICE=INVOICE NUMBER…+DATE
PAYMENT=CUSTOMER NUMBER…+DATE
DATE=MONTH+DAY+YEAR+
Reusable Attributes - For groups of attributes that are contained in many data flows, it is desirable to create a separate data structure that can be reused in other data structures.
An instance of CLAIM consists of:
POLICY NUMBER andPOLICYHOLDER NAME andPOLICYHOLDER ADDRESS
andoptionally, SPOUSE NAME
andDATE OF BIRTH and…
CLAIM=POLICY NUMBER+POLICYHOLDER NAME+POLICYHOLDER ADDRESS+( SPOUSE NAME+DATE OF BIRTH)+…
Optional Attributes - The optional notation indicates that an attribute, or group of attributes in a sequence or selection date structure may not be included in all instances of a data flow.Note: For the repetition data structure, a minimum of “zero” is the same as making the entire repeating group “optional.”
English Interpretation(relevant portion is boldfaced)
Format by Example(relevant portion is boldfaced
Data Structure
Teaching Notes Point out that the same basic structures of se-quence, selection, and iteration—that we applied to procedures using Structured English—are being applied here to describe data structures. We have never found any form or file structure that could not be described using this notation!
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.
Teaching Notes The same concepts with the same names were used in chapter 8.
Slide 29
9-29
Diverging and Converging 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.
No additional notes.
Slide 30
9-30
Diverging and Converging Data Flows
Teaching 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.
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 existing system including its limitations • Model target system’s logical requirements• Model candidate technical solutions• Model the target technical solution
Teaching Notes This is a context slide only. In this chapter, our demonstration of DFDs is exclusively for “systems analysis,” specifically “require-ments modeling.”
Slide 32
9-32
Classical Structured AnalysisRarely practiced anymore because cumbersome & time-consuming
1. Draw top-down physical DFDs that represent current physical implementation of the system.
2. Convert physical DFDs to logical equivalents.3. Draw top-down logical DFDs that represent improved
system.4. Describe all data flows, data stores, policies, and
procedures in data dictionary or encyclopedia.5. Optionally, mark up copies of the logical DFDs to
represent alternative physical solutions.6. Draw top-down physical DFDs representing target
solution.
Teaching Notes It might be best NOT to show this slide to students. It is primarily intended to help in-structors understand the differences between original structured analysis and contempo-rary 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.
Slide 33
9-33
Modern Structured Analysis(More Commonly Practiced)
1. Draw context DFD to establish initial project scope.2. Draw functional decomposition diagram to partition the
system into subsystems.3. Create 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 data dictionary.
Teaching Notes Although this process may not be as familiar to some adopters as the top-down, fully lev-eled, 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 con-suming.
• 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.
Teaching Notes This may be review from chapter 5.
Slide 39
9-39
SoundStage Context DFD
Teaching Notes Emphasize that a context DFD does not have to show every net data flow. For most sys-tems, 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 primi-tive data flows may “balance” up to the con-text 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 data flows will be replaced by their separate component data flows).
SoundStage Functional 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.
No additional notes.
Slide 41
9-41
Events and Use Cases• External events are initiated by external agents. They
result in an input transaction or data flow.
• Temporal events are triggered on the basis of time, 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.
Teaching Notes Events are very similar to use cases in object-oriented analysis. Events are represented on DFDs as data flows (for external events) or control flows (for tem-poral and state events).
Slide 42
9-42
SoundStage Partial Use Case List
Generate Member Directory Update Confirmation.Create Member in database.Create first Member Order and Member Ordered Products in database.
New Subscription
Joins club by subscribing.
Member
Generate Agreement Change Confirmation.Logically delete Agreement in database.
(current date)A subscription plan expires.
(time)
Generate Subscription Plan Confirmation.Create Agreement in the database.
Past Member ResubscriptionProgram
Establishes a new membership resubscription plan to lure back former members.
Marketing
Generate Subscription Plan Confirmation.Create Agreement in the database.
New Member Subscription Program
Establishes a new membership subscription plan to entice new members.
Marketing
ResponseTriggerEvent (or Use Case)
Actor/External Agent
Teaching Notes Walk through this so that students under-stand what goes in a use case list for DFDs. This is an abbreviated list from what is shown in the text.
Teaching Notes Most event decomposition diagrams will re-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).
Slide 44
9-44
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.
Teaching Notes 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 decom-position diagram.
Balancing - a concept that requires that 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
Teaching Notes Discuss balancing with the class, the concept that requires that data flow diagrams at differ-ent levels of detail reflect consistency and completeness.
Slide 51
9-51
Primitive Diagrams
• Some (not necessarily all) event processes may be exploded into primitive diagrams to reveal more detail.• 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
Teaching Notes 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 inquiry response event processes. Drawing detailed DFDs for such processes is usually little more than “busy work.”
Teaching Notes The screen capture demonstrates the dia-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 speci-fied.
Slide 54
9-54
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-55Source: Adapted from Matthies, Leslie, The New Playscript Procedure,
(Stamford, CT: Office Publications, Inc. 1977)
Problems with Natural English
•Many do not write well and do not 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.
•Statements frequently have
Conversion Notes The text on this slide has been shortened for the sake of readability. Refer to Figure 9-6 in the text for fuller explanations and examples.
Slide 56
9-56
Structured English
Structured English – a language syntax for specifying the logic of a process.
• Based on the relative strengths of structured programming and natural English.
Teaching Notes 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 diction-ary/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 be-tween Structured English and pseudocode.
Teaching Notes Decision tables are useful for simplifying very complex combinations of conditions. They replace complex, nested if-then-else selection structures.
Slide 59
9-59
Structured English Restrictions 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.
No additional notes.
Slide 60
9-60
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.
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 implementa-tion issues and do not show how the system will do something, only what it will do. Common synonyms for logical model are essential model, concep-tual 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, transforma-tion graph, and process model.
4. There are three major differences between data flow diagrams and flow-
charts.
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 in-clude 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 re-
sponse 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 ac-
count receivable systems, account payable systems, and payroll systems, etc.
b. Event: a logical unit of work that is triggered by a specific, separate in-
put, 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 low-
est level of activity or task needed to complete the response to an. For example, in the calculate tax withheld event, there may be proc-
esses 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, be-
cause 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 struc-
tured 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 process-ing.
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 differ-ent 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 sys-tem 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 analy-
sis 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 sys-tem 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 decom-position 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 addi-tional 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, be-
cause 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 de-composition 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 and Actions
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
Generate NEW CASE FOLDER Create INVESTI-GATION in the da-tabase
Field Office Notifies headquarters office that an investiga-tion has been com-pleted and the case can be closed
COMPLETED IN-VESTIGATION REPORT
Generate CLOSED INVESTIGATION REPORT Update INVESTI-GATION in the da-tabase
(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 ac-tivity 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 ex-pect to see references made to the value of data flow diagrams in business process redesign, the value of Structured English in helping users and de-velopers come to a common understanding, etc.
2. Depending on the methodologies chosen, response may indicate the differ-
ences 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 text-
book templates. Data flow diagrams for the two methods of renewing a sub-scription 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 deliv-ery 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 in-clude 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 stu-dents to document existing business processes without judgment. As for the actual diagrams: students usually are able to get the majority of proc-esses in the systems level diagram. They do usually miss an external in-put/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 actu-ally 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.
