DFD Note

7/28/2019 DFD Note

1/66

BrianLewis/2010

COSC 2810FOILS, CLASS 5a

1. Why Do We Need to Learn Process Modelling? 1-2

2. Class Objectives

3. Key Topics Last Class4. COSC 2810 Projects 1-2

5. Project Feedback

6. Key Topics This Class

7. Process Modelling Glossary 1-2

8. Logical Process Models 1-2

9. Buying a Coke at Billa Context Process Model

10. Process Modelling

11. Buying a Coke at Billa 1st Level Data Flow Diagram

12. Data Flow Concepts

13. Data Flow Diagrams

14. Advantages of Data Flow Diagrams

15. My Data Flow Diagramming Symbols

16. Car Purchase System 1-3

17. DFD - Whats Wrong Here? 1-4

18. Developing Data Flow Diagrams19. Exploding & Balancing Data Flow Diagrams

20. Tips From an Old Modeller

21. Functions, Events & Elementary Processes 1-2

22. Functional Decomposition Diagram

23. Event-Driven Process Modelling According to the Textbook 1-3

24. Developing Process Models for the COSC 2810 Project 1-4

25. COSC 2810 Methodology Phase 4 Logical Design

26. Biograd Passenger Handling System 1-1827. Assignment 5a 1-5

* foil included in this document for reference, but not shown in class** additional foil shown in class, butnot included in this document

7/28/2019 DFD Note

2/66

BrianLewis/2010

WHY DO WE NEED TO LEARN PROCESS MODELLING?

7/28/2019 DFD Note

3/66

BrianLewis/2010

WHY?1. To UNDERSTAND how an operation works

2. To UNDERSTAND what processes are involved

3. To UNDERSTAND the data they need as I/P

4. And how they TRANSFORM them to O/P

5. To COMMUNICATE with users

6. To be able to DESIGN software to perform

processes in an organisation

7. To have something which can be used to

SPECIFY what the software should do

8. To give to programmers in a form that they

UNDERSTAND

Oh, and also to UNDERSTAND

(did I mention that?)

Let me tell you a story about using Process Models to

communicate & reverse-engineer a Financial Budget

applicaton I knew very little about Budgeting & the

User knew very little about Computing . . .

7/28/2019 DFD Note

4/66

BrianLewis/2010

COSC 2810 OBJECTIVES

CLASS 5a

REVIEWWHAT WE LEARNED LAST CLASS

ASSOCIATIVE ENTITIES ??

NORMALISATION ??

TAKE THE CONCEPTS FROM CHAPTER 9, LEAVE

THE TRIVIA AND UNDERSTAND HOW TO

MODEL PROCESSES IN PRACTICE

(without getting carried away in the process )

SEE WHAT PROCESS MODELS OUR PROJECTS

REQUIRE

HEAR REPORTS FROM OUR PROJECT TEAMS

LOOK AT THE MARRIAGE RELATIONSHIP?

(despite our relative lack of experience)

7/28/2019 DFD Note

5/66

BrianLewis/2010

KEY TOPICS Classes 4a & 4b/Chap 8

Entity Attribute Instance Relationship

Compound Attribute Data Type Domain

Primary

Key

Foreign

Key

Composite

Key

Intelligent

Key

Strong vs Weak Entity Associative Entity

Parent & Child

Entities

One-to-Many &

Many-to-Many

Cardinality

Context

Data Model

Entity-Relationship

Diagram

Key-Based

Data Model

Generalisation Supertype & Subtype

Schema & Subschema Normalisation Metadata

Topics you might need to explain in Quizzes & Exams

7/28/2019 DFD Note

6/66

BrianLewis/2010

COSC 2810 PROJECTS

TEAM MEMBERS SYSTEM

Apples Jestin, Matthew,

Michael, Sebastian

University Course Scheduling

Decision Support System

Berries Adisa, Basil, Dejan, Rok Electronic Advisor forWebster

Cherries Adwa, Sabina, Ivan, Tino,

Zeljko

Improvement of Hotel

Reservation System

Project leaders for the past week are single underlined.

Project leaders for the next week are double underlined. They are

required to report, in class 6a, on:

a) the teams achievements & progress in the past week

b) the teams plans for the following week

7/28/2019 DFD Note

7/66

BrianLewis/2010

COSC 2810 PROJECT SCHEDULE

Project Reports Class Due

Draft (D) or Final (F) 1a 1b 2a 2b 3a 3b 4a 4b 5a 5b 6a 6b 7a 7b 8a 8b

Project Approval Project Definition x D F

Problem Analysis x D F

Requirements Analysis x x D F

Logical Data Design x x D F

Logical Process Design D F

Feasibility Analysis x D F

System Architecture x F

Group Presentation System Proposal x x =CLASSES COVERING TOPICS NECESSARY FOR THE (DRAFT) DELIVERABLE

7/28/2019 DFD Note

8/66

BrianLewis/2010

PROJECT FEEDBACK

This will have no effect of anyones grade (yet)

needs

improvement

needsimprovement

OK

7/28/2019 DFD Note

9/66

BrianLewis/2010

KEY TOPICS Classes 5a & 5b/Chap 9

Context Process Model Data Flow Diagram

External Agents

& Data Stores

External, Temporal &

State Events

Functions & Events Data & Control Flows

System Diagram Event Diagram

Elementary Process Primitive Diagram

Balancing DFDs Data Structure

Data in Motion

versus Data at Rest

Black Holes

& Grey Holes

Structured English Decision Tables

Topics you might need to explain in Quizzes & Exams

Once again, please don't be overwhelmed by

the jargon & terms

Focus on Understanding & Modelling the Requirements,

rather than diagramming for the sake of it

7/28/2019 DFD Note

10/66

BrianLewis/2010

Process Modelling GlossaryProcess

A business function or operation

that transforms input data to

output data

Data Store

File/table of data

representing an

Entity

Data Flow

Data that are input

to, or output from,

a Process

Control Flow

A condition (not

data) that triggers

a Process

Composite Data Flow

Combination of several

similar Data Flows into one

Context Diagram

DFD showing the boundaries (scope)

of a single Process, with External

Agents, Data Stores & Data Flows

External Agent

Third party outside the

system that interacts

with it (aka Actor)

Function

A set of ongoing

activities

Event

A set of tasks that must be completed

as a whole (aka Transaction)

Elementary Process

A basic task or piece of work (aka

Primitive Process)

Data Structure

Set of data attributes

comprising a data flow

Data Flow Diagram (DFD)

A model showing data flowing between the processes of a system and

the processes' interaction with External Agents & Data Stores

External Event

An input Data Flow is

initiated by an External

Agent

Temporal Event

A Control Flow is

triggered by the passing

of Time

State Event

A Control Flow is triggered by a

change in the state of the (real-time)

system

7/28/2019 DFD Note

11/66

BrianLewis/2010

Process Modelling GlossaryDiverging Data Flow

Data flow that splits into multiple data flows,

indicating data that start out as one flow, but

are routed to different destinations

Converging Data Flow

Merging of multiple data flows into a single

packet, indicating data from multiple sources

that come together as a single packet

Event Partitioning

Structuring system into subsystems

based on Business Events & responses

Event-Response List

Business Events to which

the system must respond

Event Handler

Process which deals with

carrying out an Event

Event Diagram

DFD context diagram for a single

Event, with External Agents,

Data Stores & Data Flows

System Diagram

DFD of all Event

Diagrams in a

system/sub-system

Primitive Diagram

DFD of Elementary Processes,

External Agents, Data Stores & Data

Flows, for a single Event

Balancing

DFDs at different levels should be consistent,

e.g. don't add a Data Store at a lower level

that wasn't in a higher level DFD

Black Hole

Process with

input but no

output

Grey Hole

Process with insufficient

inputs to produce the

output

Structured English

English-like commands for

specifying a Process's logic

Decision Table

Matrix of a set of conditions

and corresponding actions

CRUD

Short for Create, Read,

Update, Delete

7/28/2019 DFD Note

12/66

BrianLewis/2010

LOGICAL PROCESS MODELS

The diagram has four important components

1. DATA (information) FLOWS

2. PROCESSES (functions), whicho receive an item of data as input,

o transform it in some way,

o then output it

3. DATA STORESrepresent ENTITIES in our system

4. EXTERNAL AGENTS - thingsfrom which data areoriginally received or to which data are eventually sent

DATA are flowing between PROCESSES & DATA

STORES & to/from EXTERNAL AGENTS, so if we wish

to computerise part of this business, we need to store

the DATA in database TABLES& write PROGRAMSto

carry out the PROCESSES

7/28/2019 DFD Note

13/66

BrianLewis/2010

LOGICAL PROCESS MODELS

ALL ORGANISATIONS HAVE FUNCTIONS THAT

CARRY OUT PROCESSES

IN OUR COMPUTERISED SYSTEM WE NEED

PROGRAMS TO PERFORM THESE PROCESSES

THE DATA MODEL HELPS US DESIGN OUR

DATABASE, NOW WE NEED SOMETHING TOHELP US DESIGN OUR SOFTWARE

BY CLARIFYING WHICH FUNCTIONSEXIST IN

OUR SYSTEM AND DETERMINING . . .

1. THE STEPS INVOLVED IN EACH PROCESS2. WHAT INPUT EACH PROCESS NEEDS

3. WHAT OUTPUT EACH PROCESS PRODUCES

. . WE CAN ACHIEVE A STABLE SOFTWARE DESIGN

DATA FLOW DIAGRAMS ARE USED TO PRODUCE

A PROCESS MODEL THAT PROVIDES ABLUEPRINT FOR DESIGNING PROGRAMS IN A

COMPUTER SYSTEM

AS YOU KNOW BY NOW, A CONTEXT DIAGRAM

IS ALWAYS A HELPFUL FIRST STEP

7/28/2019 DFD Note

14/66

BrianLewis/2010

BUYING A COKE AT BILLA

CONTEXT PROCESS MODEL

POINT OF

SALE SYSTEM

PRICE TABLE

CASHIER

CUSTOMER

BANKINVENTORY FILE

CUSTOMER FILE

product

bar code

price

authorisation request

discount

product #,amount soldclearance

ACCOUNTS FILE

record of

payment

customer #,

credit card data

product code

payment receipt

customer #

Data StoreExternalAgent

Data Flow

7/28/2019 DFD Note

15/66

BrianLewis/2010

and so, you might ask, where's the coke???!!!

7/28/2019 DFD Note

16/66

BrianLewis/2010

PROCESS MODELLING

A CONTEXT level DFD sets the boundaries of the

system and identifies Actors outside the system

The Context Diagram is then developed further by:

1. EXPLODING (BREAKING DOWN) THE SYSTEM

INTO ITS SUB-SYSTEMS OR FUNCTIONS

(This identifies the PROCESSES in the system)2. ADDING TO EACH PROCESS:

What INPUTit needs to perform its tasks

And where it comes from

What FILES (stored data) it uses

What the OUTPUT(result) of the process is

And where it goes to

3. EXPLODING PROCESSES TO FURTHER LEVELS

Remember the PROCESSING CYCLE ??(the basic operations of a computer)

INPUT PROCESS OUTPUT

STORAGE

7/28/2019 DFD Note

17/66

BrianLewis/2010

BUYING A COKE AT BILLA1ST LEVEL DATA FLOW DIAGRAM

record of payment

P1

COMPUT

E SALE

PRICE TABLE

CASHIER

CUSTOMER

BANK

INVENTORY FILE

CUSTOMER FILE

customer #

product barcode

price

authorisation request

discount

product code,amount soldclearance

ACCOUNTS FILE

credit card data

product code

payment receipt

customer #

P2

VERIFY

CREDIT

P4

PRINT

BILL

P3

UPDATE

DB

amount topay

items sold,amount paid

transactiondetails

items, prices

ok

7/28/2019 DFD Note

18/66

BrianLewis/2010

DATA FLOW CONCEPTS

By studying the use of data as they are:

INPUT

PROCESSED (Transformed)

STORED

USED

CHANGED

RETRIEVED

OUTPUT

. . . and then building Process Models with

Data Flow Diagrams . . .

. . . we gain a significant insight into the way

a Business Operation works . . .. . . and can document:

a] what the existing system does

b] what the proposed system should do

7/28/2019 DFD Note

19/66

BrianLewis/2010

DATA FLOW DIAGRAMS

1. ILLUSTRATE: Essential Components of a system

Its Functions and how these Interact

Transformations by Processes on Data

What Activities are taking place

And in what Sequence

2. DOCUMENT: the Processes in the system

the Data needed by each process as Input

the Data each process produces as Output

the DataStored by the system

the DataEntering & Leaving the system

DFDs SHOULD NOT BE CONFUSEDWITH FLOWCHARTS!!!!!!!!!

7/28/2019 DFD Note

20/66

BrianLewis/2010

ADVANTAGES of

DATA FLOW DIAGRAMS

DFDs HELP TO PARTITION REQUIREMENTSAnd then become detailed specifications of programs

DFDs CAN SHOW PARALLEL ACTIVITIESWhereas flowcharts only show sequence

DFDs ARE EASIER TO UNDERSTANDThan narrative or flowcharts, especially for users

DFDs CAN CATCH ERRORS EARLY

Before they become expensive to correct

SPECIFIC AREAS OF THE ORGANISATION

CAN BE ISOLATEDBefore breaking down each area into detail

(Divide & Conquer)

DFDs SHOW A SYSTEM FROM AN OVERALL

LEVEL TO THE DETAILLike maps of the world, showing country, then provinceand then town etc.

7/28/2019 DFD Note

21/66

BrianLewis/2010

MY DATA FLOW DIAGRAM SYMBOLS

DFDs may not look attractive, but they are a very

powerful tool for analysing & designing, but above all

UNDERSTANDING, how (business) operations work

A BUSINESS FUNCTION

OR PROCESS THAT USESOR TRANSFORMS DATA

A FILE OR DATABASETABLE OF DATA

SOURCE OF INPUT DATA ORRECIPIENT OF PROCESSED

DATA THAT IS EXTERNAL[to the system being modelled]

DATA [INFORMATION] FLOWINGBETWEEN PROCESSES, DATA

STORES, SOURCES & SINKS

CONDITION OR EVENT THATTRIGGERS A PROCESS

LABEL EACH WITH A DESCRIPTIVE NAME

NUMBER EACH PROCESS

Time for an example . . .?

PROCESS

DATA FLOW

DATA STORE

EXTERNAL

AGENT

CONTROL FLOW

7/28/2019 DFD Note

22/66

BrianLewis/2010

PROCESS MODEL CAR PURCHASE SYSTEM

CONTEXT DATA FLOW DIAGRAM

P0CAR

PURCHASESYSTEM

CARDEALER BOOK

SHOP

BANK

request for information

car magazines

payment

features & prices

payment

instructions

order+payment

CUSTOMER

models, specs, prices

External Agent

Data Store

ProcessDataFlow

CATALOGUE

models

7/28/2019 DFD Note

23/66

BrianLewis/2010


1ST LEVEL DATA FLOW (SYSTEM) DIAGRAM

Do We Understand Enough To Design Software? (if not . . .

P1CHOOSE CAR

P2

PLACEORDER

P3

PAY

CARDEALER BOOK

SHOP

car magazines

payment

features & prices

CUSTOMER


inquiry

order

confirmation

BANKinstructionamount

CATALOGUE

modeldetails

selectedcar data

price OK

7/28/2019 DFD Note

24/66

BrianLewis/2010


2ND LEVEL DATA FLOW DIAGRAM (P1 CHOOSE CAR)

P1.1COLLECT

INFORMATION

P1.2EVALUATE

P1.3SELECT

MODEL &EXTRAS

CARDEALER BOOK

SHOP

car magazines

payment

features & prices

CUSTOMERrelevant test data

car data

results

modeldetails

request forinformation

inquiry

balance

test data

P2PLACEORDER

selected car data + price

CATALOGUE CAR TESTS

BANK ACCOUNT

7/28/2019 DFD Note

25/66

BrianLewis/2010

WHO WANTS AN A

FOR PROCESS MODELLING TODAY ???

Consider a Customer buying a new car. Theprocess might look like this:

1. VISIT CAR SHOW ROOM

2. GATHER DATA ABOUT VARIOUS MAKES

& MODELS3. SELECT A MAKE, MODEL & FEATURES

WHICH MEET OUR REQUIREMENTS

4. ARRANGE A TEST DRIVE

5. CHECK CAR MAGAZINES FOR REVIEWS

6. PLACE AN ORDER WITH A CAR DEALER

7. TELL OUR BANK TO TRANSFER THE

FUNDS TO THE CAR DEALER

8. TAKE DELIVERY OF THE CAR

If we are developing an information system forthis purchase application, we need a Process

Model a Data Flow Diagram

We would start our Process Modelling by drawing

a Context Diagram to set the system boundaries

7/28/2019 DFD Note

26/66

BrianLewis/2010

DFD - WHATS WRONG HERE?

CONTEXT DIAGRAM

There are EIGHT mistakes in this DFD - How many can your team find?

7 or more = A+; 6 = A; 5 = B; 4 = C; 3 = D;

7/28/2019 DFD Note

27/66

BrianLewis/2010

DFD - WHATS WRONG HERE?

CONTEXT DIAGRAM(flow direction)

(not a data store)

(actions cannot flow)(data must flow in one

direction, not both)

(physical objects

cannot flow)

(not a process)

(unnamed data flow)

P0CAR

PURCHASESYSTEM

CARDEALER

car magazines

features & prices

tell bank totransfer money

order+payment

CUSTOMERmodels, specs, prices

request forinformation

BOOKSHOP

car

BANK

payment

(data cannot flow

outside the system)

7/28/2019 DFD Note

28/66

BrianLewis/2010

DFD - WHATS RIGHT HERE

CONTEXT DIAGRAM

P0CAR

PURCHASESYSTEM

CARDEALER

BOOKSHOP

BANK


car magazines

payment

features & prices

payment

instructions

order+payment

CUSTOMER

models, specs, prices

7/28/2019 DFD Note

29/66

BrianLewis/2010

DEVELOPING DFDsDIVIDE & CONQUER

WORK FROM THE TOP DOWN

Start with a Context Diagram to define the scope

& boundaries of the system

Then create a lower-level diagram by breaking

down the system into its major functions

When a process requires more detail in order tounderstand it sufficiently, then . . .

Continue breaking down such processes to a lower

level of 3 7 sub-processes

Until you reach basic elementary processes &

understand the detail But keep the big picture in mind - dont lose sight

of the overall purpose, nor get buried in detail

One level at a time

BUT DON'T BE AFRAID TO GO BACK UP

We seldom model purely from Top to Bottom

But Group, Re-group, Explode, Consolidate as we

go

And ensure that the Process Model is consistentwith the Data Model & that both are consistent

with the Requirements (Use Case) Model

7/28/2019 DFD Note

30/66

BrianLewis/2010

7/28/2019 DFD Note

31/66

BrianLewis/2010

EXPLODING & BALANCING DFDs

EXPLODING (aka Partitioning)

Creating a lower-level DFD for a process Used when a process requires more detail in

order to understand it sufficiently

Continue exploding at successive levels until:

the process is understood sufficiently wellenough to enable a specification for a program

to be written

all processes at the lowest level are elementary

processes (single processing functions)

BALANCING

Maintain consistency between levels

Dont add new inputs, outputs or Data stores that

were not at a higher level

ADDING CONTROL ONLY AT LOWER LEVELS

Put error control & exception handling at lower

levels

Avoid physical controls, e.g. copy to Carina

7/28/2019 DFD Note

32/66

BrianLewis/2010

TIPS FROM AN OLD MODELLER

1. While you are drawing a diagram at any level,

think of the Processes in it as "Black Boxes"until you need to explode them

2. Think of data flowing between processes

3. Try not to think of one process flowing to the

next it's data that are flowing4. Dont think about IF . . THEN (thats inside

a process)

5. Remember that data flow, not actions nor

physical objects

6. Name each & every data flow

7. And name the data flowing, not what they are

recorded on, e.g. song, not DVD

8. Check that all data flows begin or end at aprocess (not from an external agent to another

external agent or to a data store)

9. Name data flowing out of a process differently

to those flowing in

(because if the data havent changed, why is

the process there?)

7/28/2019 DFD Note

33/66

BrianLewis/2010

FUNCTIONS, EVENTS &

ELEMENTARY PROCESSES

FUNCTIONSet of ongoing activitiese.g. Advising students, Servicing cars, Airport Check-in

EVENT(aka Transaction)Logical unit of work that must be done as a whole

e.g. Enrol a student, Service this car, Check in a passenger

EXTERNAL EVENT

Input data flow initiated by an External Agente.g. customer changes address

TEMPORAL EVENT

Time is the trigger for an evente.g. end of the month arrives - start process xyz

STATE EVENT

Some change in the system triggers an event

e.g. the Bancomat is out of cash

ELEMENTARY PROCESS (aka Primitive Process)Detailed activity or task (basic piece of work)e.g. Print bill, Change motor oil, Assign seat to passenger

7/28/2019 DFD Note

34/66

BrianLewis/2010

FUNCTIONS, EVENTS &

ELEMENTARY PROCESSES

Consider the process of a gamebetween two Football Teams

Function, External Event, State Event, Elementary Process?

Taking a Corner Elementary Process

Defending Function

Abandon Game due to Snow External Event

Passing the Ball Elementary Process

Scoring a Goal State Event

Managing the Team FunctionWhistle for Half-Time Temporal Event

Committing a Foul Elementary Process

Making a Substitution External Event

Taking a Penalty Elementary Process

Goalkeeping Function

Function: An Ongoing Activity

Event: A Set of Tasks Completed as a Whole

Elementary Process: A Basic Task

7/28/2019 DFD Note

35/66

BrianLewis/2010

FUNCTIONS, EVENTS & ELEMENTARY PROCESSES

FUNCTIONAL DECOMPOSITION DIAGRAM - EXAMPLE

2.5 2.5ELEMENTARY

PROCESSES(basic pieces of

work)

WEBSTER

UNIVERSITY

1.ADMISSION

2.REGISTRATION

3.ACADEMICAFFAIRS

4.STUDENTAFFAIRS

FUNCTIONS

(ongoing activities)

5.FINANCE

2.1

COURSESELECTION

2.2

ADVISORCONSUL-TATION

2.4

ENROL-MENT

2.5

MAKEPAYMENT

EVENTS (sets of tasks

completed as a whole)

RECORDPAYMENT

TRANSFERAMOUNT

CALCULATEAMOUNT TO

PAY

7/28/2019 DFD Note

36/66

BrianLewis/2010

EVENT-DRIVEN PROCESS MODELLING(ACCORDING TO THE TEXTBOOK)

CONTEXTDIAGRAM

DECOMPOSITION

DIAGRAM

EVENT-RESPONSE LIST

EVENT HANDLERS

EVENT

DIAGRAMS

SYSTEM DIAGRAM

PRIMITIVE DIAGRAMS

our system & its environment

break it down into

functions & events

one process to deal

with each event

show context of

each event

the detailed DFDs of the processes needed to carry out each event

a DFD of all

events in the

(sub-) system

7/28/2019 DFD Note

37/66

BrianLewis/2010

SO WHAT IS THE AUTHOR SAYING?

What How Why

1 Draw a ContextDFD

Show System and the Entities &Actors which connect to and areoutside it

To establish Scopeof System

2 Draw FunctionalDecompositionDiagram

Break down the System intoFunctions & Event (Handler)s

Divide & Conquer

3 Draw EventDiagrams

Show a Context DFD for every Eventthe system must respond to

To show the Eventsinteraction withExternal Agents &Data Stores

4 Draw SystemDiagram Combine all Event Diagrams on onepage To show the bigpicture

5 Draw PrimitiveDFDs

Explode each Event into theProcesses, Data Flows, Data Stores &External Agents needed

To show in detailexactly how eachEvent is carried out

7/28/2019 DFD Note

38/66

BrianLewis/2010

WHAT THE AUTHOR WANTS

US TO DO

FUNCTIONAL DECOMPOSITION DIAGRAM

(partitions system into functions/events)

CONTEXT DATA FLOW DIAGRAM(establishes initial system scope)

SYSTEM DIAGRAM

(one page DFD of all Event Diagrams

for system / sub-system)

EVENT DIAGRAMS

(lower-level DFDs showing the context

for each event)

PRIMITIVE DIAGRAMS

(detailed, lower-level DFDs showing theElementary Processes in each Event)

7/28/2019 DFD Note

39/66

BrianLewis/2010

WHAT WE'RE GOING TO DO

Weve only got another 4 weeks!!




1ST LEVEL (SYSTEM) DATA FLOW DIAGRAM

(identifies major system functions)

2ND LEVEL DATA FLOW DIAGRAMS (OPTIONAL)

(lower-level DFDs for complex processes

in the 1st level Diagram)

7/28/2019 DFD Note

40/66

BrianLewis/2010

DEVELOPING PROCESS MODELS FOR THE

COSC 2810 PROJECT

What How Why

1 Context DFD Show System and the External Agents(Entities & Actors) which are outside

it and connect to it

To establish Scopeof System

2 FunctionalDecompositionDiagram

Break down the System into Functions& Events

Divide & Conquer

3 SystemDiagram (1stlevel DFD)

Explode the Context Diagram intothe next lower level of systemfunctions, showing data flows to/fromprocesses, data stores & external

agents

To show the bigpicture by showingthe processing logicof system functions

4 2nd level DFDsfor complexprocesses(Optional)

Explode complex functions in theSystem Diagram into lower-level DFDsof the processes needed for thatfunction

To understand &show in more detailhow a function iscarried out

7/28/2019 DFD Note

41/66

BrianLewis/2010

COSC2810-DRIVEN PROCESS MODELLING

CONTEXTDIAGRAM

DECOMPOSITIONDIAGRAM

SYSTEM DIAGRAM(1ST LEVEL DFD)

2ND LEVEL DFDs(OPTIONAL)

our system & its environment

break it down into functions

& subfunctions (events)

the detailed

DFDs of any

complexprocesses

a DFD of the main

functions in the

system

3RD LEVEL DFDs,Primitive Diagrams

7/28/2019 DFD Note

42/66

BrianLewis/2010

COSC 2810 PROCESS ANALYSIS/DESIGN

TEXTBOOK COSC 2810 PROJECTS

1 Draw the Context Diagram Draw a Context DFD to

establish initial system scope

2 Compile an Event List of thoseactions which occur in our

system and to which our

system must respond

Draw Functional Decomp-osition Diagram to partition

the system into its main

subsystems/functions/events

3 Draw Functional Decomp-

osition Diagram:

a. illustrate in a hierarchy themajor functions (or sub-

systems) in the system

b. add under each function the

relevant Events

c. draw lower-level DFDs

(Event Diagrams) of eventsneeding more understanding

Explode the Context Diagram

into a First Level DFD

(System Diagram) of:1. the Processes (the system

functions)

2. the External Agents

3.the Data Stores

4. the Data & Control Flows

between Processes, DataStores & External Agents

4 Assemble all Event Diagrams

for a system or sub-system

into a System Diagram

Compile an Event List of

those actions which occur in

our system and to which our

system must respond

(OPTIONAL)5 Level the System Diagram, i.e.

Partition the Event Diagrams

a. either upwards, grouping

related processes into

higher-level DFDs

b. or downwards, explodingprocesses into more detail

Draw lower-level DFDs for

those complex events

requiring further

understanding

(OPTIONAL)

7/28/2019 DFD Note

43/66

BrianLewis/2010

COSC2810 METHODOLOGY PHASE 4

PHASE 4. LOGICAL DESIGN

4.1 CONVERTREQUIREMENTSTO SYSTEM MODELS

INTERVIEWUSERS

DEVELOP CONTEXTDATA MODEL (ERD)

DEVELOP NORMALISED KEY-BASED DATA MODEL

DRAW CONTEXTPROCESS MODEL

DEVELOPDETAILED PROCESS MODEL (DFD)

4.2 VALIDATE FUNCTIONAL REQUIREMENTS

INVOLVEUSERSTOVERIFYMODELS

4.3 DEFINE ACCEPTANCE TESTCRITERIA

DOCUMENTWHAT

THE

USER

NEEDS

TO

SEE

BEFORE

ACCEPTINGTHESYSTEMASCOMPLETED

4.4 DOCUMENTPHASE 4. AS TWO DELIVERABLES:

DATA DESIGN REPORT(Due by class 5b)

1. DATA MODEL (ENTITY RELATIONSHIP DIAGRAM)2. KEY-BASED DATA MODEL

PROCESS DESIGN REPORT(Due by class 6b)

1. CONTEXTPROCESS MODEL (CONTEXTDIAGRAM)

2. DETAILED PROCESS MODEL (DATA FLOW DIAGRAM)

this is our System Diagram

7/28/2019 DFD Note

44/66

BrianLewis/2010

TIME FOR ANOTHER

EXAMPLE?

A QUESTION FROM A RECENT EXAM

Consider the processes involved in an airports system for

getting passengers from the point when they arrive at anairport to the point when they enter the plane.

Draw a context diagram for this system and thenconstruct the first-level data flow diagram by identifyingprocesses and then adding relevant data flows, data stores

and external agents.Concentrate on showing your understanding of constructingproper data flow diagrams rather than trying to find aperfect solution.

Lets see how we might begin to answer this.

Thank goodness!! Mybrain is flowing with

functional, decomposed,

processed events, all

out of context!!

7/28/2019 DFD Note

45/66

BrianLewis/2010

BIOGRAD AIRPORT PASSENGER HANDLING SYSTEM

CONTEXT DIAGRAM

PASSENGER

P

PASSENGE

R

HANDLING

SYSTEM

ticket, passport

FLIGHT

DATABASE

boarding passPLANEbaggage list

flightreservation

data

seat #,passport #

if this were used onlywithin the PHS, we would

not show it in the

context diagram itwould be part of theProcess the system

7/28/2019 DFD Note

46/66

BrianLewis/2010



BIOGRAD

PHS

1.CHECK-IN

2.PASSPORTCONTROL

3.SECURITY

CHECK

4.BOARDING

FUNCTIONS (ongoing

activities)

5.BAGGAGELOADING

1.1

VERIFYPASSENGER

DATA

1.2

ASSIGNSEAT

1.3

WEIGH &TAG

BAGGAGE

1.4

ISSUEBOARDING

PASS

PRINTBOARDING

PASS

LOOKUP GATENUMBER

RETRIEVEPASSENGER &FLIGHT DATA

EVENTS (sets of tasks

completed as a whole)

ELEMENTARY

PROCESSES

(basic pieces of

work)

7/28/2019 DFD Note

47/66

BrianLewis/2010

BIOGRAD AIRPORT - PASSENGER

HANDLING SYSTEM

Partial EVENT LIST

Event Description Event Type

1.1.1 Check-In staff verify that passengers

ticket matches flight being checked in

External

1.1.2 Check-In staff verify that passengers

passport contains necessary visas

External

1.2. Unallocated seats are retrieved andone is blocked for passenger

External

1.3.1 Weighing machine advises weight of

baggage

State

1.3.2 Check-In staff verify that baggage

weight is within limit

External

1.3.3 Check-In staff print tag & affix it toticket

External

1.4. Check-In staff look up gate no. &

flight details and print boarding pass

External

.

.

4.1.1 Crew staff start boarding procedure

15 minutes before departure

Temporal

Event Types

EXTERNAL - process initiated by a data flow

TEMPORAL process is initiated by time

STATE process triggered by a change in the systems state

7/28/2019 DFD Note

48/66

BrianLewis/2010


1st LEVEL DATA FLOW DIAGRAM (SYSTEM DIAGRAM)

EXPLODING OUR SYSTEM INTO PROCESSES

P1

CHECK-INP2

PASSPORT

CONTROL

P3

SECURITYCHECK

P4

LOADBAGGAGE

P5

BOARDPLANE

7/28/2019 DFD Note

49/66

BrianLewis/2010

BIOGRAD AIRPORT PASSENGER HANDLING SYSTEM 1st LEVEL DFD

ADDING EXTERNAL AGENTS

P1

CHECK-IN

P2

PASSPORT

CONTROL

P3

SECURITY

CHECK

P4

LOAD

BAGGAGE

P5

BOARD

PLANE

PASSENGER

PLANE

7/28/2019 DFD Note

50/66

BrianLewis/2010


ADDING DATA STORES

P1

CHECK-IN

P2

PASSPORT

CONTROL

P3

SECURITYCHECK

P4

LOADBAGGAGE

P5

BOARDPLANE

PLANE SEATINGFLIGHTPASSENGER CRIMINAL

PASSENGER

PLANE

7/28/2019 DFD Note

51/66

BrianLewis/2010


ADDING DATA & CONTROL FLOWS

occupiedseats

PLANE SEATING

CRIMINAL

PASSENGER

FLIGHT

seat plan

seat #

ticket, passport

boarding pass

boarding pass stub

frequentflyer data

known criminals

boardingpass

ticket, passport,boarding pass

baggage weights

baggage listclearance

take-off 15 mins

P1

CHECK-IN

P2

PASSPORT

CONTROL

P3

SECURITY

CHECK

P4

LOAD

BAGGAGE

P5

BOARD

PLANE

clearance

PASSENGER

PLANE

7/28/2019 DFD Note

52/66

BrianLewis/2010


Where we started - CONTEXT DIAGRAM

PASSENGER

P

PASSENGE

R

HANDLING

SYSTEM

ticket, passport

FLIGHT

DATABASE

boarding pass PLANEbaggage list

flightreservation

data

seat #,passport #

7/28/2019 DFD Note

53/66

BrianLewis/2010


Where we finished - SYSTEM DIAGRAM

For our Projects, this level is where we can stop

occupiedseats

PLANE SEATING

CRIMINAL

PASSENGER

FLIGHT

seat plan

seat #

ticket, passport

boarding pass

boarding pass stub

frequentflyer data

known criminals

handbaggage


baggage weights

baggageclearance

take-off 15 mins

P1

CHECK-IN

P2

PASSPORT

CONTROL

P3

SECURITY

CHECK

P4

LOAD

BAGGAGE

P5

BOARD

PLANE

clearance

PASSENGER

PLANE

7/28/2019 DFD Note

54/66

BrianLewis/2010

SYSTEM DIAGRAM

We decomposed the system as shown in the

Context Diagram into its main sub-processes its FUNCTIONS

We not only achieved a deeper

understanding of the system

But we can use this model to communicate

with users on their functional requirements

And if we decide to computerise this system

we have identified important & necessary

components:

PROCESSES which will become programs

DATA STORES which become tables in our database

EXTERNAL AGENTS which will require interfacesDATA FLOWS which will become data structures and

which the programs will need as input,or will have to produce as output

THE NEXT STEP IS TO ASK: "DO WE HAVE SUFFICIENT

UNDERSTANDING OF ALL PROCESSES TO SPECIFY INDETAIL EXACTLY WHAT EACH PROGRAM SHOULD DO?"

7/28/2019 DFD Note

55/66

BrianLewis/2010

"DO WE HAVE SUFFICIENT

UNDERSTANDING OF ALL PROCESSES TO

SPECIFY IN DETAIL EXACTLY WHAT EACH

PROGRAM SHOULD DO?"

IF NOT, OUR NEXT STEP IS TO EXPLODE THOSE

PROCESSES WHERE WE LACK UNDERSTANDING

INTO FURTHER SUB-PROCESSES,

e.g. the EVENTS involved in the CHECK-IN FUNCTION

occupiedseats

P1

CHECK-IN

PASSENGER

PLANE

SEATING

PASSENGER

FLIGHT

seat plan

seat #

ticket, passport,

boarding pass

frequentflyer data


7/28/2019 DFD Note

56/66

BrianLewis/2010


2ND LEVEL DATA FLOW DIAGRAM CHECK-IN

EXPLODING A PROCESS INTO FURTHER SUB-PROCESSES

(EVENTS)

P1.1

VERIFY

PASSENGER

DATA

P1.2

ASSIGN

SEAT

P1.3

WEIGH &

TAG

BAGGAGE

P1.4

ISSUE

BOARDING

PASS

Note thehierarchicalnumbering

7/28/2019 DFD Note

57/66

BrianLewis/2010

BIOGRAD AIRPORT PHS 2nd LEVEL DFD FOR CHECK-IN

ADDING EXTERNAL AGENTS, DATA STORES & DATA FLOWS

baggage id

confirmation

PLANE SEATINGPASSENGER

seat plan

seat no.

ticket, passport

boarding pass

frequentflyer data booking

FLIGHT

occupiedseats

reserved seatpassenger

id

endorsed ticket, boardingpass, baggage receipt

verified passport

P1.1

VERIFY

PASSENGERDATA

P1.2

ASSIGN

SEAT

P1.3

WEIGH &

TAG

BAGGAGE

P1.4

ISSUE

BOARDING

PASS

PASSENGER

7/28/2019 DFD Note

58/66

BrianLewis/2010

ACCORDING TO THE BOOK,We Would Do The Aforegoing Exercise In This Way:

1. DRAW THE CONTEXT DIAGRAM

2. COMPILE AN EVENT LIST

a. List those actions which occur in our system and towhich our system must respond

b. The ERD may help us in identifying these

3. DRAW FUNCTIONAL DECOMPOSITION DIAGRAM

a. Illustrate in a hierarchy the major functions (or

sub-systems) in our systemb. Add under each function the events from the

event listc. Draw lower-level DFDs (event diagrams) for those

events which require further understanding

4. ASSEMBLE ALL EVENT DIAGRAMS INTO A

SYSTEM DIAGRAM

5. LEVEL THE SYSTEM DIAGRAM BY PARTITIONING

THE EVENT DIAGRAMSa. Either upwards, grouping related processes into

higher-level DFDs

b. Or downwards, exploding processes into furtherdetail

But since we have limited time, we will go straight fromthe Context Diagram to the System Diagram and then

(optionally) to Event Diagrams

7/28/2019 DFD Note

59/66

BrianLewis/2010

DEVELOPING COSC 2810

PROCESS MODELS




1ST LEVEL (SYSTEM) DATA FLOW DIAGRAM

(identifies major system functions)

2ND LEVEL DATA FLOW DIAGRAMS (OPTIONAL)

(lower-level DFDs for complex processes

in the 1st level Diagram)

7/28/2019 DFD Note

60/66

BrianLewis/2010

Putting each Event Handler process in its own context:

EVENT DIAGRAMS (sets of tasks carried out as a whole)

frequentflyer data

ticket

baggage id,passenger #

PLANE

SEATING

PASSENGER

seat plan

ticket, passport

boarding pass

P1.1

VERIFY

PASSENGER

DATA

P1.2

ASSIGN

SEAT

booking

FLIGHT

occupiedseats

reserved seat

P1.3

WEIGH &

TAG

BAGGAGE

P1.4

ISSUE

BOARDING

PASS

endorsed ticket,boarding pass

verified passport

BAGGAGE

baggage id

FLIGHT

BAGGAGE

PASSENGER

PASSENGER

PASSENGER

7/28/2019 DFD Note

61/66

BrianLewis/2010

If we still dont understand how some

processes work well enough to be able to

write programs, we explode these into:

PRIMITIVE DIAGRAMSof ELEMENTARY PROCESSES

(basic pieces of work)

P1.4

ISSUE

BOARDING

PASS

endorsed ticket,

boarding pass

BAGGAGE

PASSENGER

P1.4.1

RETRIEVE

PASSENGER

& FLIGHT

DATA

P1.4.2

LOOK UP

GATE

NUMBER

P1.4.3

PRINT

BOARDING

PASS

7/28/2019 DFD Note

62/66

BrianLewis/2010

MARRIAGE

The government of Analasia has commissioned you to

do the Analysis & Logical Design of the data of a

system for recording all important data regardingmarriages in the country. Bigamy is forbidden in

Analasia, but divorce is not. The government wants to

be able to query a database to find, for example:

when and where a marriage took place, the woman's

maiden name, which persons were married, who

officiated at the ceremony and whether the parties

were subsequently divorced.

1. Draw an Entity Relationship Diagram of the

marriage relationship between two persons.

2. Illustrate the tables with which you would build to

resolve relationships in the ERD, showing important

attributes, selecting Primary Keys and adding any

appropriate Foreign Keys.

3. Give examples of attributes which, if added, would

violate:

a) First Normal Form,

b) Second Normal Form

c) Third Normal Form

7/28/2019 DFD Note

63/66

BrianLewis/2010

Q1.

This is a Recursive Relationship

each person marries none, one or many persons

each person is married to none, one or many

persons

In understanding a relationship, it helps greatlyto read it aloud, from one direction to the other

And we have to remember that we are designing

a database that should record:

all marriages

and all divorces

of all persons

from the beginning of time until eternity

not instances of one man marrying one woman

PERSONmarries

is married to

7/28/2019 DFD Note

64/66

BrianLewis/2010

Q2.

SSN = Social Security Number Marriage Date needs to be part of the Primary Key of the Marriage associative

entity in case the same couple marry, divorce and then re-marry

Presiding Official is a Foreign Key pointing to the PERSON table where anattribute indicates whether the person is authorised to conduct marriages

MARRIAGE TablePERSON.SSN PERSON.SSN Marriage Date (PK)Wedding Ceremony AddressDivorce DatePresiding Official (FK Person.SSN)

PERSON TableSSN (PK)Last NameFirst NameMaiden NameAddress

SexBirth DateDeath DateMarriage Authority (Y/N)Occupation

marries

is married to

should be "Name at Birth" -

thanks to Michael for

pointing this out

7/28/2019 DFD Note

65/66

BrianLewis/2010

Q3.

a. If we were to put Marriage Date in the Person Tablethis would violate 1st Normal Form. Since a person can

marry more than once we would need a repeating groupof the marriage dates

b. If we were to put Maiden Name in the Marriage Table

this would violate 2nd Normal Form. Since the MaidenName applies to one person only, it is dependent on just

one part of the Primary Key

c. If we were to add the attribute Age to the PersonTable this would violate 3rd Normal Form. Since Age is

dependent on another attribute (the Birth Date). Also,it is not good design to include attributes whose value

changes with time and which can anyway be calculated(from Birth Date).

7/28/2019 DFD Note

66/66

BrianLewis/2010

NORMAL FORMS

FIRST NORMAL FORM (1NF)

NO REPEATING GROUPS

An entity whose attributes have no more thanone value for a single instance of that entity

Any attributes that can have multiple values actuallydescribe a separate entity, possibly an entity andrelationship

SECOND NORMAL FORM (2NF)

THE WHOLE KEY & NOTHINGBUTTHE KEY

An entity whose attributes are dependent on allparts of the primary key

Any attributes that are dependent on only part of theprimary key should be moved to any entity where thatpartial key is actually the full key. This may requirecreating a new entity and another relationship

THIRD NORMAL FORM (3NF)

NO ATTRIBUTES DEPENDON OTHER ATTRIBUTES An entity whose attributes are not dependent on

any other attributes

DFD Note

Documents

Transcript of DFD Note