sofware engineering

Phạm Văn Sim Anh –Aprotrain-Aptech

Sofware Engineering

Know what SSADM is Data Flow diagrams Entity relationship diagrams


Know what SSADM isData Flow DiagramsEntity relationship diagrams

Sofware Engineering


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


Know what SSADM isData Flow DiagramsEntity relationship diagrams

Sofware Engineering


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


1 2

P1 P2S D

D1

X Y Z

W

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

name

xxx

Identifier

Description oftransformationPhysical Location

1

create invoicessales office

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

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

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

Data Flow Diagrams


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


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




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



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)



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.



ProcessOrdersCustomer

Distributor

Context Diagram

customer order

Purchase order



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



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



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



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.



OperateWare-house

Manufacturing

InternalOrder

Accounts

Issue Notice

Purchasing

Requisition

Supplier

delivery note

Context diagram



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


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


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.


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


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


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


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


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


• 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


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#)


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)


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

sofware engineering

Documents