1. Sofware Engineering Know what SSADM is Data Flow diagrams
Entity relationship diagrams

2. Sofware Engineering Know what SSADM is Data Flow Diagrams
Entity relationship diagrams

3. Stages and sample techniques of SSADM
SSADM = Structured Systems Analysis and Design Method
0: Feasibility
Cost-Benefit Analysis, DFD’s
1: Investigation of Current Requirements
Interviews, questionnaires, observation, documentation review
2: Business Systems Options
3: Definition of Requirements
DFD’s, ER models
4: Technical System Options
5: Logical Design
DFD’s, ER models
6: Physical Design

4. Sofware Engineering Know what SSADM is Data Flow Diagrams
Entity relationship diagrams

5. Data Flow Diagrams Data Flow Diagrams (DFDs)
A Data Flow Diagram (DFD) is a network representation of a system showing the processes and data interfaces between them. 4 Symbols:
SOURCE or DESTINATION of data
name
name
DATA FLOW
name
PROCESS Dn
DATA STORE

6. Data Flow Diagrams 1 2 X Y Z S D P1 P2 W D1

7. Data Flow Diagrams Rules for drawing DFDs 1. Data Flows 2. Processes
between processes, into and out of data stores, to/from destinations/sources
must have arrow to indicate direction
Unique, meaningful and consistent name must be given to the flow
2. Processes
Represent transformations
sometimes drawn as circles or ovals
Name of process should be written - meaningful
Normally data flows in and out of each process 1
Identifier
name
Description of
transformation
xxx
Physical Location 1
create
invoices
sales
office

8. Data Flow Diagrams 3. Data Store
Each process must have a unique number
description - active verb + object clause
3. Data Store
Temporary depository of data
Stores data between processes
Identified by Dn where n is an integer
Data Stores are connected to processes by data flows
Duplicated stores represented by D3

9. Data Flow Diagrams 4. Sources and Sinks show origin/receiver of data
can be duplicated
lie outside the DFD
Name is written inside the symbol
Sometime drawn as
name

10. Data Flow Diagrams Guidelines for drawing DFD
1. Identify all external entities
2. Identify all inputs and outputs
3. Work your way through from Inputs to outputs
4. Label all data flows and data stores descriptively
5. Ignore initialisation/ termination trivia
6. Omit trivial error paths and control logic e.g conditions, loops

11. Tools for Specification - Structured Sys. Analysis
Levelling
High level DFD shows the major processes in a system 1 2 X Y Z S D P1 P2 W D1

12. Tools for Specification - Structured Sys. Analysis
These must be broken down to show the details
Process 2 exploded
2.1
sub-
process 1 1 V Y P1
2.2
sub-
process 2 Z D

13. Tools for Specification - Structured Sys. Analysis
This task is called levelling
Levels are
CONTEXT DFD - the top diagram
the bottom level - procedure which cannot be further decomposed (functional primitives)
the middle levels -everything else

14. Tools for Specification - Structured Sys. Analysis
Guidelines for Levelling
1. Number each process in the context DFD
2. Identify those processes in the overview which need to be decomposed
3. Draw a lower level DFD (child diagram) for each high level DFD which can be decomposed.
4. Number each child to associate it with its parent e.g. the children of process 3.0 may be called 3.1, 3.2 etc.
5. Check inputs and outputs match between parent and child diagrams
6. Repeat the procedure until system is sufficiently described (can be described on 1 A4 sheet)

15. Tools for Specification - Structured Sys. Analysis
Example: A Video Sales System - step by step
The system accepts video orders from customers. These customer orders are checked against a video file (i.e. title and distributor match etc) to ensure they are correct. Also, another file is used to check the customers credit worthiness.
Once a valid order is received it is stored in a pending order file, until a batch of orders is assembled to be sent to a specific distributor.
Each distributor send a delivery note with the video and this is checked with the customer order. Videos are then delivered with a delivery note to the customer. An invoice is also sent for all the orders that a customer has been sent. a copy of this is sent is stored for use by the accounts department. Payment is outside the scope of this investigation.

16. Tools for Specification - Structured Sys. Analysis
Purchase order
customer order
Distributor
Process
Orders
Customer
Context Diagram

17. Tools for Specification - Structured Sys. Analysis
Video File D4
Distributor file
Video details
Distributor details
1.0
2.0
valid
cust-
omer
order
Verify
Order
Valid
Create
Purchase
Orders
Distributor
Customer
purchase
order
customer
order
credit
status
batched order D3
Pending Orders D2
Customer Data
Video
order
details
3.0
address
Assemble
Customer
Orders
invoice
delivery note
delivery note

18. Tools for Specification - Structured Sys. Analysis
Lets take process 3.0, Assemble Customer Orders:
Del. note
3.4 D6
Customer Data
Create
Delivery
Note
Customer D3
Pending Orders
invoice
Customer details
assembled
orders
Video
order
details
assembled
orders
3.3
3.1
3.2
Create
Invoice
Assign
delivery to
pending
orders
Verify
Correct
Delivery
Distributor
delivery note
invoice copy
details
of indiv.
orders D5
A/c Receivable

19. Tools for Specification - Structured Sys. Analysis
Note
video file, distributor file etc.. but no mention of maintenance/ creation
No error conditions dealt with. e.g. invalid order
Levelling continues for each process

20. Tools for Specification - Structured Sys. Analysis
Example: Warehouse
A company makes complicated engineering structures. To operate, the company keeps a large warehouse of parts.
Typically, an internal order for parts is made by the manufacturing division. From these orders a picking list is made and the parts are picked from bins. The quantity in the bins is amended on a notice at each bin. Also, the amended quantity is compared with a reorder level. If the quantity of parts is below this reorder level, then a requisition is made and sent to the purchasing department to order more parts. In this way the quantity of parts is maintained at an acceptable level. Nevertheless, it is possible that an order is only partly filled. An issue notice is sent to the Accounts department so that a record of cost is maintained.
When a part is delivered from the supplier, the goods are checked with the delivery note and the warehouse staff place the parts in their bins and amend the quantities on the bin notices. Discrepancies with the delivery note are dealt with at this time. Outstanding internal orders are then examined to see if they can now be met.

21. Tools for Specification - Structured Sys. Analysis
Accounts
Issue Notice
Internal
Order
Requisition
Operate
Ware-
house
Manufacturing
Purchasing
delivery note
Supplier
Context diagram

22. Tools for Specification - Structured Sys. Analysis
Accounts D5
Parts file D5
Parts file
Part details
issue notice
issue details
Internal
Order
Compare
quantities
with on-
hand
Create
Picking
List
Create
Issue
Notice
Manufacturing
delivery
notification
Receive
goods
picking list
You could decompose this to a lower level
Outstanding
orders D5 D5
Parts file
Outstanding order details
delivery note
Supplier

23. Level Balancing
Child diagram must have exactly the same data flows as the parent
i.e. there is a balance in data content
2 ways
If exactly the same data flows are present in the child then the levels are balanced
If net data content is the same, there is balancing (Wu & Wu, Fig 9-18)
NB: Data stores need not balance - they may be concealed as “unnecessary detail” at a higher level

24. Physical vs Logical DFDs
DFDs model the flow of data through a system
Can be logical or physical
Physical
when any physical object or process is present
Logical
when no physical components are present
Physical = How? i.e. limited to the way things are done
Logical = What? i.e. concerned with what is done
Example – a data store called ‘Sales Notebook’ is a physical data store but ‘Sales File’ is logical.

25. Physical Process processes that use a physical object
e.g. “membership card” is physical, “member details” is logical
process that performs data entry
e.g. “key in payroll data”
processes that only transmit data
e.g. “Send paycheque” is physical
processes that rearrange data
e.g. sort paycheque
payroll data
2.1
key in payroll
data D5
Payroll data D5
Parts file
mailed pay-cheque
2.1
send pay-cheque
3.3
2.4
Check member details
sort pay-cheque
membership
card
sorted pay-cheque

26. Modelling the Proposed System
Model the existing system using DFDs - include physical features
Remove physical aspects
Modify the logical DFDs in 2, to show the new system
Examine the logical DFDs and determine how each part can be implemented
Produce a set of physical DFD’s

27. Data Models DFDs show data flowing through processes
Data Dictionary reveals the contents of the data
This data needs to be converted to a format for files/dbms
Data Model
Data Model helps the analyst to understand and document the logical structure of the data

28. Entity Relationship Model
A graphical description of data entities and the relationship between them
Important as the quality of the design affects the usability and maintainability of the database
ER Model gives an easy way to design a database
Entity - something that exists
Entities have attributes - properties
Each entity has a key which is one or more attributes that can be used to uniquely identify an entity
e.g. Employee(Emp#,EmpName, EmpAddress...)
e.g. Part(Part#,PartName,....)
e.g. Contact(ContactName, ContactCo, Phone, Fax...)

29. NB: SSADM uses for N (we prefer Chen’s notation) Examples
Relationships - exist between 2 (or more) entities - an association between entities Every relationship has a multiplicity: 1 or N
NB: SSADM uses for N (we prefer Chen’s notation)
Examples 1 N
Lecturer advises Student 1 N
COMANY_DIVISION
DIRECTED_DY
DIRECTOR N 1
PRODUCT
COMPOSED_OF
PART

30. Membership of relationships may be
optional - not all occurrences of the entity are members
or mandatory - all occurrences of the entity are members
e.g.
LIBRARY HAS_BRANCH BRANCH 1 N 1 N
BRANCH SHELVES BOOK

31. ER to Relational Database Design (extra)
1 Every entity becomes a table with the same name and attributes. The entity key becomes the table key
2 Relationships must be represented either using foreign keys or creating a separate table
1:1 Relationships
Put the key of one as a foreign key in the other
e.g. Dept-Mgr Manages Department 1 1
DEPT-MGR(Emp#, EmpName)
DEPARTMENT(Dept#, DepartmentName)
DEPT-MGR(Emp#, EmpName)
DEPARTMENT(Dept#, DepartmentName, Emp#)

32. Place the key of the “1” side as an attribute in the “N” side e.g.
OFFICER GUARDS AREA N 1
OFFICER (EMP#, EMPNAME)
AREA(AREANAME)
OFFICER (EMP#, EMPNAME, AREANAME)
AREA(AREANAME)

33. Always create a separate relationship e.g.
N:M
Always create a separate relationship
e.g.
SALESMAN SELLS_TO CUSTOMER N M
SALESMAN(EMP#, EMPNAME)
CUSTOMER(NAME, ADDRESS)
SALESMAN(EMP#, EMPNAME)
CUSTOMER(NAME, ADDRESS)
SELLS_TO(EMP#,NAME, ADDRESS)