SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition

Скачать презентацию SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition

a084caf0e2896339903f506647bce191.ppt

Количество слайдов: 70

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Chapter Eight Whitten Bentley Dittman Process Modeling • Define systems modeling and differentiate between logical and physical system models (again). • Define process modeling and explain its benefits. • Recognize and understand the basic concepts and constructs of a process model. • Read and interpret a data flow diagram. • Construct a context diagram to illustrate a system’s interfaces with its work environment. • Identify use cases, external and temporal business events for a system. • 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. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Models: Logical and Physical A model is a representation of reality. Just as a picture is worth a thousand words, most models are pictorial representations of reality. 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 (Sometimes called ‘conceptual choices. (Sometimes called ‘technical’ or or essential model) ‘implementation’) Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman “Logical” • 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 – Contrary to the systems analysis expectation that a logical model is technology-independent. • Again, 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. • Given that one logical model, there are multiple candidate physical models that could represent alternative, technical implementations that could fulfill the business requirements Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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 endusers in nontechnical or less technical languages. • Here, we will focus on logical process modeling… Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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. • The ‘context diagram’ (level-0 DFD) shows the interface from the perspective of the system owners and users. • While data models can be captured by reverse engineering data base schema, the similar process of doing so ‘for process’ is not so mature. Other kinds of process models: • structure charts (hierarchy charts) (functional decomposition) • program flow charts (logic flowcharts) • decision tables (decision logic tables – DLTs) • data flow diagrams (DFDs) – a systems analysis process model. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Process Modeling and DFDs 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 (BPR). Planning for DFDs, use a planning tool: decomposition diagrams. Will also look at context diagrams – illustrates the system interfaces to business, and the outside world. Let’s consider a sample DFD: Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Simple Data Flow Diagram Very easy to read. Try to read it…. Three symbols and one connection Symbols: Rounded Rectangle – a ‘process’or work to be done. The Square – for external entities. . are considered on the boundary but outside the system. The Data Store – can correspond to all instances of a single entity in a data model; file or database. Flow lines – data flows – inputs and/or outputs to/from processes. Walk through it…. . Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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 and other considerations…. – Processes on flowcharts are part of a single program with consistent timing Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Systems Thinking “Systems Thinking” is the application of formal systems theory and concepts to systems problem solving. Systems theory and concepts help us to understand the way systems are organized and how they are used… DFDs are a tool that supports systems thinking. Problems in college are much smaller and simpler than those encoutered in the real world. Systems thinking is a technique that will pay off as problem size and complexity grow…. Used throughout this course…. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Process Concepts The most fundamental building block is a Process. All information systems have processes that represent business needs that transform data into useful information. A process is work performed on, or in response to, incoming data flows or conditions. In logical modeling, we focus on ‘what’ work/action is being done and not on who/what is doing the actual work. A System is a Process Entity Like my level 0 DFD Feedback and control is included I added the “entity” to the to monitor the system and adapt book’s drawing…. Entities are producers/consumers/triggers to change. of system’s data / information facilities Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved Irwin/Mc. Graw-Hill

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Decomposition is the act of breaking a system into its component subsystems, processes, and sub-processes. Each level of abstraction becomes more concrete and less abstract; Going down the hierarchy, we find less and less ‘control’ and more ‘computation. ’ System Decomposition Here is one way to show levels of abstraction (decomposition) Sometimes this is called, ‘functional decomposition’ or ‘stepwise refinement. ’ In program design, this is your architectural design (your building blocks). Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Decomposition Diagrams Drawn in a more familiar style: (really the same thing) A decomposition diagram or hierarchy chart shows the topdown, functional decomposition of a system. No arrows – show structure and not flow; connections not named: ‘consists of. ’ Sum of child processes = parent process. In Cobol, I had students number these modules: 0000 -main, 1000 -Initialization, 2000 -xxxx, 3000 -yyyy and then break down ‘each of those abstractions’ into 2100 -xxxx, 2200 -xxxx, etc. where xxxx is a meaningful descriptor. ‘parent’ and ‘child’ processes Parents have >= two children Child has at most one parent. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Types of Logical Processes (Processes that must be done. ) • A function is set of related and ongoing activities of a business. – – No start or end. Named as nouns (at high levels) Given identified inputs, the processes produce indicated outputs. Often major subsystems or business components, such as Order Entry, Subscription Handling, Customer Relations… • Now, at ‘high levels’ of DFDs, we can see specific inputs being fed into these major ‘functions. ’ (These major functions are normally shown as a level 1 DFD…) In reality, these major functions have events that constitute the detailed functions. So, when we see inputs going into a high level function (and outputs produced), in reality, the inputs will be handled by an ‘event handler’ of the function and output will be produced by an ‘event handler’ of the function – and shown in a lower level. – (Implementation of Use Cases is really design and implementation of event handlers…) Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Example: (my example) input 1 1 Major Fct output 1 input 2 typically a ‘verb object’, as in Test Material Qty, Order New Materials Return Unused Junk… is decomposed to: input 1 Event 1. 1 input 2 Event 1. 2 another input some intermediate output Event 1. 3 output 1 Data Flows are preserved!! Irwin/Mc. Graw-Hill But ALL of these events comprise the major function of 1 (or 1. 0) Often see this transactionlevel DFD at a level 2 or 3…) Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Continuing…logical processes – second type • Second logical process: an event (or transaction) is a logical unit of work that must be completed as a whole (as part of a function). (Think: path through a Use Case) – Specific input(s) initiate an event and the event continues until it produces the appropriate outputs. Events are often called ‘transactions’ in the DFD world (not in the Use Case world: called scenarios. (Will see a lot of these. ) These events are often called ‘business events’ also. – As seen, these ‘events’ are normally verb-object and are of the form: Generate xxxxx or Process xxxxxx or Produce ZZZZZ or Maintain YYYYY. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Continuing…logical processes – third type • A Event Process can also be decomposed into an elementary process that provides the very low level detail about how the system will respond to an event. These are called Elementary Processes. • 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. (We are breaking down the Event Process…) • Very strong action word; object clauses…Validate Customer –ID, Perform Computations, Sort Stuff, …. • Not concerned with boring data movement or events that do not change the data. Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved Irwin/Mc. Graw-Hill

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Common Process Errors on DFDs Common Errors: Black hole (3. 1. 2) Processes that have only outputs and no inputs (3. 1. 3) Grey hole – inputs insufficient to produce the outputs. (3. 1. 1) Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Detailed Process Logic – Capturing the Software Procedure. • DFDs and Structure Charts provide much information regarding data flow and functional decomposition (used for architectural design…). – Don’t not show software procedure in those functions. • Specifically, we need to model the algorithms. • Your author poo-poos program flow charts, pseudo code, and natural English. (I disagree) They advocate Structured English approach… • Let’s see what they have to say. • First they poo-poo Natural Language (I agree). Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Problems with Natural English PROBLEMS WITH NATURAL ENGLISH 1 • 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. Irwin/Mc. Graw-Hill Source: Adapted from Matthies, Leslie, The New Playscript Procedure, (Stamford, Companies. All Rights reserved Copyright © 2000 The Mc. Graw-Hill CT: Office Publications, Inc. 1977)

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Detailed Processing Logic - 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. Still very high level and shows some algorithmic detail…. Notice the STRUCTURE… 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 the ORIGINAL LOAN PRINCIPAL for 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. I can live with the authors’ version of Structured English – if the numbers are tied to the modules or processes in the Structure Chart and/or DFD. It does marry some of the constructs of structured programming, indentation, and natural language. Still uses sequence, selection, and iteration. OK Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Structured English Constructs (Part 1) Useful for simplifying very complex combinations of conditions. Replace complex, nested if-then-else selection structures… Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman More on Structured English Be sure to read these couple of pages carefully!!!! Note the ‘restrictions’ on Structured English like only names that have been defined in the project dictionary may be used. I would strictly adhere to the use of scope terminators Figures 8 -7 – 8 -9. Please note: This is the ‘detailed design’ I have been speaking about. I referred to it as ‘software procedure. ’ IT is. And ways you document this is by program flowcharts, pseudocode, natural English, and (your authors’ preference Structured English. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Structured English Constructs (Part 2) Here is a decision table. (Another example is found in your COBOL textbook) complex logic in which rows represent conditions Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Structured English Constructs (Part 3) Know the difference between the Repeat … Until (will always do at least one time – prior to test… And the Do…While – do while something is true… These are great constructs for pseudocode…that is, detailed algorithmic logic. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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). Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Data Flows & Control Flows • 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). (CRUD) – All processes have at least one input and one output data flow. • A composite data flow is a data flow that consists of other data flows. Usually seen on high-level DFDs to make the diagrams easier to read – See slides ahead… • A control flow represents a condition or nondata event that triggers a process. (more later – on CFDs) – Used sparingly on DFDs. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Data Flow Packet Concept Packets represent data items that must be kept together. Treat these as a single unit – especially at higher levels of abstraction. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Composite and Elementary Data Flows Note the composition of data flow all in Order Note: high-level DFD. Can clearly see the decomposition of the flows into separate named flows. Note the ‘junction. ’ Means an order is only of one type. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Control Flows • Some texts in Software Development address “Control Flows. ” – As suggested, a control flow acts like a trigger. – Not used much in Information Systems – Used a lot in computer science/computer engineering • Triggering devices are very important to document as part of the requirements analysis activities. • Often documented in State Transition Diagrams (STDs) vice Control Flow Diagrams (CFDs). • In OOA/OOD we use Event Traces and Event Flows and Action Diagrams – A nice plus re: DFDs is, however, that this tool ‘can’ be used for documented almost any kind of system! Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Data Flows to and from Data Stores Note: That data flows not ‘how’ it flows. Note: Should be singular, descriptive nouns. Note: Data Store names are ‘plural’ and actions to/from a store are normally not indicated. All data flows must begin and end at a process. All data flows must be named. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman • Some DFD methodologies suggest that data flows to and from data stores not be named. – Confuses the end-users when they try to read the diagrams. – Name your data. Keep this as a consistent approach. • Some DFD notations actually use the CRUD letters only to name flows to and from data stores. – Popular approach. – CRUD: 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. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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. (better than using ‘field’) Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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 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 Irwin/Mc. Graw-Hill 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 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 Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Data Structure Constructs Data Structure Format by Example (relevant portion is boldfaced) English Interpretation (relevant portion is boldfaced) Sequence of Attributes - The WAGE AND TAX STATEMENT= An instance of WAGE AND TAX STATEMENTS sequence data structure indicates one TAXPAYER IDENTIFICATION NUMBER+ consists of: or more attributes that may (or must) TAXPAYER NAME+ TAXPAYER IDENTIFICATION NUMBER and be included in a data flow. TAXPAYER ADDRESS+ TAXPAYER NAME and WAGES, TIPS, AND COMPENSATION+ TAXPAYER ADDRESS and FEDERAL TAX WITHHELD+… WAGES, TIPS AND COMPENSATION and FEDERAL TAX WITHHELD and… Selection of Attributes - The ORDER= selection data structure allows you to (PERSONAL CUSTOMER NUMBER, show situations where different sets CORPORATE ACCOUNT NUMBER)+ of attributes describe different ORDER DATE+… instances of the data flow. An instance or ORDER consists of: Either PERSONAL CUSTOMER NUMBER or CORPORATE ACCOUNT NUMBER; and ORDER DATE and… Repetition of Attributes - The CLAIM= An instance of CLAIM consists of: repetition data structure is used to set POLICY NUMBER+ POLICY NUMBER and off a data attribute or group of data POLICYHOLDER NAME+ POLICYHOLDER NAME and attributes that may (or must) repeat POLICY HOLDER ADDRESS+ POLICYHOLDER ADDRESS and themselves a specific number of time 0 {DEPENDENT NAME+ zero or more instance of: for a single instance of the data flow. DEPENDENT’S RELATIONSHIP} N+ DEPENDENT NAME and The minimum number of 1 {EXPENSE DESCRIPTION+ DEPENDENT’S RELATIONSHIP and repetitions is usually zero or one. SERVICE PROVIDER+ one or more instances of: The maximum number of EXPENSE AMOUNT} N EXPENSE DESCRIPTION and repetitions may be specified as “n” SERVICE PROVIDER and meaning “many” where the actual EXPENSE ACCOUNT number of instances varies for each instance ofsame basic structures (sequence, selection, iteration) are applied to procedures Note: the data flow. using Structured English are applied here to describe data structures… Have NEVER founds any form or file structure that could not be described in this notation. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Data Structure Constructs (concluded) Data Structure Format by Example (relevant portion is boldfaced) English Interpretation (relevant portion is boldfaced) Optional Attributes - The optional CLAIM= notation indicates that an attribute, or POLICY NUMBER+ group of attributes in a sequence or POLICYHOLDER NAME+ selection date structure may not be POLICYHOLDER ADDRESS+ included in all instances of a data ( SPOUSE NAME+ flow. DATE OF BIRTH)+… Note: For the repetition data structure, a minimum of “zero” is the same as making the entire repeating group “optional. ” An instance of CLAIM consists of: POLICY NUMBER and POLICYHOLDER NAME and POLICYHOLDER ADDRESS and optionally, SPOUSE NAME and DATE OF BIRTH and. . . Reusable Attributes - For groups of DATE= attributes that are contained in many MONTH+ data flows, it is desirable to create a DAY+ separate data structure that can be YEAR+ reused in other data structures. 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 Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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 Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Diverging and Converging Data Flows Not always supported by CASE tools… Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman External Agents / External Entity / Actor (from OO world…) • 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 • (not same as entity in database world…) Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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, Concepts, … – Data stores depicted on a DFD store all instances of data entities (depicted on an ERD) – Prefer the simplicity of representing each data entity from the data model as its own data store on process models. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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) Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman • Differences between original structured analysis and contemporary structured analysis -shown on the next slide). • This approach to systems analysis is rarely practiced and is no longer recommended even by its original evangelists, Tom De. Marco and Ed Yourdon. • Yourdon officially updated the methodology based on the seminal work, Essential Systems Analysis, by Mc. Menamin and Palmer. • The revised approach is shown on the next slide. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman • Although this process may not be as familiar to some as the top-down, fully leveled, classical “physicallogical-physical” approach in the 1976 De. Marco methodology, this is the more contemporary approach. • The original approach is rarely, if ever, practiced because it is so labor intensive and time consuming. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Structured Analysis Diagram Progression Irwin/Mc. Graw-Hill (1 of 3) Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Structured Analysis Diagram Progression Irwin/Mc. Graw-Hill (2 of 3) Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Structured Analysis Diagram Progression Irwin/Mc. Graw-Hill (3 of 3) Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman CASE for DFDs (Sample Screen) Irwin/Mc. Graw-Hill from System Architect 2001 Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Sound. Stage Context DFD A context DFD does not have to show every net data flow. For most systems, this 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). Promotion Club Member Order Potential Member various Inquiry Reponses New Subscription Offer Accounts Receivable Member Credit Status Warehouse Member Services System Revised Packing Order New Promotion Subscription Program various Sales Reports Subscription Renewal various Promotion Reports Past Member Irwin/Mc. Graw-Hill various Subscription Reports Resubscription Offer various Member Reports Marketing Department Member Services Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Sound. Stage Functional Decomposition Diagram Member Services System Subscription Subsystem Promotion Subsystem Order Subsystem Operations Subsystem Process Subscription Transactions Process Promotion Transactions Process Order Transactions Process Membership Transactions Generate Subscription Reports Generate Promotion Reports Generate Order Reports Process Marketing Transactions Process Warehouse Transactions Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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. • Events are very similar to Use Cases in OO Design. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 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). • Use Cases are very similar to Yourdan’s eventresponse structured analysis paradigm in the past… Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Use Case List Actor Event (or Use Case) Trigger Responses Marketing Establishes a new membership subscription plan 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 A subscription plan expires. (current date) (time) CHANGE CONFIRMATION. Update AGREEMENT in the database. Generate AGREEMENT CHANGE CONFIRMATION. Logically Delete (void) AGREEMENT in the database. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Use Case List (continued) Actor Event (or Use Case) Marketing Cancels a subscription plan before its planned expiration Trigger Responses Generate CANCELATION CHANGE CONFIRMATION. Logically Delete (void) AGREEMENT 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 Generate MEMBER DIRECTORY UPDATE CONFIRMATION. Create MEMBER in the database. Create first MEMBER ORDERED PRODUCTs in the database. Member hanges address (including email and privacy code) CHANGE OF ADDRESS Generate MEMBER DIRECTORY UPDATE CONFIRMATION. Update MEMBER in the database. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Use Case List (continued) Actor Event (or Use Case) Trigger Responses Accounts Receivable Changes member’s credit status CHANGE OF CREDIT STATUS Generate CREDIT DIRECTORY UPDATE CONFIRMATION. Update MEMBER in the database. (time) 90 days after a Marketing decides to no longer sell a product. (current date) Generate CATALOG CHANGE CONFIRMATION. Logically Delete (deactivate) PRODUCT in the database. Member Wants to pick products for possible purcase. (Logical requirement is driven by vision of web-based access PRODUCT INQUIRY Generate CATALOG DESCRIPTION. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Event Decomposition Diagram (partial) Member Services System Subscription Subsystem Process Subscription Transactions Generate Subscription Reports Promotion Subsystem Process Promotion Transactions Generate Promotion Reports Order Subsystem Process Order Transactions Generate Order Reports Process Membership Transactions Pg 3 Pg 2 Process Marketing Transactions Process Warehouse Transactions Pg 4 Generate Quarterly Subscription Report Process New Subscription Plan Operations Subsystem Generate Inactive Member Report Generate Agreement Compliance Report Generate Membership Directory Generate Subscription Analysis Report Process New Resubscription Plan Process Change to a Subscription Plan Process Subscription Plan Expiration Process Subscription Plan Cancelation Process New Member Subscription Irwin/Mc. Graw-Hill Process Former Member Resubscription Process Member Change of Address Process Member Change of Preferences Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman External Event DFD (more complex) Members Updated Member from Order Accounts Receivable Relevant Transactions Member Club Member Order Process Member Order Confirmation Member Orders Member Ordered Products Irwin/Mc. Graw-Hill New Member Ordered Products Warehouse Packing Order Inventory Commitment Product and Availability Products Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Temporal Event DFD Agreements Members Fulfillment Progress Calendar End of Month Irwin/Mc. Graw-Hill Agreement Identify Agreements Near Default Agreement Default Exception Report Agreements Manager Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition System DFD Whitten Bentley Dittman (see book for more readable copy) Most DFDs won’t 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. Transactions Product and Availability Products Product and Availability Relevant Transactions Member Order Process Member Order Inventory Commitment Inventory Commitmen t Member Subscription Order Warehouse Packing Order Process Subscription Order Packing Order Member Order Confirmation Subscription Order Confirmation New Member Ordered Products Member Updated Member from Order Members New Member Ordered Products Address New Member Order Members Member Ordered Products Member Orders Deleted Member Orders Updated Member Order Updated Member from Updated Order Member Order Change Request Deleted Member Ordered Products Member Order Confirmation Product and Availability Process Member Order Revision Generate Order Analysis Report Process Member Order Cancelation Updated Member Ordered Products Member Order Cancelation Notice End of Day Inventory Commitment Revised Packing Order Warehouse Time Order Analysis Report Club Directors Products Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Primitive DFD (see book for more readable copy) Important to recognize that NOT all events require a primitive DFD Invalid Order to be drawn. This is especially true for the most report. Member writing and inquiry response event processes. Drawing detailed DFDs for such processes is usually little more than “busy work. ” Member Validate Members Updated Member from Order Invalid Member ID Invalid Product ID Ordered Product ID Validate Ordered Product Valid Product Ordered Product Quantity Member Order Check Product Availability Products Product Availability Inventory Comittment Available Product Bonus Credits Claimed Product Price Calculate Order Cost to Member Payment Credit Problem and Instruction Relevant Transactions Order to be Filled Member Orders Members Credit Details Check Member Credit Confirmed Member Ordered Products Irwin/Mc. Graw-Hill Member ID and Address New Member Ordered Products Transactions Order to be Filled Record Order Release Order Packing Order Warehouse Updated Credits Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Data Structure for a Primitive Data Flow Data Structure 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. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman Logic for a Primitive Process Logic 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. Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 5 th Edition Whitten Bentley Dittman 8. 31 Process to Location Association Matrix Irwin/Mc. Graw-Hill Copyright © 2000 The Mc. Graw-Hill Companies. All Rights reserved