IS 421 Information Systems Analysis James Nowotarski 4 November 2002.
IS 421 Information Systems Analysis James Nowotarski 21 October 2002.
-
date post
20-Dec-2015 -
Category
Documents
-
view
221 -
download
0
Transcript of IS 421 Information Systems Analysis James Nowotarski 21 October 2002.
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