Post on 16-Jan-2016
transcript
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 1
Software Engineering
Chapter 11: Structured Analysis Techniques
(loosely based on SSADM)
Learning OutcomesKnow what SSADM is
Be able to draw a levelled set of Data Flow diagrams
Be able to draw Entity relationship diagrams
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 2
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 3
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 4
1 2
P1 P2S D
D1
X Y Z
W
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 5
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 6
• 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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 7
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 8
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 9
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 10
These must be broken down to show the details
Tools for Specification - Structured Sys. Analysis
1
P1
Process 2 exploded
2.1
sub-process 1
2.2
sub-process 2
Y V
DZ
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 11
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 12
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)
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 13
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.
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 14
Tools for Specification - Structured Sys. Analysis
ProcessOrdersCustomer
Distributor
Context Diagram
customer order
Purchase order
delivery note
invoice
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 15
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 16
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 17
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 18
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.
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 19
Tools for Specification - Structured Sys. Analysis
OperateWare-house
Manufacturing
InternalOrder
Accounts
Issue Notice
Purchasing
Requisition
Supplier
delivery note
Context diagram
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 20
Tools for Specification - Structured Sys. Analysis
Manufacturing
InternalOrder
CreatePickingList
Comparequantitieswith on-hand
D5 Parts fileD2 Parts file
Part details
D5 Parts fileD1Outstandingorders
picking list
CreateIssueNotice
issue details
Accounts
issue notice
Supplier
delivery note
Receivegoods
deliverynotification
Outstanding order details
You could decompose
this to a lower level
1.0
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 21
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 22
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.
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 23
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 24
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 25
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 26
Entity Relationship Model (aka Logical Data 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...)
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 27
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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 28
• 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
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 29
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#)
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 30
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)
Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk Slide 31
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