Sofware Engineering

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 DFD’s, ER models 3: Definition of Requirements 5: Logical Design 4: Technical System Options 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 • 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 • 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 V 1 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 D4 Distributor file D1 Video 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: 3.4 Del. note D6 Customer Data Create Delivery Note Customer D3 Pending Orders Customer details invoice 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 2.4 3.3 sort pay-cheque Check member details 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. 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. 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)

33. 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)