system analysis and design Chap008

1,682 views

Published on

Published in: Data & Analytics, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,682
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
133
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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.
  • No additional notes
  • No additional notes
  • 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).
  • No additional notes
  • 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
    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.
  • No additional notes
  • 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
    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.
  • No additional notes
  • 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.
  • No additional notes
  • 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.
  • No additional notes
  • 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
    Decision tables are useful for simplifying very complex combinations of conditions. They replace complex, nested if-then-else selection structures.
  • 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
    The notion of sequence and selection is based on classic flow-of-control structures in structured programming.
  • Teaching Tips
    Do the poker chip problem as a fun, in-class exercise to illustrate the potential and value of decision tables.
  • No additional notes
  • 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.
  • No additional notes
  • No additional notes
  • 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.
  • No additional notes
  • Conversion Notes
    Many structured analysis books do not specifically use the term data structure, but the relational algebraic notation is very common in both books and CASE tools.
    Some books refer to data attributes as data elements. 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).
  • Teaching Tip
    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.
  • Teaching Tips
    Point out that the same basic structures of sequence, 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!
  • Teaching Tips
    Point out that the same basic structures of sequence, 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!
  • <number>
    Chapter 8 - Process Modeling
    Teaching Notes
    In previous editions, we tried to distinguish between “information systems” and “computer applications” (the latter being a subset of the former). This created more confusion with students than it was worth.
    Some books use the term “computer technology.” We prefer the more contemporary term “information technology” as a superset of computer technology.
  • <number>
    Chapter 8 - Process Modeling
    Teaching Notes
    In previous editions, we tried to distinguish between “information systems” and “computer applications” (the latter being a subset of the former). This created more confusion with students than it was worth.
    Some books use the term “computer technology.” We prefer the more contemporary term “information technology” as a superset of computer technology.
  • <number>
    Chapter 8 - Process Modeling
    Conversion Notes
    Different CASE tools use different notations to illustrate converging and diverging data flows. In fact, some CASE tools do not even support this concept.
  • <number>
    Chapter 8 - Process Modeling
    Conversion Notes
    Most books refer to external agents by the name of external entities. Eventually, we expect to borrow the object-oriented term “actors.”
    Teaching Tips
    It is very important to emphasize the external agents on DFDs are not the same as entities on ERDs (from Chapter 7)—especially if the instructor prefers the more traditional term “external entity.”
    This is true even though you could have both an entity (on an ERD) with the same name as an external agent/entity on a DFD. Consider the entity CUSTOMER and the external agent CUSTOMER:
    The entity CUSTOMER indicates the requirement to store data about customers.
    The external agent CUSTOMER indicates the requirement for an interaction (inputs and/or outputs) with customers.
    It is very important for students to understand that external agents are “processes” outside of the scope of the system or business. As such, as scope “increases,” external agents can become processes. Conversely, if scope “decreases,” processes can become external agents.
  • <number>
    Chapter 8 - Process Modeling
    Teaching Tips
    Emphasize that a data store contains all instances of a data entity (from the data model). That is why data store names are plurals (as contrasted to data entity names that are singular).
    Although we don’t prefer it, some analysts designate a data store to contain all instances of several entities and relationships from a data model. For example, an ORDERS data store might include all instances of the data entities ORDER and ORDERED PRODUCT, and all instances of the relationship between ORDER and ORDERED PRODUCT—We prefer the simplicity of representing each data entity from the data model as its own data store on the process models.
    Emphasize that because data stores are shared resources available to many processes, it is acceptable to duplicate them on several DFDs—The duplication does NOT indicate redundant storage (on logical DFDs); it merely represents the sharing of the data store by several processes.
  • <number>
    Chapter 8 - Process Modeling
    Teaching Tips
    This is a context slide only. In this chapter, our demonstration of DFDs is exclusively for “systems analysis,” specifically “requirements modeling.”
  • <number>
    Chapter 8 - Process Modeling
    Conversion Notes
    It might be best NOT to show this slide to students. It is primarily intended to help instructors understand the differences between original structured analysis and contemporary structured analysis (the latter is shown on the next slide).
    This approach to systems analysis is rarely practiced and is no longer recommended even by its original evangelists, Tom DeMarco and Ed Yourdon. Yourdon officially updated the methodology based on the seminal work, Essential Systems Analysis, by McMenamin and Palmer. The revised approach is shown on the next slide.
  • <number>
    Chapter 8 - Process Modeling
    Conversion Notes
    Although this process may not be as familiar to some adopters as the top-down, fully leveled, classical “physical-logical-logical-physical” approach in the 1976 DeMarco methodology, this is the more contemporary approach and is taught in our book. The original approach is rarely, if ever, practiced because it is so labor intensive and time consuming.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    Teaching Tips
    This context comes directly from Chapter 3. The blue processes and the blue and black data flows define systems analysis.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    Teaching Tips
    Emphasize that a context DFD does not have to show every net data flow. For most systems, that would overwhelm the reader. Trivial 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 data flows will be replaced by their separate component data flows).
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    Conversion Notes
    For instructors not familiar with event-driven structured analysis, see the Yourdon book, Modern Structured Analysis.
    Events are very similar to use cases in object-oriented analysis.
    Teaching Tips
    Events are represented on DFDs as data flows (for external events) or control flows (for temporal and state events).
  • <number>
    Chapter 8 - Process Modeling
    Conversion Notes
    Why teach use cases in a DFD chapter? Simple! We recognized the similarity of concept between Yourdon’s event-response structured analysis paradigm and Jacobsen’s use case object-oriented analysis paradigm.
    Note that DFDs are included in at least one early object-oriented analysis methodology, namely, OMT (Rumbaugh, et al.).
    Teaching Tips
    Agents are essentially equivalent to DFD external agents.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    Teaching Tips
    Most event decomposition diagrams will require multiple pages (or one very large plotter-style page) because most systems are required to respond to many events (possibly dozens or hundreds).
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    Teaching Tips
    Most system DFDs will not fit on one or two pages—too many event processes. Instead they must be illustrated in a series of system diagrams that correspond to the structure originally depicted in the functional decomposition diagram.
  • <number>
    Chapter 8 - Process Modeling
    Teaching Tips
    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.”
  • <number>
    Chapter 8 - Process Modeling
    Teaching Tips
    The screen capture demonstrates the dialogue 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.
  • <number>
    Chapter 8 - Process Modeling
    Teaching Tips
    The screen capture demonstrates the dialogue box used to insert the logic structure for a process on a DFD. Only those processes for which the logic is not intuitive would require a similar logic structure to be specified.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • <number>
    Chapter 8 - Process Modeling
    No additional notes.
  • system analysis and design Chap008

    1. 1. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition 8 C H A P T E R PROCESS MODELING
    2. 2. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Chapter Eight Process Modeling • Define systems modeling and differentiate between logical and physical system models. • Define process modeling and explain its benefits. • Recognize and understand the basic concepts and constructs of a process model. • Read and interpret a data flow diagram. • Explain when to construct process models and where to store them. • Construct a context diagram to illustrate a system’s interfaces with its work environment. • Identify use cases, external and temporal business events for a system. • Perform event partitioning and organize events in a functional decomposition diagram. • Draw event diagrams and merge those events into a system diagram. • Draw primitive data flow diagrams and describe the elementary data flows and processes in terms of data structures and procedural logic (Structured English and decision tables), respectively. • Document the distribution of processes to locations. • Synchronize data and process models using a CRUD matrix.
    3. 3. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Chapter Map
    4. 4. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition 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. A model is a representation of reality. Just as a picture is worth a thousand words, most models are pictorial representations of reality.
    5. 5. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition 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.
    6. 6. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition 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.
    7. 7. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Simple Data Flow Diagram
    8. 8. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition 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
    9. 9. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Systems Thinking Systems thinking is the application of formal systems theory and concepts to systems problem solving. DFDs are a tool that supports systems thinking.
    10. 10. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Process Concepts A process is work performed on, or in response to, incoming data flows or conditions. A System is a Process T h e S y s t e m is a P r o c e s s in p u t o u t p u t in p u t in p u t o u t p u t o u t p u t F e e d a c k a n d C o n t r o l L o o p T h e S y s t e m 's E n v ir o n m e n t ( c o n s t a n t ly c h a n g in g ) A P r o c e s s
    11. 11. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition System Decomposition 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.
    12. 12. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Decomposition Diagrams A decomposition diagram or hierarchy chart shows the top- down, functional decomposition of a system.
    13. 13. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Types of Logical Processes • A function is set of related and ongoing activities of a business. • An event (or transaction) is a logical unit of work that must be completed as a whole (as part of a function). • An elementary process (or primitive process) is a discrete, detailed activity or task required to respond to an event. Usually, several such tasks must be completed to respond to an event.
    14. 14. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Common Process Errors on DFDs
    15. 15. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition PROBLEMS WITH NATURAL ENGLISH 1 Source: Adapted from Matthies, Leslie, The New Playscript Procedure, (Stamford, CT: Office Publications, Inc. 1977) Problems with Natural English • Many of us do not write well, and we also tend not to question our writing abilities. • Many of us are too educated! It’s often difficult for a highly educated person to communicate with an audience that may not have had the same educational opportunities. For example, the average college graduate (including most analysts) has a working vocabulary of 10,000 to 20,000 words; on the other hand, the average non-college graduate has a working vocabulary of around 5,000 words. • Some of us write everything like it was a program. If business procedures required such precision, we’d write everything in a programming language. • Too often, we allow the jargon and acronyms of computing to dominate our language. • English statements frequently have an excessive or confusing scope. How would you carry out this procedure: “If customers walk in the door and they do not want to withdraw money from their account or deposit money to their account or make a loan payment, send them to the trust department.” Does this mean that the only time you should not send the customer to the trust department is when he or she wishes to do all three of the transactions? Or does it mean that if a customer does not wish to perform at least one of the three transactions, that customer should not be sent to the trust department? • We overuse compound sentences Consider the following procedure: “Remove the screws that hold the outlet cover to the wall. Remove the outlet cover. Disconnect each wire from the plug, but first make sure the power to the outlet has been turned off.” An unwary person might try to disconnect the wires prior to turning off the power! • Too many words have multiple definitions. • Too many statements use imprecise adjectives. For example, an loan officer asks a teacher to certify that a student is in good academic standing. What is good? • Conditional instructions can be imprecise. For example, if we state that “all applicants under the age of 19 must secure parental permission,” do we mean less than 19, or less than or equal to 19? • Compound conditions tend to show up in natural English. For example, if credit approval is a function of several conditions: credit rating, credit ceiling, annual dollar sales for the customer in question, then different combinations of these factors can result in different decisions. As the number of conditions and possible combinations increases, the procedure becomes more and more tedious and difficult to write.
    16. 16. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition 1. For each CUSTOMER NUMBER in the data store CUSTOMERS: a. For each LOAN in the data store LOANS that matches the above CUSTOMER NUMBER: 1) Keep a running total of NUMBER OF LOANS for the CUSTOMER NUMBER. 2) Keep a running total of thw ORIGINAL LOAN PRINCIPALfor the CUSTOMER NUMBER. 3) Keep a running total of CURRENT LOAN BALANCE for the CUSTOMER NUMBER. 4) Keep a running total of AMOUNTS PAST DUE for the CUSTOMER NUMBER. b. If the TOTAL AMOUNTS PAST DUE for the CUSTOMER NUMBER is greater than $100.00 then: 1) Write the CUSTOMER NUMBER and all their data attributes as described in the data flow LOANS AT RISK. Else 1) Exclude the CUSTOMER NUMBER and data from the data flow LOANS AT RISK. Structured English 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.
    17. 17. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Structured English Constructs (Part 1)
    18. 18. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Structured English Constructs (Part 2) complex logic in which rows represent conditions
    19. 19. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Structured English Constructs (Part 3)
    20. 20. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition 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).
    21. 21. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition A Simple Decision Table
    22. 22. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition • A data flow represents an input of data to a process, or the output of data from a process. – A data flow may also be used to represent the creation, reading, deletion, or updating of data in a file or database (called a data store). – A composite data flow is a data flow that consists of other data flows. • A control flow represents a condition or nondata event that triggers a process. – Used sparingly on DFDs. Data Flows & Control Flows
    23. 23. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Data Flow Packet Concept
    24. 24. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Composite and Elementary Data Flows
    25. 25. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Data Flows to and from Data Stores
    26. 26. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Illegal Data Flows
    27. 27. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Data Structures Data flows can be defined by data structures. A data structure is a specific arrangement of data attributes that defines the organization of data contained in a data flow. A data attribute is the smallest piece of data that has meaning to the end-users of a business.
    28. 28. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition A Data Structure for a Data Flow DATA STRUCTURE ORDER= ORDER NUMBER + ORDER DATE+ [ PERSONAL CUSTOMER NUMBER, CORPORATE ACCOUNT NUMBER]+ SHIPPING ADDRESS=ADDRESS+ (BILLING ADDRESS=ADDRESS)+ 1 {PRODUCT NUMBER+ PRODUCT DESCRIPTION+ QUANTITY ORDERED+ PRODUCT PRICE+ PRODUCT PRICE SOURCE+ EXTENDED PRICE } N+ SUM OF EXTENDED PRICES+ PREPAID AMOUNT+ (CREDIT CARD NUMBER+EXPIRATION DATE) (QUOTE NUMBER) ADDRESS= (POST OFFICE BOX NUMBER)+ STREET ADDRESS+ CITY+ [STATE, MUNICIPALITY]+ (COUNTRY)+ POSTAL CODE ENGLISH ENTERPRETATION An instance of ORDER consists of: ORDER NUMBER and ORDER DATE and Either PERSONAL CUSTOMER NUMBER or CORPORATE ACCOUNT NUMBER and SHIPPING ADDRESS (which is equivalent to ADDRESS) and optionally: BILLING ADDRESS (which is equivalent to ADDRESS) and one or more instances of: PRODUCT NUMBER and PRODUCT DESCRIPTION and QUANTITY ORDERED and PRODUCT PRICE and PRODUCT PRICE SOURCE and EXTENDED PRICE and SUM OF EXTENDED PRICES and PREPAID AMOUNT and optionally: both CREDIT CARD NUMBER and EXPIRATION DATE An instance of ADDRESS consists of: optionally: POST OFFICE BOX NUMBER and STREET ADDRESS and CITY and Either STATE or MUNICIPALITY and optionally: COUNTRY and POSTAL CODE
    29. 29. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Data Structure Constructs Data Structure Sequence of Attributes - The sequence data structure indicates one or more attributes that may (or must) be included in a data flow. Selection of Attributes - The selection data structure allows you to show situations where different sets of attributes describe different instances of the data flow. 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. Format by Example (relevant portion is boldfaced) WAGE AND TAX STATEMENT= TAXPAYER IDENTIFICATION NUMBER+ TAXPAYER NAME+ TAXPAYER ADDRESS+ WAGES, TIPS, AND COMPENSATION+ FEDERAL TAX WITHHELD+… ORDER= (PERSONAL CUSTOMER NUMBER, CORPORATE ACCOUNT NUMBER)+ ORDER DATE+… CLAIM= POLICY NUMBER+ POLICYHOLDER NAME+ POLICY HOLDER ADDRESS+ 0 {DEPENDENT NAME+ DEPENDENT’S RELATIONSHIP} N+ 1 {EXPENSE DESCRIPTION+ SERVICE PROVIDER+ EXPENSE AMOUNT} N English Interpretation (relevant portion is boldfaced) An instance of WAGE AND TAX STATEMENTS consists of: TAXPAYER IDENTIFICATION NUMBER and TAXPAYER NAME and TAXPAYER ADDRESS and WAGES, TIPS AND COMPENSATION and FEDERAL TAX WITHHELD and… An instance or ORDER consists of: Either PERSONAL CUSTOMER NUMBER or CORPORATE ACCOUNT NUMBER; and ORDER DATE and… An instance of CLAIM consists of: POLICY NUMBER and POLICYHOLDER NAME and POLICYHOLDER ADDRESS and zero or more instance of: DEPENDENT NAME and DEPENDENT’S RELATIONSHIP and one or more instances of: EXPENSE DESCRIPTION and SERVICE PROVIDER and EXPENSE ACCOUNT
    30. 30. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Data Structure Constructs (concluded) Data Structure 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.” 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. Format by Example (relevant portion is boldfaced) CLAIM= POLICY NUMBER+ POLICYHOLDER NAME+ POLICYHOLDER ADDRESS+ ( SPOUSE NAME+ DATE OF BIRTH)+… DATE= MONTH+ DAY+ YEAR+ English Interpretation (relevant portion is boldfaced) An instance of CLAIM consists of: POLICY NUMBER and POLICYHOLDER NAME and POLICYHOLDER ADDRESS and optionally, SPOUSE NAME and DATE OF BIRTH and... 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
    31. 31. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Data Types and Domains Data attributes should be defined by data types and domains. A data type defines what class of data can be stored in an attribute (e.g., character, integers, real numbers, dates, pictures, etc.). A domain defines what values or range of values an attribute can legitimately take on.
    32. 32. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Diverging and Converging Data Flows • A diverging data flow is one that splits into multiple data flows. – Useful for illustrating data that starts out naturally as one flow, but needs to be routed to parallel processes. – Also useful for illustrating multiple copies of the same output going to different destinations. • A converging data flow is the merger of multiple data flows into a single packet. – Useful for illustrating data from multiple sources that must come back together for some subsequent processing
    33. 33. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Diverging and Converging Data Flows
    34. 34. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition External Agent External Agents • An external agent defines a person, organization unit, or other organization that lies outside of the scope of the project but that interacts with the system being studied. – External agents define the “boundary” or scope of a system being modeled. – As scope changes, external agents can become processes, and vice versa. – Almost always one of the following: • Office, department, division inside the business but outside the system scope. • An external organization or agency. • Another business or another information system. • One of your system’s end-users or managers
    35. 35. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Data Store Data Stores • A data store is an inventory of data. – Frequently implemented as a file or database. – A data store is “data at rest” compared to a data flow that is “data in motion.” – Almost always one of the following: • Persons (or groups of persons) • Places • Objects • Events (about which data is captured) • Concepts (about which data is important) – Data stores depicted on a DFD store all instances of data entities (depicted on an ERD)
    36. 36. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition When to Draw Process Models • Strategic systems planning – Enterprise process models illustrate important business functions. • Business process redesign – “As is” process models facilitate critical analysis. – “To be” process models facilitate improvement. • Systems analysis (primary focus of this course) – Model the existing system including its limitations – Model the target system’s logical requirements (meaning processes and data flows needed regardless of how the system will be implemented) – Model candidate technical solutions (physical DFDs only) – Model the target technical solution (physical DFDs only)
    37. 37. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Classical Structured Analysis 1. Draw top-down physical DFDs that represent the current physical implementation of the system including its limitations. 2. Convert the physical DFDs to their logical equivalents. 3. Draw top-down logical DFDs that represent an improved system. 4. Describe all data flows, data stores, policies, and procedures in a data dictionary or encyclopedia. 5. Optionally, mark up copies of the logical DFDs to represent alternative physical solutions. 6. Draw top-down physical DFDs that represent the target solution. THE ABOVE METHODOLOGY IS RARELY PRACTICED ANYMORE BECAUSE IT IS VERY CUMBERSOME AND TIME-CONSUMING.
    38. 38. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Modern Structured Analysis 1. Draw a context DFD to establish initial project scope. 2. Draw a functional decomposition diagram to partition the system into subsystems. 3. Create an event-response or use-case list for the system to define events for which the system must have a response. 4. Draw an event DFD (or event handler) for each event. 5. Merge event DFDs into a system diagram (or, for larger systems, subsystem diagrams). 6. Draw detailed, primitive DFDs for the more complex event handlers. 7. Document data flows and processes in the data dictionary. THE ABOVE METHODOLOGY, BASED ON EVENT PARTITIONING, IS MORE COMMONLY PRACTICED.
    39. 39. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Structured Analysis Diagram Progression (1 of 3)
    40. 40. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Structured Analysis Diagram Progression (2 of 3)
    41. 41. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Structured Analysis Diagram Progression (3 of 3)
    42. 42. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition CASE for DFDs (Sample Screen) from System Architect 2001
    43. 43. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition SoundStage Context DFD Member Services System Potential Member Club Member Marketing Department Warehouse Accounts Receivable Past Member Member Services various Inquiry Reponses various Sales Reports various Promotion Reports Subscription Offer Member Order New Subscription Promotion Subscription Renewal Resubscription Offer various Member Reports various Subscription Reports Subscription Program New Promotion Revised Packing Order Member Credit Status
    44. 44. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition SoundStage Functional Decomposition Diagram Order Subsystem Promotion Subsystem Operations Subsystem Subscription Subsystem Member Services System Process Order Transactions Generate Promotion Reports Process Membership Transactions Process Promotion Transactions Generate Subscription Reports Generate Order Reports Process Marketing Transactions Process Subscription Transactions Process Warehouse Transactions
    45. 45. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Events • Events define processes needed to respond to those events. – External events are those initiated by external agents. They result in an input transaction or data flow. – Temporal events are those that are triggered by the passage of time. They simply “happen” and are indicated by a control flow. – State events are those based on a system’s change from one state to another.
    46. 46. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Use Cases • Use cases are based upon object-oriented concepts that are essentially the same as events. – Use case analysis is the process of identifying and modeling business events and how the system responds to them. – An actor is anything that needs to interact with the system (essentially, a synonym for external agent).
    47. 47. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition membership subscription plan AGREEMENT Logically Delete (void) in the database. Use Case List Actor Event (or Use Case) Trigger Responses Marketing Establishes a new to entice new members. NEW MEMBER SUBSCRIPTION PROGRAM Generate SUBSCRIPTION PLAN CONFIRMATION. Create AGREEMENT in the database. Marketing Establishes a new membership resubscription plan to lure back former members. PAST MEMBER RESUBSCRIPTION PROGRAM Generate SUBSCRIPTION PLAN CONFIRMATION. Create AGREEMENT in the database. Marketing Changes a subscription plan for current members (e.g., extending the fulfillment period) SUBSCRIPTION PLAN CHANGE. Generate AGREEMENT CHANGE CONFIRMATION. Update AGREEMENT in the database. (time) A subscription plan expires. (current date) Generate AGREEMENT CHANGE CONFIRMATION.
    48. 48. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Generate CHANGE CONFIRMATION. Logically Delete (void) AGREEMENT Generate MEMBER DIRECTORY UPDATE CONFIRMATION. Create MEMBER in the database. Create first MEMBER ORDERED PRODUCTs in the database. Generate MEMBER DIRECTORY UPDATE CONFIRMATION. Update MEMBER in the database. Use Case List (continued) Marketing Cancels a subscription plan before its planned expiration CANCELATION in the database. Member Joins the club by subscribing. (“Take any 12 CDs for one penny and agree to buy 4 more at regular prices within two years.”) NEW SUBSCRIPTION MEMBER ORDER Member hanges address (including email and privacy code) CHANGE OF ADDRESS Actor Event (or Use Case) Trigger Responses
    49. 49. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Generate CREDIT DIRECTORY UPDATE CONFIRMATION. Update MEMBER in the database. Generate CONFIRMATION. Logically Delete (deactivate) PRODUCT database. Generate CATALOG DESCRIPTION. Changes member’s credit status 90 days after a Marketing decides to no longer sell a product. Wants to pick products for possible purcase. (Logical requirement is driven by vision of web-based access Use Case List (continued) Accounts Receivable CHANGE OF CREDIT STATUS (time) (current date) CATALOG CHANGE in the Member PRODUCT INQUIRY Actor Event (or Use Case) Trigger Responses
    50. 50. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Event Decomposition Diagram (partial) Member Services System Process Member Change of Preferences Process Former Member Resubscrip- tion Process Subscription Plan Cancelation Process Member Change of Address Process Subscription Plan Expiration Generate Inactive Member Report Process Change to a Subscription Plan Generate Quarterly Subscription Report Process New Member Subscription Process New Resubscrip- tion Plan Generate Membership Directory Generate Subscription Analysis Report Process New Subscription Plan Generate Agreement Compliance Report Promotion Subsystem Order Subsystem Operations Subsystem Subscription Subsystem Process Membership Transactions Process Warehouse Transactions Process Marketing Transactions Generate Subscription Reports Generate Order Reports Process Order Transactions Process Promotion Transactions Process Subscription Transactions Generate Promotion Reports Pg 4 Pg 3 Pg 2
    51. 51. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition External Event DFD Process Member Address Change Club Member Members Member Updated Address Confirmation Updated Member Address Member Change of Address
    52. 52. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition External Event DFD (more complex) Process Member Order Club Member Warehouse Accounts Receivable Products Members Member Ordered Products Member Orders Member Order Confirmation New Member Ordered Products New Member Order Inventory Commitment Product and Availability Relevant Transactions Updated Member from Order Member Packing Order Member Order
    53. 53. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Temporal Event DFD Identify Agree- ments Near Default Calendar Agreements Manager AgreementsMembers AgreementFulfillment Progress Agreement Default Exception ReportEnd of Month
    54. 54. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition System DFD (see book for more readable copy) Generate Order Analysis Report Process Member Order Cancelation Process Member Order Revision Process Subscription Order Process Member Order Club Directors TimeWarehouse Warehouse Member Member Member Member Ordered Products Products Transactions Products Member Orders Member Orders Members Members Inventory Commitment Product and Availability Address New Member Order New Member Ordered Products Member Order Cancelation Notice Updated Member Deleted Member Order Deleted Member Ordered Products Order Analysis Report End of Day Orders Ordered Products Packing Order Packing Order Member Order Confirmation Inventory Commitment Product and Availability Updated Member from Updated Order Updated Member Ordered Products Updated Member Order Member New Member Ordered Products Relevant Transactions Inventory Commitmen t Product and Availability New Member Order Updated Member from Order Member Subscription Order Confirmation Member Order Confirmation Revised Packing Order Member Order Cancelation Member Order Change Request Subscription Order Member Order
    55. 55. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Primitive DFD (see book for more readable copy) Record Order Release Order Check Member Credit Calculate Order Cost Check Product Availability Validate Ordered Product Validate Member Warehouse Member Member Ordered Products Members Products Members Transactions Member Orders Order to be Filled Updated Credits Confirmed Member Order Packing Order Order to be Filled Credit Details Credit Problem and Instruction Product Price Invalid Order Invalid Member ID Invalid Product ID Inventory Comittment Product Availability Product Updated Member from Order Member Cost to Member Available Product Valid Product Bonus Credits Claimed Ordered Product ID Payment Ordered Product Quantity Member ID and Address Member Order Relevant Transactions New Member Ordered Products New Member Order
    56. 56. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Data Structure for a Primitive Data Flow Data Structure Data Flow
    57. 57. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition Logic for a Primitive Process Logic Process
    58. 58. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition 8.30 Data to Process CRUD Matrix
    59. 59. Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition 8.31 Process to Location Association Matrix

    ×