Post on 05-Feb-2016
description
transcript
Phạm Văn Sim Anh –Aprotrain-Aptech
Sofware Engineering
Know what SSADM is Data Flow diagrams Entity relationship diagrams
Phạm Văn Sim Anh –Aprotrain-Aptech
Know what SSADM isData Flow DiagramsEntity relationship diagrams
Sofware Engineering
Phạm Văn Sim Anh –Aprotrain-Aptech
Stages and sample techniques of SSADM
0: Feasibility
1: Investigation of Current Requirements
SSADM = Structured Systems Analysis and Design Method
2: Business Systems Options
3: Definition of Requirements
4: Technical System Options 5: Logical Design
6: Physical Design
Cost-Benefit Analysis, DFD’s
Interviews, questionnaires, observation, documentation review
DFD’s, ER models
DFD’s, ER models
Phạm Văn Sim Anh –Aprotrain-Aptech
Know what SSADM isData Flow DiagramsEntity relationship diagrams
Sofware Engineering
Phạm Văn Sim Anh –Aprotrain-Aptech
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:
name SOURCE or DESTINATION of data
DATA FLOWname
name
Dn
PROCESS
DATA STORE
Phạm Văn Sim Anh –Aprotrain-Aptech
1 2
P1 P2S D
D1
X Y Z
W
Data Flow Diagrams
Phạm Văn Sim Anh –Aprotrain-Aptech
Rules for drawing DFDs
1. Data Flows• 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
name
xxx
Identifier
Description oftransformationPhysical Location
1
create invoicessales office
Data Flow Diagrams
Phạm Văn Sim Anh –Aprotrain-Aptech
• 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
Data Flow Diagrams
Phạm Văn Sim Anh –Aprotrain-Aptech
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
Data Flow Diagrams
Phạm Văn Sim Anh –Aprotrain-Aptech
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
Data Flow Diagrams
Phạm Văn Sim Anh –Aprotrain-Aptech
Tools for Specification - Structured Sys. Analysis
Levelling High level DFD shows the major processes in a system
1 2
P1 P2S D
D1
X Y Z
W
Phạm Văn Sim Anh –Aprotrain-Aptech
These must be broken down to show the details
1
P1
Process 2 exploded
2.1
sub-process 1
2.2
sub-process 2
Y V
DZ
Tools for Specification - Structured Sys. Analysis
Phạm Văn Sim Anh –Aprotrain-Aptech
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
Phạm Văn Sim Anh –Aprotrain-Aptech
Tools for Specification - Structured Sys. Analysis
Guidelines for Levelling1. Number each process in the context DFD2. Identify those processes in the overview which need to be
decomposed3. 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
diagrams6. Repeat the procedure until system is sufficiently described (can
be described on 1 A4 sheet)
Phạm Văn Sim Anh –Aprotrain-Aptech
Tools for Specification - Structured Sys. Analysis
Example: A Video Sales System - step by stepThe 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.
Phạm Văn Sim Anh –Aprotrain-Aptech
Tools for Specification - Structured Sys. Analysis
ProcessOrdersCustomer
Distributor
Context Diagram
customer order
Purchase order
Phạm Văn Sim Anh –Aprotrain-Aptech
Tools for Specification - Structured Sys. Analysis
CustomerVerifyOrderValid
1.0
D2 Customer Data
D1 Video File
Video details
customerorder
D3 Pending Orders
CreatePurchaseOrders
2.0validcust-omerorder
Distributor
purchaseorder
batched order
AssembleCustomerOrders
3.0
creditstatus
invoice
Videoorderdetails
D4 Distributor file
Distributor details
delivery notedelivery note
address
Phạm Văn Sim Anh –Aprotrain-Aptech
Tools for Specification - Structured Sys. Analysis
Lets take process 3.0, Assemble Customer Orders:
D3 Pending Orders
Videoorderdetails
Distributor
Assigndelivery topendingorders
3.1
delivery note
Customer
CreateInvoice
3.3
VerifyCorrectDelivery
3.2
D5 A/c Receivable
invoice copy
invoice
detailsof indiv.orders
assembledorders
CreateDeliveryNote
3.4Del. note
assembledorders
D6 Customer Data
Customer details
Phạm Văn Sim Anh –Aprotrain-Aptech
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
Phạm Văn Sim Anh –Aprotrain-Aptech
Tools for Specification - Structured Sys. Analysis
Example: WarehouseA 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.
Phạm Văn Sim Anh –Aprotrain-Aptech
Tools for Specification - Structured Sys. Analysis
OperateWare-house
Manufacturing
InternalOrder
Accounts
Issue Notice
Purchasing
Requisition
Supplier
delivery note
Context diagram
Phạm Văn Sim Anh –Aprotrain-Aptech
Tools for Specification - Structured Sys. Analysis
Manufacturing
InternalOrder
CreatePickingList
Comparequantitieswith on-hand
D5 Parts fileD5 Parts file
Part details
D5 Parts fileD5Outstandingorders
picking list
CreateIssueNotice
issue details
Accounts
issue notice
Supplier
delivery note
Receivegoods
deliverynotification
Outstanding order details
You could decompose
this to a lower level
Phạm Văn Sim Anh –Aprotrain-Aptech
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
Phạm Văn Sim Anh –Aprotrain-Aptech
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.
Phạm Văn Sim Anh –Aprotrain-Aptech
membership
card
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
Check member details
3.3
key in payrolldata
2.1
D5 Parts fileD5 Payroll data
payroll data
send pay-cheque
2.1mailed pay-cheque
sort pay-cheque
2.4
sorted pay-cheque
Phạm Văn Sim Anh –Aprotrain-Aptech
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
Phạm Văn Sim Anh –Aprotrain-Aptech
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
Phạm Văn Sim Anh –Aprotrain-Aptech
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...)
Phạm Văn Sim Anh –Aprotrain-Aptech
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
Lecturer advises Student
COMANY_DIVISION DIRECTED_DY DIRECTOR
PRODUCT COMPOSED_OF PART
1 N
1 N
1 N
Phạm Văn Sim Anh –Aprotrain-Aptech
• 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
BRANCH SHELVES BOOK
N1
1 N
Phạm Văn Sim Anh –Aprotrain-Aptech
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 Department1 1
DEPT-MGR(Emp#, EmpName)
DEPARTMENT(Dept#, DepartmentName)
DEPT-MGR(Emp#, EmpName)
DEPARTMENT(Dept#, DepartmentName, Emp#)
Phạm Văn Sim Anh –Aprotrain-Aptech
1:N
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)
Phạm Văn Sim Anh –Aprotrain-Aptech
N:M
Always create a separate relationship
e.g.
SALESMAN SELLS_TO CUSTOMER
SALESMAN(EMP#, EMPNAME)
CUSTOMER(NAME, ADDRESS)
SALESMAN(EMP#, EMPNAME)
CUSTOMER(NAME, ADDRESS)
SELLS_TO(EMP#,NAME, ADDRESS)
N M