Data and Process Modeling PHASE 2: SYSTEMS ANALYSIS Chapter 4 Data and Process Modeling

Chapter Objectives Describe data and process modeling concepts and tools, including data flow diagrams, a data dictionary, and process descriptions Describe the symbols used in data flow diagrams and explain the rules for their use Draw data flow diagrams in a sequence, from general to specific Explain how to level and balance a set of data flow diagrams 3

Chapter Objectives Describe how a data dictionary is used and what it contains Use process description tools, including structured English, decision tables, and decision trees Describe the relationship between logical and physical models 3

Introduction In Chapter 4, we will use data and process modeling techniques … To develop a logical model of the proposed system Logical model  WHAT system must do Physical model  HOW system will be constructed (later in systems design phase) To document system requirements A logical model could specify output as a list of data, without committing to a specific format. A physical model would include details about the format. 4

Overview Data and Process Modeling Tools Systems analysts use many graphical techniques to describe an information system A data flow diagram (DFD) uses various symbols to show how the system transforms input data into useful information Data Flow Diagram A DFD shows inputs, processes, storage, and outputs of a system

Data Flow Diagrams A data flow diagram (DFD) shows how data moves through an information system but does not show program logic or processing steps A set of DFDs provides a logical model that shows what the system does, not how it does it

Data Flow Diagrams DFD Symbols DFDs use four basic symbols that represent processes, data flows, data stores, and entities Gane and Sarson symbol set Yourdon symbol set With minimal training DFDs can be read and interpreted by many different workers - both end users, and management, making them a valuable tool for communication.

Data Flow Diagrams DFD Symbols PROCESS symbol Receives input data and produces output that has a different content, form, or both Contains the business logic  business rules Referred to as a black box Process: A process can be a procedure or an algorithm. Processes can be simple or complex. Keep in mind that processing details are not shown in a DFD. Black Box: Because inputs, outputs, and general functions of process are known but underlying details and logic of process are hidden. Don’t know the internal operations.

Data Flow Diagrams DFD Symbols DATA FLOW symbol Represents one or more data items The symbol is a line with a single or double arrowhead Fork  same data Data Flow: Data flows represent data movement among processes, data stores, and external entities. Fork  same data go from a common location to two or more processes, data stores or entities

Data Flow Diagrams DFD Symbols Basic rules for all PROCESSES and DATA FLOWS At least 1 data flow must enter and 1 data flow must exit each process AVOID: Spontaneous generation Has no input Black hole Produces no output Gray hole Input insufficient to generate output No process can have only outputs Something must go in or a miracle has occurred No process can have only inputs This should not happen lest we call this the “black hole”

Data Flow Diagrams DFD Symbols DATA STORE symbol Represent data that the system stores Physical characteristics of data store are unimportant Concerned only with logical model Data Store: Stores  file, database server, web server, file server A DFD does not show detailed contents of a data store.

Data Flow Diagrams DFD Symbols Basic rules for all DATA STORES Data cannot be moved from one store to another Data cannot move from an outside source to a data store Data cannot move directly from a data store to a data sink 1) Data cannot be moved from one store to another Example: In 4-23, pg. 166, Data cannot go from the Master Schedule database to the Orders database without some type of process in between. 2) Data cannot move from an outside source to a data store Example: Same example. A Customer‘s order information does not enter directly to the Orders database without some processing (Order System) in between. 3) Data cannot move directly from a data store to a data sink Example: Same example. Reordered parts do not go directly from the Parts database to the Suppler entity without some processing (Purchasing System) in between.

Data Flow Diagrams DFD Symbols ENTITY Symbol Symbol is a rectangle Depicts origin and/or destination of data Sometimes referred to as external entity Name of the entity appears inside the symbol AKA: Terminators  final destination Source  supplies data Sink  receives data Entity: A person, place, thing, or event for which data is collected and maintained. An external entity is outside the system boundary but supplies input or accepts output. A DFD shows the boundaries of a system and how it interfaces with the outside world. Terminators – data origins or final destinations. Source – Entity that supplies data to the system Sink – Entity that receives data from the system

Data Flow Diagrams DFD Symbols Basic rules for all ENTITIES (i.e. sources/sinks) Entity must be connected to a process by a data flow and not directly to a data store Data cannot move directly from a source to a sink Entity must be connected to a process by a data flow and not directly to a data store  The data must be processed in between before going to the database. Data cannot move directly from a source to a sink  Otherwise what was the purpose of the system in the first place.

Data Flow Diagrams Basic rules for connecting processes, data stores, and entities in a DFD

Creating a Set of DFDs Create a graphical model of the information system based on your fact-finding results Performing three main tasks Step 1: Draw a context diagram Step 2: Draw a diagram 0 DFD Step 3: Draw the lower-level diagrams Step 1: Draw a context diagram Highest level – scope of system Step 2: Draw a diagram 0 DFD More detail – breaks down system into detail Step 3: Draw the lower-level diagrams  Greater detail – break each module into its lowest level of detail until no more detail is necessary

Creating a Set of DFDs Draw a Context Diagram Process 0 represents system Context diagram The most abstract, least detailed, model. It shows the system’s boundaries and scope Symbolizes all processing activity within a system with a single process symbol. Data stores are not shown. Mention how to determine which entities and data flows are shown in a context diagram.

Creating a Set of DFDs Draw a Context Diagram Context Drawing Guidelines (Page 156, Figure 4-13) Fit on one page Name of information system  Process name Use unique names within each set of symbols Do not cross lines Obtain user input and feedback

Creating a Set of DFDs Context Diagram Refer to Figure 4-13 on page 156 of textbook What is the name of the system in this Context Diagram? How many sources of data are there? What are they? Which entities (sinks) do not supply inputs to the Order System? What data is going into the Order System from Customer? What data is going to the Warehouse from the Order System? Name Order system 2 sources of data  Customer and Warehouse Sinks only  Sales Rep, Bank, Accounting From Customer  Payment, Order To Warehouse  Picking List

Creating a Set of DFDs Draw a Level-0 DFD Diagram Draw a Level-0 Diagram This is the expanded view (or child diagram) of the Order System. The Order Context Diagram has been decomposed to show… 3 processes: Fill Order, Create Invoice, Apply Payment 1 data store: Accounts Receivable 2 new data flows: Invoice Detail and Payment Detail 1 diverging data flow: Invoice

Creating a Set of DFDs Draw a Level-0 DFD Diagram Level-0 DFD Drawing Guidelines (p. 161, Figure 4-16) Decomposition of Context diagram Parent/Child diagram KEEP all data flows into and out of process 0 KEEP all entities Functional primitive Diverging data flow – different locations Decomposition: Decompose a diagram to show what lies beneath. Here we show the major processes, data flows, and data stores within the main system Each process has a reference number. Reference numbers are important because we can then break each Level-0 process down further into a Level 1 diagram Parent/Child: We exploded, or decomposed, the Context diagram (Process 0). The higher level is called the Parent diagram. The lower level is called the Child diagram. Which one is the Parent here? Context. Which is the child? Level-0. Keep all data flows: (Balancing) All data flows going into/coming out of Context diagram must be on Level-0 diagram. Keep all entities: (Balancing) All entities that appeared on the Context must appear on the Level-0 diagram. Functional Primitive: A process that has been broken down into its smallest unit, a single function that cannot be broken down further. At this point it can be handed off to the programmer to use to develop code. Diverging data flow Same data travels to two or more different locations. In this situation, a diverging data flow is the best way to show the flow rather than showing two identical data flows – misleading.

Creating a Set of DFDs Draw Lower Level 1-n DFD Diagrams Level 1-N Diagrams

Creating a Set of DFDs Draw Lower Level 1-n DFD Diagrams Level 1-n DFD Drawing Guidelines Leveling Balancing Leveling: Keep decomposing the DFDs until all functional primitives are identified. i.e. Until you get to the lowest level necessary to describe the function. Balancing: Maintains consistency among DFDs by ensuring that the input and output data flows of the parent DFD are drawn on the child DFD.

Creating a Set of DFDs Draw a Level-0 DFD Diagram Draw a Level-0 Diagram Ci1 Wo Co C2 Wi This is the expanded view (or child diagram) of the Order System. The Order Context Diagram has been decomposed to show… 3 processes: Fill Order, Create Invoice, Apply Payment 1 data store: Accounts Receivable 2 new data flows: Invoice Detail and Payment Detail 1 diverging data flow: Invoice Ci2 Ao So Bo

Creating a Set of DFDs Draw Lower Level 1-n DFD Diagrams Level 1-N Diagrams Co Ci1 Wo

Data Dictionary Central Storehouse (aka Data Repository) Facts about system Data elements (aka Field) Record (aka Data Structures) Facts about system: Contents of data flows, data stores, entities, and processes Data Elements: Defines and describes fields. Like student name, social security number. Record: Data elements are combined into records, also called data structures. A record is a combination of related data elements that is included in a data flow or retained in a data store. For example: A Student demographic record might include student id, name, address, city, state, zip.

Data Dictionary Documenting the Data Elements Objective: Provide clear, comprehensive information about the data and processes that make up the system

Data Dictionary Documenting the Data Elements The following attributes are recorded and described: Data element name or label Alias Type and length Default value Acceptable values - Domain and validity rules Name of data element, meaningful to users Alias – Alternate name users may refer to it. Instead of Current Balance  Amount Owed Type/Length – numeric, alpha, character and max # of characters if alpha, max # of digits & # of decimals if numeric. Default value – If value is not entered, amount to be entered. i.e. date Acceptable values – Domain: set of values permitted for data element  list or use a lookup table, i.e. Tax Code based on Adjusted Gross Income lookup table Validity Rules: Does entered value make sense? Salary is within range for job classification.

Data Dictionary Documenting the Data Elements The following attributes are recorded and described: Source Security Responsible user(s) Description and comments Source: The origination point for the data element’s values. Did it come from a form, a department, outside organization, another system, or the result of a calculation. i.e. Perhaps you obtain an employee’s review code for a non-HR system from an HR system. The source would be another system – specifically the HR system. Security: Who has access or update privileges – at the data element level. Some workers may have read-only while the manager may be able to update. Responsible users: Those responsible for maintaining the data element. Description and comments: Notes

Data Dictionary Documenting the Data Flows Typical attributes of data flows: Data flow name or label Description Alternate name(s) Origin Destination Record Volume and frequency Origin: The DFD beginning, or source, for the data flow; can be a process, a data store, or an entity. Where is it coming from? Destination: The DFD ending point(s) for the data flow; can be a process, data store, or entity. Where is it going to? Record: Each data flow represents a group of related data elements (or a record). In data dictionaries, records are defined separately from the data flow and stores. When records are defined, more than one data flow or data store can use the same record, if necessary. Volume and Frequency: Expected # of occurrences for the data flow per unit of time. Example: If company has 300 hourly employees  Time Card dataflow would have 300 transactions and records each week when they punch their time card.

Data Dictionary Documenting the Data Stores Typical attributes of a data store: Data store name or label Description Alternate name(s) Attributes Volume and frequency Attributes: DFD data flow names that enter or leave the data store. These names are standardized throughout the data dictionary for consistency purposes. Volume and frequency: Estimated number of records in the data store and how frequently they are updated. This is important because they will affect design decisions in subsequent SDLC phases.

Data Dictionary Documenting the Processes Typical attributes of a process: Process name or label Description Process number Process description Description vs. Process Description: Description is a brief statement of the process’s purpose. Process description includes the input and output data flows. For functional primitives, this description should also document the processing steps and business logic.

Data Dictionary Documenting the Entities Typical attributes of an entity: Entity name Description Alternate name(s) Input data flows Output data flows Input data flows: Flows going to the entity. Output data flows: Flows leaving the entity.

Data Dictionary Documenting the Records Typical attributes of a record: Record or data structure name Definition or description Alternate name(s) Attributes Record name: As it appears in the related data flow and data store entries in the data dictionary. Attributes: A list of all the data elements included in the record. The data element names must match exactly what was entered in the data dictionary.

Data Dictionary Data Dictionary Reports Many valuable reports may be obtained Data Element report Data Flows/Stores report Detailed reports Data Element Report: A report describing each data element and indicating the user or department that is responsible for data entry, updating, or deletion An alphabetized list of all data elements by name Data Flow/Store Report: A report of all data flows and data stores that use a particular data element Detailed Reports: Detailed reports showing all characteristics of data elements, records, data flows, processes, or any other selected item stored in the data dictionary

Process Description Tools A process description documents the details of a functional primitive AND represents a specific set of processing steps and business logic When you analyze a functional primitive, you break the processing steps down into smaller units in a process called modular design.

Process Description Tools Modular Design Based on the combination of 3 logical structures Sequence Selection Iteration - looping 3 logical structures: These are building blocks for the process/program. Sequence: Complete steps one after another. In a program, once a record is read in and verified, a number of sequential steps are done. Page 173, Figure 4-33. Selection: Here you have to make a decision. This would be like an IF statement. If this then this path, else the other path. Iteration: This is like a Do…While or Do…Until statement. Also Looping. You have an iteration of a process until some condition has been satisfied.

Process Description Tools Typical process tools include: Structured English Decision Tables Decision Trees

Process Description Tools Structured English Purpose: Describe underlying business logic Structured English Rules Use 3 building blocks Sequence, Selection, Iteration Use indentation for readability Use limited vocabulary Standard terms used in data dictionary Specific words that describe the processing rules

Process Description Tools Structured English (Pg. 174, Figure 4-37) Might look familiar because it resembles pseudocode

Process Description Tools Decision Tables Logical structure  All combinations of conditions Resulting actions VERIFY ORDER Process Conditions Combo of Y/N for condition – 4 diff. rules or combos X to accept or reject order given the rule 1 2 3

Process Description Tools Decision Tables Can have > 3 possible outcomes Best way to describe complex set of conditions Sales Promotion Policy

Process Description Tools Decision Trees Graph of conditions, actions, rules in decision table Personal preference  Decision table or tree

Logical Versus Physical Models Four-Model Approach What analysts can do … 1st Create a physical model of current system 2nd Develop a logical model of current system 3rd Develop a logical model of new system 4th Develop a physical model of new system Disadvantage: Added time and cost

Chapter Summary During data and process modeling, a systems analyst develops graphical models to show how the system transforms data into useful information The end product of data and process modeling is a logical model that will support business operations and meet user needs Data and process modeling involves three main tools: data flow diagrams, a data dictionary, and process descriptions Data flow diagrams (DFDs) graphically show the movement and transformation of data in the information system DFDs use four symbols 49

Chapter Summary Any questions? A set of DFDs is like a pyramid with the context diagram at the top The data dictionary is the central documentation tool for structured analysis Each functional primitive process is documented using structured English, decision tables, and decision trees Structured analysis tools can be used to develop a logical model during one systems analysis phase, and a physical model during the systems design phase Any questions? 49