Академический Документы
Профессиональный Документы
Культура Документы
Introduction
SSADM What is a Data Flow Diagram? Why do we use DFDs? Levelling Conventions Decomposition and Abstraction The Elements Process and Data Stores Outside Entity Data Flow The Levels Rules The Procedure for Constructing DFDs The Document Flow Diagram The Context Diagram Draw the external entities and data stores Level 1 Physical DFD - Complete
S.S.A.D.M.
S.S.A.D.M. - Structured Systems Analysis and Design Method Uses different techniques to model a system Data Flow Diagrams Entity Relational Model (Logical Data Stores) Normalisation
Levelling
DFDs are expanded or decomposed into levels. Separating each process into sub processes Uncovers more and more detail
Conventions
Balancing Process at lower level should have identical data flows if they flow out of a process Modelling Data Stores Only use DATA STORES used within this process on the diagram Numbering 1 - 1.1 - 1.1.1 1.2 - 1.2.1 Labels Should carry as much meaning as possible
The Elements
The four main elements of DFDs notation Data Flows, with a label to indicate what data is flowing Processes, that handle the data Data stores, within the system (diary, filing cabinet or computer file) Outside entities, outside sources of data
Data Stores
Can be M for manual or D for computer base data stores. M1
Name of Store
Outside Entity
Is anything outside the system that is of interest to the system. Can be a person, a company or another system.
Customer a
Outside entity shows the Name and a lowercase alpha character is used to uniquely identify it.
Customer a
If an outside entity is repeated for the purpose of neat layout a line is added across the top.
Data Flow
Is shown by a line with an arrowhead, indicating the direction of the flow of data. Each data flow should be named to indicate what data is being passed. Nouns or adjectives only no verbs are permitted.
The Levels
Context - Overview contains only one process Level 1 - Utilises all four elements Level 2 - A breakdown of a level 1 process Level 3 - A breakdown of a level 2 process There is no rule as to how many levels of DFD that can be used.
Rules
Sequence not important - getting the Process correct is
Context or Level 0 - Identifies the system/ boundary/External Links Level 1 - Overview of function Level 2 - Breakdown to Understand Hard to know where to stop Rule of Thumb If there are more than 8 data flows break it Process of Identifying major Processes
Supplier
Stock Control
Purchasing
Bill of Materials
Factory
Design
a Production Planning
Production Plan
b Supplier
Delivery Note
e Design
Bill of Materials
c Purchasing
d Factory
All data flows going into the system must be received by a process. All data flows going out of the system must be generated by process. The first task is therefore to identify these processes:
1
Stock cler k M aintain planned call- off
a Production Planning
Stock clerk
M1 Bill of materials
Maintain planned call-off
b Supplier
M2
Stock cards
c Factory
2 Stock clerk
Maintain stock cards
3
d Purchasing
B O M details
M1 Bill of materials
Planned call-off details b Supplier Delivery note c Factory Stock withdrawal note Updated supply details Delivery note Material requirements list
(Lejk & Deeks)
M2
Stock cards
Stock details
2 Stock clerk
Maintain stock cards Stock details
Stock clerk
d Purchasing
M2 Appointment diary
Confirmation of arrival
3
(Lejk & Deeks)
Conduct appointment
Process 3 Level 2
3 Client a Clie a
Hair/Reception
3.1
3.2
Hairdresser
3.3
Complete Appointment
Level 2
2.2
Level 3
Level 4
2.1.1 Elementary process descriptions. Decision trees Decision table Structured English
3 Process Man
There must be consistency between levels, with all the data appearing on the higher level DFD. If a data store is used only for one process it is placed with that process. Outside entities are always shown outside the boundary of a lower level DFD process, even if they only communicate with that one process.
Summary SSADM What a DFD is & Why we use them The different conventions What the elements are Example Next Week:- Entity Relational Model