IS 421Information 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 Phase2. Project Initiation3. Project Management

Analysis Phase4. Systems Analysis5. Gathering Information6. Process Modeling7. Data Modeling

1 2 3 4 6 7 8 9 10 115

Assignments

QuizzesFinal

Week

CoreExamReview

Topic Duration

• Recap Data Modeling 30 minutes

• Quiz 45 minutes

*** Break 15 minutes

• Process Modeling 90 minutes

• Assignment 4 Intro 10 minutes

Today’s agenda

Topic Duration

• Recap Data Modeling 30 minutes

• Quiz 45 minutes

*** Break 15 minutes

• Process Modeling 90 minutes

• Assignment 4 Intro 10 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

100 Slick Willy, Inc.

200 George_W, Co.

300 Gore, Ltd.…

ord no cust_id ord_date

2100 200 13-Sep-2000

2101 100 14-Nov-20002102 100 23-Dec-20002103 100 24-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.

PKFKCust_id

Entity Types1. Independent2. Dependent3. 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.

RosterStudent Class

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?

Orders

CD_No CD_Title Order_No CD_No Qty Order_No234 Best of Lawrence Welk 100101 234 12 100101235 Living Daylights Soundtrack 100101 236 3 100102236 Moody Blues Greatest Hits 100102 234 5 100108

100102 235 2100102 236 6100108 236 1

CD Line Items

Creating An Entity-Relationship Diagram

Steps in Building Data Models1. Review existing data models2. Define entities

a. Independentb. Dependent, including Intersection entities

3. Define attributes and keys (primary, foreign)4. Define relationships5. Finalize ERD6. Normalize (to be covered in IS 422)7. Integrate data models as required8. Verify completeness of the data model9. Validate the data model

a. With usersb. 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 Modeling 30 minutes

• Quiz 45 minutes

*** Break 15 minutes

• Process Modeling 90 minutes

• Assignment 4 Intro 10 minutes

Today’s agenda

Topic Duration

• Recap Data Modeling 30 minutes

• Quiz 45 minutes

*** Break 15 minutes

• Process Modeling 90 minutes

• Assignment 4 Intro 10 minutes

Today’s agenda

SDLC

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

Planning Analysis Design Implementation

Process Modeling in the Analysis Phase

FromPlanningPhase:

System requestFeasibility analysisWorkplan . . .

DevAnalysisPlan

Examine-As-is

IdentifyImprove-ments

DevelopBasicSystemConcepts

DevelopDataModel

DevelopProcessModel

PrepareProposal

ToDesignPhase:

Deliverables:

Analysis Plan Functional Requirements

Quality Requirements

SystemConcept

Data Model

Process Model

System Proposal

Develop Conceptfor 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

salary

taxes

Program Graph

READ_DATA

CALC_SALARY

CALC_TAXES

PRINT_PAYCHECK

employee_data

employee_data

salary

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

ExternalEntities

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 StoresD1

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

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 CASEIf 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

External entity Process Data store

External entityCustomer

information

Process

Data store N/A

Data moved TO:

Data Moving FROM

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 Modeling 30 minutes

• Quiz 45 minutes

*** Break 15 minutes

• Process Modeling 90 minutes

• Assignment 4 Intro 10 minutes

Today’s agenda