IS 421 Information Systems Analysis James Nowotarski 21 October 2002

Finish coverage of data modeling Understand rules and elements of data flow diagrams Understand the process for creating data flow diagrams Create simple data flow diagrams Today’s Objectives

Course Map Contents 1. Introduction Planning Phase 2. Project Initiation 3. Project Management Analysis Phase 4. Systems Analysis 5. Gathering Information 6. Process Modeling 7. Data Modeling Assignments Quizzes Final Week Core Exam Review

Topic Duration Recap Data Modeling30 minutes Quiz45 minutes *** Break15 minutes Process Modeling90 minutes Assignment 4 Intro10 minutes Today’s agenda

Topic Duration Recap Data Modeling30 minutes Quiz45 minutes *** Break15 minutes Process Modeling90 minutes Assignment 4 Intro10 minutes Today’s agenda

Foreign Key Example Customer(cust_id (PK), cust_name) Order (ord_no (PK), cust_id (FK), ord_date) Customers (Parent) cust_id cust_name 100Slick Willy, Inc. 200George_W, Co. 300Gore, Ltd. … ord no cust_idord_date Sep Nov Dec Dec-2000 … Orders (Child) A foreign key is a primary key of one entity that is duplicated in another entity to provide a common linkage between entities. PK FKCust_id

Entity Types 1.Independent 2.Dependent 3.Intersection

Independent Entities An independent entity exists without the help of another entity –Common entities such as student, professors, customers, products –The identifier is created by the entity’s own attributes –Usually on the “1” side of a relationship –a.k.a. fundamental entity (in Visual Analyst, e.g.) or strong entity

Dependent Entities Alternatively, a dependent entity cannot exist without the help of another entity –Special entities such as emp_dependent (needs an employee to exist) –The identifier is usually based on another entity’s attributes (emp_ssn & dep_ssn) –Usually on the “M” side of a relationship –a.k.a. attributive entity (in Visual Analyst, e.g.) or weak entity

Intersection entities An intersection entity exists based on the relationship between two entities. –They have attributes that are peculiar to the relationship between those entity instances, not the individual entities themselves –They are created to store information about two entities sharing an M:M relationship –a.k.a. associative entities, gerunds

Intersection Entity Example A student may take many classes. A class may have many students. Where are grades stored? Student Class An instance in the student entity is related to _____ instances in the class entity. An instance in the class entity is related to _____ instances in the student entity. RosterStudentClass

Adding Intersection Entities 1.Create an intersection entity (line item). 3. The “1” side goes on the original entities. 2.Move the “M’s” adjacent to the intersection entity.

M:N to 1:Ms Rule: The M always go to the intersection entity. Why?

Creating An Entity- Relationship Diagram

Steps in Building Data Models 1.Review existing data models 2.Define entities a.Independent b.Dependent, including Intersection entities 3.Define attributes and keys (primary, foreign) 4.Define relationships 5.Finalize ERD 6.Normalize (to be covered in IS 422) 7.Integrate data models as required 8.Verify completeness of the data model 9.Validate the data model a.With users b.With the enterprise’s data administrator

Design Guidelines Best practices rather than rigid rules Entities should have many instances (don’t include fixed items such as stationery headings) Avoid unnecessary attributes (outside the scope of your system) Apply correct cardinality and modality Labels reflect common business terms Assumptions should be clearly stated

Summary The ERD is the most common technique for drawing data models. The building blocks of the ERD are: –Entities (nouns), describe people, places, or things –Attributes (nouns), capture information about the entity –Relationships (active verb sentences) associate data across entities; they have cardinality and modality

Topic Duration Recap Data Modeling30 minutes Quiz45 minutes *** Break15 minutes Process Modeling90 minutes Assignment 4 Intro10 minutes Today’s agenda

Topic Duration Recap Data Modeling30 minutes Quiz45 minutes *** Break15 minutes Process Modeling90 minutes Assignment 4 Intro10 minutes Today’s agenda

SDLC The systems development life cycle (SDLC) is a description of the phases of an information system PlanningAnalysisDesign Implementation

Process Modeling in the Analysis Phase From Planning Phase: System request Feasibility analysis Workplan. Dev Analysis Plan Examine- As-is Identify Improve- ments Develop Basic System Concepts Develop Data Model Develop Process Model Prepare Proposal To Design Phase: Deliverables: Analysis PlanFunctional Requirements Quality Requirements System Concept Data Model Process Model System Proposal Develop Concept for To-Be System

Key Definitions A process model is a formal way of representing business processes –Illustrates processes/activities and how data moves among them Data flow diagramming is a technique for creating a process model. –The primary output of data flow diagramming is a data flow diagram (DFD)

Key Definitions Logical process models describe processes without suggesting how they are conducted Physical models include information about how the processes are implemented

Data Flow Diagrams

Structure Chart PROCESS_PAYROLL for each employee get_data(:employee_data) calc_salary(employee_data:salary) calc_tax(salary:tax) print_check(employee_data, salary, tax) GET_DATA employee_data CALC_SALARY employee_ data salary CALC_TAX salary tax PRINT_CHECK employee_data salary tax

Program Graph READ_ DATA CALC_ SALARY CALC_ TAXES PRINT_ PAYCHECK employee_data employee_ data salary taxes

Program Graph READ_ DATA CALC_ SALARY CALC_ TAXES PRINT_ PAYCHECK employee_data employee_ data salary taxes Big idea: As a prelude to creating a design, represent the basic computational requirement for the system to be designed in more abstract terms, i.e., in terms of data flow

DFD Elements

Some Rules for External Entities External people, organizations, systems and data stores Reside outside the system, but interact with system Either receive info from system or trigger system into motion Examples: Customers, managers Not clerks or other staff External Entities

Some Rules for Data Stores Internal to the system Data at rest Include in system if the system processes transform the data –Create, Update, Delete Every data store on DFD should correspond to an entity on an ERD Must have at least one input data flow (or else they never contain any data) Usually have at least one output data flow Data Stores D1

Some Rules for Data Flows Data in motion –From external entity (“source”) to system –From system to external entity (“sink”) –From internal symbol to internal symbol, but always either start or end at a process Data Flow

Some Rules for Processes Always internal to system Law of conservation of data: #1: Data stays at rest unless moved by a process. #2: Processes cannot consume or manufacture data –Must have at least 1 input data flow (to avoid miracles) –Must have at least 1 output data flow (to avoid black holes) –Should have sufficient inputs to create outputs (to avoid gray holes) 0. Processes

Logical process models omit any processes that do nothing more than move or route data, thus leaving the data unchanged. Valid processes include those that: –Perform computations (e.g., calculate grade point average) –Make decisions (e.g., determine availability of ordered products) –Sort, filter or otherwise summarize data (e.g., identify overdue invoices) –Organize data into useful information (e.g., generate a report or answer a question) –Trigger other processes (e.g., turn on the furnace or instruct a robot) –Use stored data (create, read, update or delete a record)

Structured English Common Statements Example Action Statement Profits = Revenues - Expenses Generate Inventory - Report Add Product record to Product Data Store If Statement IF Customer Not in Customer Data Store THEN Add Customer record to Customer Data Store ELSE Add Current-Sale to Customer’s Total-Sales Update Customer record in Customer Data Store For Statement FOR all Customers in Customer Data Store Generate a new line in the Customer-Report Add Customer’s Total-Sales to Report-Total Case Statement CASE If Income < 10,000: Marginal-tax-rate = 10% If Income < 20,000: Marginal-tax-rate = 20% If Income < 30,000: Marginal-tax-rate = 31% If Income < 40,000: Marginal-tax-rate = 35% ELSE Marginal-tax-rate = 38% ENDCASE

Creating Data Flow Diagrams Creating DFDs is a highly iterative process of gradual refinement. General steps: 1. Create Use cases/textual requirements descriptions 2. Create a Context diagram 3. Create DFD fragments for each use case/requirement 4. Create a Level 0 diagram from fragments 5. Decompose to Level 1,2,… 6. Go to step 1 and revise as necessary 7. Validate DFDs with users.

Creating Use Cases

Step 1. Use Cases Ask who, what, where, when about tasks the system will perform Major tasks: –Who does them? When? –What info is required to perform the task? –What output is generated? Where does the output go? Remember: The process is iterative. Remember: Use cases are for users’ benefit, not programmers.

Step 1. Use Cases Name: becomes a process name on the level 0 DFD Description Trigger: external or temporal Major inputs: become data flows Major outputs: become data flows Major steps performed: become process names on the level 1 DFD Information for steps

Creating Data Flow Diagrams

Steps in Building DFDs 2. Create the context diagram 3. Create DFD fragments for each use case 4. Organize DFD fragments into level 0 diagram 5. Decompose level 0 DFDs as needed 6. Go to step 1 and revise as necessary 7. Validate DFDs with users.

Step 2. Context Diagram Shows the context into which the business process fits Shows the overall business process as just one process Shows all the outside entities that receive information from or contribute information to the system

Step 2. Context Diagram Draw the overall system as a process. –Number the process 0. –Label the process as the name of the system. Draw and label all external entities. No data stores, unless external. Draw data flows for all possible data coming from or going to external entities –Bundle data flows as you deem necessary

Context Diagram Example

Step 3. Create DFD Fragments For each use case, create a DFD fragment. One process (verb phrase) per fragment Maintain organization’s viewpoint in naming processes Layouts often place: –Process in the center –Inputs from the left –Outputs to the right –Add data stores beneath the processes

DFD Fragment Example

Step 4. Level 0 Diagram Integrate DFD fragments to a Level 0 DFD There will be one Level 0 diagram, –Shows all the processes that comprise the overall system –A decomposition of the process on the context diagram Shows how information moves from and to each process

Level 0 Tips Generally move from top to bottom, left to right Minimize crossed lines Iterate as needed –The DFD is often drawn many times before it is finished, even with very experienced systems analysts

Some Data Flow Rules A process moves data from place to place in the system. On a data flow diagram, processes may move data between certain symbols (data stores, external entities, and other processes). However, data may not be moved without a process. To help you understand and appreciate this, fill in the empty cells in the following table. The cell entries should either be 1) An example of how data could be moved; 2) N/A to indicate this cannot be done. In this example, “customer information” may be moved from an external entity to a process (e.g., a customer gives their address and credit card information to a sales agent). The “N/A” suggests data cannot be moved from a data store directly to an external entity, which is true (you need a process in between them).

Relationship Among DFD levels

Step 5. Level 1 Diagrams A major step on the use case is usually a process on the Level 1 DFD Level 1 DFD shows all the processes that comprise a single process on the level 0 diagram Inputs to step are input data flows to process Outputs to step are output data flows from process In general, # level 1 DFDs = # of processes on level 0 DFD

Level 2 Diagrams Shows all processes that comprise a single process on the level 1 diagram Shows how information moves from and to each of these processes Level 2 diagrams may not be needed for all level 1 processes Correctly numbering each process helps the user understand where the process fits into the overall system

Key Definition Decomposition is the process of modeling the system and its components in increasing levels of detail. Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.

Data Flow Splits and Joins A data flow split shows where a flow is broken into its component parts for use in separate processes Data flow splits need not be mutually exclusive nor use all the data from the parent flow As we move to lower levels we become more precise about the data flows A data flow join shows where components are merged to describe a more comprehensive flow

Alternative Data Flows Where a process can produce different data given different conditions We show both data flows and use the process description to explain why they are alternatives, e.g. –Process credit card rejections –Process credit card approvals Tip -- alternative data flows often accompany processes with IF statements

Tips for Level 1 and Below Sources for inputs and outputs listed at higher level List source and destination of data flows to processes and stores within each DFD Depth of DFD depends on overall system complexity –Two processes generally don’t need lower level (move to higher level) –More than seven processes become overly complex and difficult to read

Hierarchical Consistency Diagrams –A context diagram and level 0 DFD must always exist. Process –Must decompose to either another diagram or an elementary (primitive) process (e.g. Calculate order cost, Update customer address, Validate customer identification). –Must be numbered with respect to its parent.

Hierarchical Consistency Balancing Data Flows –An input (output) data flow on a PARENT diagram must appear on a CHILD diagram as input (output). –Conversely, an input (output) data flow on a CHILD diagram must appear on a PARENT diagram as input (output). –A set of data flows on a child diagram that were split from a data flow on a parent diagram must match the parent data flow's composition.

Step 7. Validating the DFD Syntax errors –Assure correct DFD structure Semantics errors –Assure accuracy of DFD relative to actual/desired business processes User walkthroughs Role-play processes Examine lowest level DFDs Examine names carefully

Summary The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes and data flows. Use cases record the input, transformation, and output of business processes. Eliciting scenario descriptions and modeling business processes are critically important skills for the systems analyst to master.

Exercise

Topic Duration Recap Data Modeling30 minutes Quiz45 minutes *** Break15 minutes Process Modeling90 minutes Assignment 4 Intro10 minutes Today’s agenda