YOURDON METHODOLGY

STATIC VIEW
Entity Relationship Diagram
-- Shows the
data relationship
FUNCTIONAL
VIEW
Data Flow Diagram
--Shows the
flow of data
BEHAVIOURAL
VIEW
State Transition Diagram
-- Shows the state
behavior of the system
 ENTITY RELATIONSHIP DIAGRAM (ERD)
ERD- It is a detailed logical representation of the data for an organization.

 Data Structure and relationship may be complex

 Data and ownership of Data

(Responsibility of Data administrative group to manage and Control the
essential information of the business)

 Useful Modeling tool for DA group to ensure that system

information is compatible with global

 Help Data Base administrative group who is responsible for efficiently

and effectively DBMS to decide P-key Index or Pointer they will use.

 It highlights the relationship between data which is not modeled by

DFD
 CONCEPTS OF ERD

1.) Entity represented by rectangle , is a collection or set of things of an

organization having common attributes and relationships .
 each plays a necessary role in building the system,
 each of it is described by one or more data elements which
distinguishes it from others

Example: Doctor, patient.

Doctor Patient
 CONTD…
2.) Attribute:
 Represented by ellipse , is used to qualify properties or characteristics
of entity or relationship.

 Example: Student can have attributes as student id, name, age ,

address etc.

name
age
Student id
address

Student
 CONTD…
(i.) Attributes can be simple or complex:
-- Atomic/simple attributes are ones which cannot be decomposed
e.g. age
-- Complex attributes are ones which are composed of other simple or
complex attribute. E.g. Attribute ‘name’ can be composed of
attribute first-name , middle name and last name.

(ii.) Attributes can also be single-valued or multi-valued which is determined

by functionality of attribute. This is a function which maps attribute to
underlying value set. It can be single valued or multi valued.
-- Single-valued attributes are ones which have only a single value associated
for a particular attribute. E.g. Attribute ‘Loan-no.’ can have only a single
value for its entity Loan
 CONTD…
-- Multi-valued attributes are ones which have a set of values for a
particular attribute. It is represented by a double line ellipse.

designati
emp-id
on

name
Phone
Employee no.

E.g. Attribute ‘Phone-no.’ can have more than 1 value for its entity
Employee

’.
Contd.
3.) Primary Key is set of attributes that uniquely
identifies instances of entity or relationship.
-- It is represented by underlining the attribute
-- Example , attribute emp-id can be used to
identify different
instances of entity type employee and thus is
the primary key of
entity type employee.
 CONTD…
4.) Relationship represented by diagonal, is used to represent
association between zero or more entity type through set of concepts
or attribute .

Doctor Examines Patient

Prescribes

Medicine
 CONTD…
4.1.) Degree of relationship
-- Unary : Also called recursive relationship , relationship
between instances of one entity type
-- Binary : Association between two entities type
-- Ternary: Association between three entities type

A.) Unary relationship

Works
Employee
for
 CONTD…
B.) Binary relationship

Registered
Student Programme
for

C.) Ternary relationship

Teacher

Student May Subject

have
 CONTD…
4.2) Cardinality of relationship

Consider a relationship R between A and B , the

cardinality of R is the number of instances of B that can
be associated with each instance of A.

Cardinality can be:

 1:1 One instance of A is connected to one instance of B
 1:m One instance of A is connected to ‘m’ instances of B
 m:n ‘m’ instances of A is connected to ‘n’ instances of B
 1:[m..n] One instance of A is connected to m to n instances
of B
 CONTD…
4.2) Cardinality of relationship
Is
Person Married Manages
Employee
to

One to One One to many

STUDENT Registers COURSE

for

Many to many
 CONTD…

1 1 M.Tech
Student takes
(One- to- one) course
1 m
Programme registers Student
(One-to many)
m m
Student registers Subject
(Many- to- many) for

4.3.) Role
 In the relationship, entity type plays different roles.
 Roles are specified by writing the role names on different sides of
relationship as shown :
 CONTD…
B.) Binary relationship Category

Worker Works for Employer

Employee Samsung

C.) Ternary relationship

Teacher

Instructor

Learner May Knowledge

Student Subject
have Source
 CONTD…
Issue date

4.4.)

Student Issues Book

Relationships can also have attributes

E.g. Many students enrolling in several courses
get grades in these courses which can be
represented as attribute as of relationship ‘enroll’.
 Relationships can also have a Primary key
 CONSTRAINTS
 Every relationship should have an entity attached to it and vice versa.
 Every entity should have a unique primary key.
 There cannot be more than one primary key associated with a single
entity.
 Every attribute should be attached to either relationship or entity
 Every relationship should have Cardinality specified and vice versa.

Click to open linked file

(ER diagram)
 DATA FLOW DIAGRAM (DFD)
 Emphasis the flow of data in a system and ignores the procedural
aspects.

 DFDs model the system from a functional perspective.

 Tracks and documents how the data associated with a process is

helpful to develop an overall understanding of the system.

 Shows the data exchange between a system and other systems in

its environment.
 CONCEPTS OF DFD
1.) Processes represented by circles. It transforms input into output.
Ex. Compute- Tax, Validate Phone-no

2.) Data flow, arrows between processes represent the flow of

information from one part of the system to another. It is data in
motion..bit, characters, messages, numbers. Data can be partial or
full .

A B C
P1 P2
 CONTD….
 Multiple input data streams and multiple data output streams are
possible.
-- If two adjacently placed inputs are both required then a * is placed
between these.
A
*
B

-- If either of two adjacently placed inputs are required then a ring-sum is

placed between these.
A
+
B
 CONTD…
3.) Data stores represented by parallel lines or open rectangle. It is
collection of data packets at rest.

Data Store Data Store

 Store exist because of user’s requirement or convenient

implementation.

 A flow from Data store can be single, partial or collection of data

packets.

 A flow to data store can be write, delete or update data packets

 CONTD…
4.) Data Terminators represented by closed rectangle.
They are also data stores but they are outside the System and can not
be changed by modeler.

Click to open linked file

 STEPS IN BUILDING DFD
 Choose meaningful name for processes, data flow, data
stores and data terminators
 Number the processes, this is useful in drawing leveled
DFD
 Work from input to the output, output to the input, or
middle-out
 Only show the flow of control. Ignore initialization and
termination, assume the system never stops.
 Omit simple error paths from each transform to the outside
world
 Use the * and ring-sum operators as appropriate
 CONTD…
 Draw DFD as many times as required till it satisfies user and is
technically correct, neat and clear

 Avoid over complex DFD ( not more than 6 processes on one page)

 DFD should be internally consistent and consistent with outside word

(every process should have input and output, beware of read only and
write only stores)

 Each of the data terminator should be connected to at least one

process.

 There should be inflow or outflow from each data terminator.

 LEVLES OF DFD
- DFD can represent the system at any level of abstraction, with each
level representing increasing information flow and functional detail.
- Complexity of circle determines number of levels
- Different parts of the system may have different number of levels.
Zero Level- DFD
 Also called a fundamental system model or Context diagram
 Represents the entire software system as a single bubble with input

and output data. x1

Y
x2 P
 LEVLES OF DFD (CONTD…)
Levels should be consistent : Guideline
Flows coming into/going out of a circle at one level must
correspond to the flows into/out of an entire figure at the
next lower level which describes the circle.
 LEVLES OF DFD (CONTD…)
Data stores at different levels : Guideline
Show store at highest level where it is an interface between circles. Then
show at every level below, which further describes the interface circle.
DS

Level 1

DS
Level 2
Levelled Data Flow Diagram
Entity A Context Entity B
Diagram

Entity A 1 2 Entity B

1.1 1.2 2.1 2.2

Entity A
1.3 2.3

3.1 3.2 Entity B

LEVELLED DFD
Development Heuristics
 At each level no more than 6 circles + related stores
 Each process should be leveled and numbered accordingly .
 The data flow should be correct for the level of detail concerned
 Levels should be consistent with each other i.e. Flows coming
into/going out of a circle at one level must correspond to the
flows into/out of an entire figure at the next lower level which
describes the circle.
 Process specification of each circle should fit in one page else
make another level
 0 - LEVEL DFD FOR COLLEGE
REGISTRATION SYSTEM

Registration Rejection
Registration Confirmation Collect Fees
Receipts Accountant
1 Issue Receipts
Fees College
Registrar Registration Application form
Request for Form System Confirmation Registrar
Issue form Rejection
Submit form
Return form for correction
FIRST- LEVEL DFD FOR COLLEGE
REGISTRATION SYSTEM
 Issue Receipts Collect Fees
Pay Fees 1.2
Student Accountant
Request Accounting
Issue
for Form Process
Form Issue Receipts
Enquiry
1.1
Update
Registration Record
Enquiry Student Record
Process
Check Student
Status
Application
Submit Form Form
Registration Confirmation 1.3
Registration Rejection Registrar
Registration
Return Form for Correction Process Confirmation
Rejections
2- LEVEL DFD (ONLY REGISTRATION PROCESS – 1.3)

STUDENT RECORD

Authenticate student
Return form
for correction 1.3.1 1.3.2
FORM Form verified VALIDITY
Submit form VERIFICATION CHECKING
PROGRESS PROCESS

Send form after

authentication

Confirmation note 1.3.3

REGISTRATION Form
REGISTRAR
Rejection note PROCESS
Confirmation

Rejection
 DATA DICTIONARY

- Listing of all data items

- For user/analyst communication

Contains

 meaning of flows/stores

 composition of data packets/stores

 values and units of elementary pieces of information in

flows/stores
 details of relationships between stores
 CONVENTIONS
 ** Comments

 [] One of several choices

 @ Key field of a store

 | Choice

 = Composed of

 + and

 () optional

 n{}m at least n, at most m

 {}m zero or more, at most m

 EXAMPLE
 name = courtesy title + first_name + (middle_ name) + last_
name

 courtesy_ title= [Mr.| Mrs.| Miss.| Dr.| Prof.]

 first_name = { legal_character}
 middle_name = { legal_character}
 last_name = { legal_character}
 legal_character = [A-Z| a-z| 0-9| , |…..]

 customer_ address= [shipping_ address | Billing_address|

shipping_address + billing_address]
 CONTD…
 shipping_address = city_code + state_code +house_No.
 Purchases = @ customer + 1{@ item_id + quantity_ purchased}
 Weight = * patient weight upon admission to hospital *
* Units: Kg, range: 1—200*
Checks

 Every flow on DFD has been defined

 All component of composite items have been defined

 All elements in data dictionary are referred in DFD

 Notations are correct, no element is defined more than once

LINK TO RAILWAY RESERVATION SYSTEM