1

ECE 355: Software Engineering

Traditional Analysis and Modeling ApproachesLectures notes by

Instructor:Krzysztof Czarnecki

2

Three main views of the traditional approach(Structured Analysis)

• Process/functional view:Data flow diagrams

• Data structures:Entity-relationship diagrams

• Time-dependent behavior:State-transition diagrams

3

Outline for today

• IntroductionData Flow Diagrams

• Entity Relationship Diagrams

• Further Reading

4

Data Flow Diagrams (DFDs)

• A DFD is a graphical representation of– the processes of a system,

– the data being transformed and stored

• A DFD gives a very good overview of what is happening in the system

• A DFD represents– the process view of a system (processes are actions or sets of

actions)

– the functional view (processes as functions)

– (workflow model)

5

Components of a DFD

• DFD is very easy to read since it is a graphical model and

• there are only four symbols to learn:– Processes

– Data Flows

– Data Stores

– External Agents

6

Process

• Processes transform a data flow by changing its structure or by generating new information from it

• A process must have at least one data flow into it and one data flow out of it

• A process cannot exist independently

Validate Customer

Order

<processtitle>

7

Data Flows

• A data flow is represented by an arrow and depicts the fact that some data is flowing from one process to another

• Data moved is sometimes called a packet of data

• The name of data flows should be different if the data is changed on entering the process

verified_order

<flow name>

customer_address

zip_code

phone_#

street_address

8

Data Stores

• When a process needs other data other than what it receives from another process, to perform its function, this ‘other’ data can be retrieved from data stores

• A data store is a collection of related information for example, a telephone book, student records held in a filing cabinet

Orders

<store name>

9

Sources and sinks

• External agents exist in the system’s environment and can:

– provide data to the system (i.e. a source or input) or

– receive data from the system (i.e. a sink or output)

• External entities include people like customers, managers, and include places like departments and suppliers

• The boundaries of a system determine what entities are external

• External agents are also referred to as terminators

Customer

<externalagent

name>

10

Components of a DFD Put Together

Orders

order

part_numbernew_order

Customer

Validate Order

Stock

11

Please note...

• A DFD does not represent any control flow aspect in your system

• Therefore, no sequencing information can be read from a DFD

• However, this lack of control flow is not a drawback of DFD, because what we are modeling using DFDs are requirements and not how those are implemented

• Note: In general, a DFD is not a dependency diagram (where a process produces output whenever all inputs are available)

• Some extensions of DFD for real-time systems consider control flow (e.g., http://www.yourdon.com/books/msa2e/)

12

Direct data flow vs. data store

• The analyst may decide if intermediate data needs to be stored persistently– implied by the

user’s needs

– implicates development cost

13

An alternative notation...

Customer

CustomersD1

ID

Sales Clerk

Validate Customer Order

2

Location

validate_order

Process(rectangle instead a circle!)

Data flow

Data store

External agent(an oval instead of a rectangle)

14

A few comments about notation...

• The modeling notation being used should be appropriate and efficient for the task at hand

• Beyond that it’s a matter of taste– Circle, rectangle, a cloud...

• Use a standard whenever a standard available• In any case, be consistent• Underlying concepts matter

– Surface syntax can be learned quickly...

15

DFD Leveling

• DFDs allow the analyst to look at the system at different levels of detail

• Even quite small systems can be made up of many processes– To include all processes in a single diagram can:

– make it look cluttered,

– make it difficult to see in detail what a process does

• To overcome this, we can ‘break down’ a single diagram, into a number of diagrams

• This process is known as leveling

16

Context Diagrams (Overview or Level 0)

• Represents the system at the highest level of detail.• Comprised of

– A single process representing the entire system modeled

– External entities

– The data flows that pass between the external entities and the system

• Purpose is– to identify and examine the interfaces between the

external entities and the system

17

Example of a context diagram

18

Context diagram for a telephone system

19

Guidelines for drawing a Context Diagram

• List potential external entities (people, places). Look for entities that– give data to the system without explaining the process

that creates that data

– take data from the system without explaining what it does with that data

• Establish what flows are sent to and from the system from the external entities

• Draw the context diagram

20

Level 1 Diagram

• Show– the system in more detail

– how data enters the system

– how these data items are transformed by the processes

– how they leave the system

• A level 1 diagram must have the same number of inputs and outputs as its context diagram

• The flows are connected to and from the actual processes which create, receive or change them

• Processes represent a breakdown of the activities which make up the system

21

Refinement of “Telephone System” processing element in the context diagram

22

Guidelines for drawing a Level 1 Diagram

• Take one sentence at a time and try to identify potential processes (look for verbs)

• Group potential processes so you end up with (minimum) 3 to (maximum) 10

• Identify and list the data flows (generally documents but could also be physical items). A data flow is really anything that moves around the system

• Identify and list the data stores

• Draw the level one diagram

23

Refinement of “PBX” processing element

24

DFD Fragments

• A DFD fragment is created for each event in the event list

• A DFD fragment is a self-contained model showing how the system responds to a single event

• As an analyst, you create DFD fragments one at a time

25

DFD fragment corresponding to the “off hook”

26

Bottom Level

• Continue decomposing a DFD into lower levels until the processes get so simple that you can describe them using:– Process specifications in pseudocode– Decision tables

27

Example of a process specification using pseudocode

1. IF the dollar amount of the invoice times the number of weeks overdue is greater than $10,000 THEN:

a. Give a photocopy of the invoice to the appropriate salesperson who is to call the customer.

b. Log on the back of the invoice that a copy has been given to the salesperson, with the date on which it was done.

c. Refile the invoice in the file for examination two weeks from today.

2: OTHERWISE IF more than four overdue notices have been sent THEN:a. Give a photocopy of the invoice to the appropriate salesperson to call the customer.

b. Log on the back of the invoice that a copy has been given to the salesperson, with the date on which it was done.

c. Refile the invoice in the file to be examined one week from today.

3: OTHERWISE (the situation has not yet reached serious proportions):

...

28

Example of a decision table

29

Data in data flow diagrams

• Data and data stores defined using Entity Relationship Diagrams and data dictionaries

30

Outline for today

• Introduction

• Data Flow DiagramsEntity Relationship Diagrams

• Further Reading

31

Entity Relationship Diagrams (ERD)

• ER diagrams describe things and relationships between them

• They were first proposed by Chen in 1976– Unify different approaches to database design

(hierarchical, network and relational)– Original reference: Peter Pin-Shan Chen. The entity-relationship model—toward a

unified view of data . ACM Transaction on Database Systems. Vol. 1, No 1, 1976, pp 9-36

• Different ERD notations in use, but basically the same underlying concepts

32

Components of ERDs

• Entities: Things about which we want or need to maintain information– E.g., students, courses, suppliers, parts

• Attributes: Properties of entities– E.g. student ID, Course #, course name

• Relationships: – Associations between two or more entities

– Students take courses

• ERDs can represent real world (or even imaginary worlds) in a diagram

33

Example

Student

FName

LName

Address

Course

C#CName

CDescription

takes

Entity(or more precisely: entity set or type)

Entity attribute

Relationship

34

Relationships

• How two or more entities are related (if at all…)• Cardinality

– 1:1 (wife-husband)– 1:N (mother-children)– N:M (grandparents-grandchildren)

• Participation– Total participation

• Every child has a mother

– Partial participation• Not every person has a child

35

Meaning of ER diagrams

wife husband

Entitiesrepresentobject types

Associationsbetweenindividualobjects

1 1

36

One-To-Many Relationship

mother children1 n

37

Many-To-Many Relationship

grandparents

grandchildren

4 m

38

Partial participation

1

39

Kinds of Relationships

• Mathematically, a relationship on the entities E1,..,En is a mathematical relation on E1,..,En, i.e., a subset of the Cartesian product E1 x E2 x…En.

• n gives rise to the arity of a relationship– Binary relationship (n=2)– Ternary relationship (n=3)– N-ary relationships– Unary relationship (n=1; basically, a predicate)

• Most likely represented as an Boolean attribute

• A recursive binary relationship is one where E1 and En is one the same set

40

Attributes

• Atomic: e.g. SSN• Compound: e.g. address (contain other atomic

attributes: street, zip, state. Can expand it to several attributes )

• Multi-valued: e.g. hobbies ( can have more than one hobby. Can expand to a relationship)

• Derived: e.g. age (can be derived from date of birth. You can decide whether you want to store the derived attributes in the database or not)

• Key: An attribute that uniquely identifies a thing

41

ERD Notation

• Different notations– No single standard notation

• Some variations– Using diamond to denote relationships or not– Providing cardinality or not– Way of specifying cardinality

42

Notation used here

+1

1-3,6

Exactly one

Many (zero or more)

Optional (zero or one)

One or more

Numerically specified

Relationship (unrary and binary only)

Entity

43

Summary of Diagrams in the Traditional Approach

• Three main views:– Data flow diagrams - process/functional view

– Entity-relationship diagrams - view of data structures

– State-transition diagrams - view of time-dependent behavior

• Two additional detailed views:– Data dictionary - detailed structure of data

– Process specification - detailed structure of processes

• The above diagram types are used in Structured Analysis– see http://www.yourdon.com/books/msa2e/

• Additional diagram type in Structured Design:– Structure chart (module structure)

44

Further Reading

• Book by Ed Yourdon “Just Enough Structured Analysis”– Online version at

http://www.yourdon.com/books/msa2e/

• Series of articles on ER modeling (discusses available tools):– “Entity Relationship Modeling from an ORM

perspective” by Terry Halpin– see http://www.inconcept.com/JCM/