TDT4175 - Information Systems, Spring 2006
TDT4175 - Information Systems, Spring 2006
This week:
„
Today: introduction to modelling in general
„
Today and tomorrow
z
Today:
Introduction to Modelling
and DFDs
z
What is it? Why use it? Types of models
Introduction to Data Flow Diagrams
‹
„
(Hawryszkiewycz, ch.8)
z
Easier to learn new modelling techniques if you
z
Preparation for Customer-Driven Project
z
Basis for course TDT4250 Modelling of Information Systems
‹
John Krogstie, IDI
„
TDT4175 - Information Systems, Spring 2006
2
TDT4175 - Information Systems, Spring 2006
Now jumping to chapter 8
Overview of traditional types of IS
z
„
DFDs and similar models much used in industry
1
Last week
„
Know some existing ones, and have a general overview
Why is this useful to you as a practitioner
z
DFD1.ppt
Notation, examples, working method
Why is this useful to you as a student?
„
Ch1, 2,3
Because
z
Chapter 4 (on requirements analysis): dealt with later
z
Chapter 5, 6 (life-cycles, proj.mgmnt): assumed known
z
Chapter 7 (strategical issues): dealt with later
New trends and relevant system types
‹
‹
„
Related to stuff in Pearlson book
But before going into Data Flow Diagrams…
z
z
Some introduction to modelling in general
‹
What is a model?
‹
Why make models?
‹
What to model?
What different modelling languages are there?
‹
3
Not included in the readings
And why does this course focus on DFDs?
4
1
1
TDT4175 - Information Systems, Spring 2006
Introduction to modelling
„
What is a model?
z
„
A simplified representation of a real or planned system,
enterprise or product, e.g.,
‹
‹
‹
‹
z
TDT4175 - Information Systems, Spring 2006
Why use models?
An architect’s cardboard model of a building set in a
certain landscape
A mathematical model of a car’s stopping length with a
certain type of ABS brakes on various road surfaces
„
A CAD tool construction drawing of a planned brigde
Purposes of modelling
z
Basis for dialogue
z
Understanding problems with current systems
z
Planning / designing new systems
z
Documentation of built systems
Why not simply look at or make ’the real thing’?
z
A model of current and planned business processes and
IS solutions in company X
Simplified is a key word here:
‹
Why?
‹
And are the requirements towards the simplifiction?
A model may be simpler / easier
‹
to understand
‹
to discuss and change
z
A model can be experimented with
z
A model can facilitate planning and estimation
‹
at lower cost and risk than ’the real system’
5
TDT4175 - Information Systems, Spring 2006
Modelling is essential in many types of projects
„
In package-oriented projects:
z
z
‹
Need models of existing DBs / sources to be integrated
‹
Need integrated model of DW’s DB
‹
Dimensional models of various users’ information needs
„
External models
z
z
E.g., process modelling in ERP, EAI or workflow projects, e.g.
‹
„
TDT4175 - Information Systems, Spring 2006
Many kinds of modelling techniques (Bray, 2002)
E.g., information modelling in data warehouse projects
‹
„
6
Find out whether an ERP package supports existing process or it
must be changed
Configure the ERP package to the customer’s processes
„
Understanding the current situation
z
Requirements model for the new system
In business process re-engineering
7
‹
Static: screen diagrams
‹
Dynamic: throw-away prototypes
Behavioural
‹
Funtional: e.g., decision tables, use cases
‹
State-based: e.g., finite state machines, Petri nets
Internal models
z
In custom-development projects:
z
Representational
Process oriented
‹
Communicating concurrent processes, e.g., DFDs
‹
Communicating sequential proc., e.g., structure charts
‹
Single process, e.g., pseudo code, flow charts
z
Data oriented, e.g. ER
z
Process / data combination, e.g.
‹
Entity life histories (ELH)
‹
OO class models
8
2
2
TDT4175 - Information Systems, Spring 2006
TDT4175 - Information Systems, Spring 2006
Why focus on Data Flow Diagrams ?
„
Much used in industry
z
Rumours that UML has taken over completely are
exaggerated
z
Not taught in Sw.eng. or DB course
‹
Cf investigation from Australian industry in 2002
(Rosemann)
‹
While UML and ER were
‹
But UML Activity Diagrams covered in InfoSys
‹
„
Today:
Introduction to Data Flow Diagrams
(Hawryszkiewycz, ch.8)
Connecting with what you know from before
Basis for understanding several more advanced
languages for
z
Business process modelling
z
Workflow modelling
9
TDT4175 - Information Systems, Spring 2006
Litt administrativt
John Krogstie, IDI
DFD1.ppt
10
TDT4175 - Information Systems, Spring 2006
Overview of the lecture
„
Data Flow Diagrams, intro
„
Husk at beskjeder blir lagt ut på siste nytt
z
Central concepts
„
Melde dere på mailingslisten
z
Diagram notation
„
Trenger personer til å sitte i referansegruppen for
faget
„
Endring av rom: Fredagsforelesningen foregår på
R9 (ikke R5) fremover
„
Neste uke: Øvingsforelesning på torsdagen vise
hvordan man bruker DFD diagrammer på et
eksempelcase.
„
„
11
Relationship between DFDs and other techniques
z
Placement in (Bray, 2002) classification of modelling
techniques
z
DFD vs use cases
z
DFD vs ER diagrams
z
DFD vs UML class and sequence diagrams
z
(DFD vs UML activity diagrams)
Examples
12
3
3
TDT4175 - Information Systems, Spring 2006
DFD – central concepts
„
„
„
„
TDT4175 - Information Systems, Spring 2006
DFD - notations
Processes
z
Show what the system does
z
May be automated or manual
z
Typical naming: verb + noun
„
Several dialects for how to write DFDs
diagrammatically, cf. Fig 8.1
„
The most used are:
Data stores
z
Contains data retained in the system
z
…electronically or otherwise
z
Data are produced by, and used by, processes
z
The stores themselves are passive
„
z
DeMarco notation (used in the textbook)
z
Gane/Sarson notation
Types of diagrams
z
External entities (do not confuse these with ER entities!)
z
Are outside the system, supply or receive data
z
May be a person, organization, a computer system, …
Connect the above three
z
Show the flow of data
‹
‹
Showing the entire system as one process, cf. Fig 8.2
‹
Including external entities, but no stores
z
Top level diagram:
z
Lower level diagrams:
‹
Data flows
z
Context diagram:
‹
Process ↔ process; process ↔ store; process ↔ external entity
Several processes + stores, cf. Fig 8.3
Decompose a top level process into several sub-processes, cf.
Fig 8.4
‹
Can be done recursively
‹
Do not decompose too far, cf. Fig. 8.5
13
TDT4175 - Information Systems, Spring 2006
Relationships to other techniques (1)
„
Use cases
z
z
TDT4175 - Information Systems, Spring 2006
Many kinds of modelling techniques (Bray, 2002)
„
‹
External entities ≈ use case actors
‹
DFD processes ≈ use cases
‹
Both showing activities performed
‹
Both named ”verb + noun”
Decomposition ≈ ”includes” relationship
While some of the above sub-items are true, the two
kinds of models are really quite different
‹
Show different things
‹
Used for different purposes
A use case model is external while a DFD model is
internal
15
External models
z
Common mistake: ”DFD’s and UC’s almost the same”
‹
z
14
z
„
Representational
‹
Static: screen diagrams
‹
Dynamic: throw-away prototypes
Behavioural
‹
Funtional: e.g., decision tables, use cases
‹
State-based: e.g., finite state machines, Petri nets
Internal models
z
Process oriented
‹
Communicating concurrent processes, e.g., DFDs
‹
Communicating sequential proc., e.g., structure charts
‹
Single process, e.g., pseudo code, flow charts
z
Data oriented, e.g. ER
z
Process / data combination, e.g.
‹
Entity life histories (ELH)
‹
OO class models
16
4
4
TDT4175 - Information Systems, Spring 2006
Relationship to other techniques (2)
„
DFD vs ER
z
„
„
OO class and sequence diagrams
z
Internal like DFD and ER
‹
Shows the structure of data (static)
z
Data + process
‹
While DFD shows processing activities
z
Advantages:
Both ”internal”, but ER is data-oriented
z
I.e., very little overlap
z
But there will be many links between the two
‹
„
TDT4175 - Information Systems, Spring 2006
Relationship to other techniques (3)
‹
cover everything with one (?) model
‹
Easier transition to OOD
‹
The data that flows, and resides in the stores will be the
same data whose structure is modelled in ER diagrams
z
Disadvantages
‹
The process aspects are hidden within objects
‹
The model is more complex, difficult to understand for non-techs
‹
Sometimes, a transition to OOD is not very interesting
Often, these two diagram types will be used
together
Will lecture about this later
z
two supplementary models needed for ER + DFD
last three pages of chapter 9
‹
Only visible through method calls
‹
Must potentially look at a whole lot of sequence diagrams
‹
business process improvement
‹
acquisition and adaptation of package products
17
TDT4175 - Information Systems, Spring 2006
Relationship to other techniques (4)
„
UML activity diagrams
18
TDT4175 - Information Systems, Spring 2006
Logical vs. physical DFDs
„
Logical DFD, ex. Fig 8.8 (a)
z
Belongs to the ”subject world”
z
Internal like DFD
z
Show what is done
z
In many ways quite similar
z
But not how, or by whom
‹
z
UML activities ≈ DFD processes
But also notable differences:
‹
z
„
Activity diagrams: single processes from start to end
‹
One diagram per process
‹
Explicitly showing sequence, branching and parallellism
‹
Swimlanes: who does what?
Helps analysts gain a clear perception about what should be
achieved
Physical DFD, ex. Fig 8.8 (b)
z
Belongs to the ”usage” world
z
Show how things are done
z
By whom, automated or not
z
Indicating physical components / persons
z
Often easier to start with when modelling a current system
‹
‹
DFD’s: modelling entire systems
‹
External entities showing where data comes into the
system, and where it is output
„
19
sometimes naming processes just by noun, not verb + noun
Often: start with a physical DFD, then convert to logical
20
5
5
TDT4175 - Information Systems, Spring 2006
Conversion physical → logical
TDT4175 - Information Systems, Spring 2006
Tomorrow
„
Example, fig 8.9
„
Continuing with Hawr ch.8
„
Steps
„
More on logical and physical DFDs
„
Guidelines for how to make good DFDs
„
Levelling of DFDs
1.
Remove all physical processes that refer to physical
activities only and do not transform information
2.
Replace other physical processes by a leveled DFD of
logical functions that represent the physical object’s
logical activities
3.
Combine common or similar functions to make a top
level logical DFD
z
More examples: figs 8.10-12
z
Bigger example: figs 8.13-16
21
TDT4175 - Information Systems, Spring 2006
22
TDT4175 - Information Systems, Spring 2006
Overview of the lecture
Today:
„
More on logical and physical DFDs
„
Guidelines for how to make good DFDs
„
Levelling of DFDs
Data Flow Diagrams - continued
(Hawryszkiewycz, ch.8)
Guttorm Sindre, IDI
DFD1.ppt
23
24
6
6
TDT4175 - Information Systems, Spring 2006
Guidelines for making good DFDs (1)
„
No control elements (cf fig 8.17), avoid
z
„
„
Naming: be specific!
z
Branching and looping flows
‹
z
TDT4175 - Information Systems, Spring 2006
Guidelines for making good DFDs (2)
Instead done inside process description, cf 8.18, 8.19
z
Process activation signals
Names with little meaning: impossible to understand the
diagram, cf fig 8.21
Processes:
‹
Name: one phrase (normally verb + noun phrase)
‹
Action possible to describe in one sentence
‹
Layout:
z
avoid crossing lines if possible
z
Normal flow direction: upper left to lower right
z
Double arrows between process and stores
z
Stores
‹
Noun phrase (with dashes if several words)
‹
‹
„
z
instead of two different arrows
Conservation of data
z
Processes or stores cannot create data, cf 8.20 (b)
z
And should normally not lose data either, 8.20 (a)
„
TDT4175 - Information Systems, Spring 2006
Leveling (decomposition)
„
Necessary for readability of large diagrams
z
„
Normally one word
‹
Possibly add state info to remove ambiguity, fig 8.22
If needed: use special notation (e.g., fig 8.23)
26
TDT4175 - Information Systems, Spring 2006
Two ways of arriving at a DFD model
„
From a system description
1.
Start with (stores and) flows, follow them through
the system, cf. Fig 8.28
2.
Start with top level processes, decompose, cf.
Fig 8.29
Use numbering to indicate position in the structure
‹
Cf fig 8.24
z
No new external entities
z
Use stores only when referenced by >1 process
z
Data flow balancing (but not always)
‹
„
‹
And the understanding of large systems
Conventions
z
E.g., APPROVED-INVOICES
Flows
Material flows: normally not included
z
25
E.g., Verify invoice
Cf. Data flow expansion, Fig 8.25
# of processes per level
z
or subprocesses within a process
z
”around 7”;
”4 to 7”
27
28
7
7