Unit-3

Data Oriented
Analysis & Design
1
Modelling
• A model is an abstraction of something for the purpose of
understanding it before building it.
• Both physical models and computer models are usually cheaper
than building a complete system.
• Communication with customers
• Visualization
• Reduction of complexity
• Abstract view of the system

2
Class Model
• A class describe a group of objects with the same properties.
• Objects in a class have the same attributes and behaviour.
• Class diagram provides a graphical notation for modelling classes
and their relationships.

3
Attributes and Operations
• An operation is a function or procedure that may be applied to or
by objects in a class.
• A method is the implementation of an operation for a class.

4
Links and Associations

5
Multiplicity

• Multiplicity specifies the number of instances of one class that may

relate to single instance of an associated class.
• Ex: 1; 1…* ; 3…5 ; 0…1 ; *
• Multiplicity is constraint on cardinality.

6
Generalization

• Relationship between superclass and subclasses.

7
Visibility

• Visibility refers to the ability of a method to reference a

feature from another class.
• It has possible values of public (+), private (-), protected (#).

8
N-ary associations

9
Aggregation

• Aggregation is string form of association in which an aggregate

object is made of constituent parts.
• Part-whole relationship
• Aggregation vs. Association

10
Composition

• Composition is a form of aggregation with two additional

constraints:
1. A constituent part can belong to at most one assembly.
2. It has a coincident lifetime with the whole assembly.

11
Example Airline System

12
Example: IoT

13
Guidelines for class diagrams

• Try to avoid n-ary associations.

• Restrict generalization upto 4-5 levels.
• Don’t get confused between aggregation and composition.
• Associations are bidirectional, without specifying arrows.
• Try to use minimal number of classes, avoid redundancy.

14
Interaction Modelling
• Class model describes the objects in a system and their
relationships, and the interaction model describes how the
objects interact.
• Interactions can be modelled at different levels of
abstractions.
• At high level, use cases describe how a system interacts with
outside actors.
• Sequence diagram provides more detail and show the
messages exchanged among a set of objects over time.
• Activity diagram provides further detail and show the flow of
control among the steps of a computation. 15
Use Case Model
• Actor: object or set of objects that communicates directly with
the system.
• Use case: functionality that a system can provide by
interacting with actors.

16
17
Use Case Relationships

• Include relationship

18
• Exclude relationship

19
• Generalization relationship

20
21
22
Guidelines for use case diagrams

• The actors need not be always persons.

• Distinct behaviour sequence (exceptions) and error conditions.
• Multiple actors can participate in a use case.
• Every use case should have at least one actor, and every actor
should participate in at least one use case.

23
Sequence Model
• A sequence diagram shows participants in an interaction and
the sequence of messages among them.
• Lifeline
• Message
• Concurrent signals
• Each use case requires one or more sequence diagrams to
describe its behaviour.
• Each sequence diagram shows a particular behaviour
sequence of a use case.
24
25
26
27
Example: IoT

28
Guidelines for sequence diagrams

• Break large interactions into small tasks and prepare a

sequence diagram for each of them.
• Prepare separate sequence diagram for each error condition.

29
Activity Model
• An activity diagram shows flow of control, similar to a
sequence diagram, but focuses on operations rather than
objects.
• Unlike a flow chart, an activity diagram can show both
sequential and concurrent flow of control.
• Branches
• Initiation and termination
• Concurrent activities (fork and merge)

30
31
32
Example: IoT

33
Guidelines for activity diagrams

• Concurrent activities means that the activities can complete in

any order. Before a merge can happen, all inputs must first
complete.
• If there are conditions, at least one must be satisfied when an
activity completes.

34
Data Vs. Information
Data Information
• Represents lowest level • Represents high level
• Raw input can be data • Shows processed input
which represent some
• Observation and knowledge
readings are used to
• Analysis is used to obtain
obtain data information
• Data alone is not useful • Information itself is
• Can be collected in any significant
random manner • Must be collected in 35
proper sequence
Data modelling concept
• Data modelling is the basic step in analysis modelling. In this,
objects are examined independently of processing.
• The data domain is focused. A model is created at customer’s
level of abstraction.
• The data model represents how data objects are related with
one another.
• Elements of data model are:
• Data object
• Attributes
• Relationship 36
 Data objects
• It is set of attributes that will be manipulated within the
software. It can be a person, organization, device or software
product.
• Each instance of data object can be identified with the help of
unique identifier. E.g. Roll No.
• The system cannot perform without accessing to the instances
of object. Each object is described by attributes.
• It is a collection of attributes that act as an aspect,
characteristic, quantity or descriptor of the object.
Object Typical data objects are:-
External Entities (printer etc), Things (repports etc), Occurences
Attributes (alarm etc), Roles (manager etc), Places (workshops etc), 37
Organizational Units (departments etc), Structures (files etc)
Attributes
• Attributes defines properties of data object.
• Three types of attributes:
• Naming attribute – Used to name an instance of data object.
• Descriptive attribute – Used to describe characteristics or
features of the data object.
• Referential attribute – These are the attributes that are used in
making the reference to another instance to another table.

38
Relationship
• It represents connection between data objects.
• For example:
• Customer and Order are two classes then relationship is:
• Customer gives order

39
 E-R Model
• The ER model defines the conceptual view of a database.

• ER Model is a database modeling technique that generates an

abstract diagram or visual representation of a system’s data that
can be helpful in designing a relational database. These diagrams
are known as entity-relationship diagrams, ER diagrams or ERDs.

• It works around real-world entities and the associations among

them.

• At view level, the ER model is considered a good option for

designing databases.
 ER Model Concepts
• ER model has three main concepts:

• Entities(and their entity types and entity sets)

• Attributes (simple, composite, multivalued)

• Relationships (and their relationship types and relationship

sets)
 Entity
• An entity is an object that exists and is distinguishable
from other objects.

• Entities are specific objects or things in the real-world

that are represented in the database.

• Entity may be an object with a physical existence for

example student.

• Entity may be an object with a conceptual existence for

example a company, a job, a university course.
Entity Sets
• An entity set is a set of entities of the same type that share
the same properties.

• The set of all persons who are customers at a given bank

can be defines as the entity set customer.

• The entity loan might represent the set of all loans to be

awarded by a particular bank.
 Attribute
• An entity is represented by a set of attributes, that is
descriptive properties possessed by all members of an
entity set.

• For example, an STUDENT entity may have the attributes ID,

Name, Address, Gender, Birth Date.
Notations
Multivalued
Entity
Attribute

Relationship
Weak Entity

Attribute

Derived Attribute

Attribute Key Attribute

Types of Attributes
• Simple or Atomic Attribute
• Composite Attribute
• Single-Valued Attribute
• Multi-valued Attribute
• Derived Attribute
Simple or Atomic Attribute
• It cannot be divided into simpler components
Example age of an employee.
Composite Attribute
• Composite Attributes can be divided into smaller subparts, which
represent more basic attributes with independent meanings.
• The attribute may be composed of several components. For
example: Address(House#, Street, City, State, ZipCode,
Country), or Name(FirstName, MiddleName, LastName).
• Composition may form a hierarchy where some components are
themselves composite.
Example
Single Valued Attribute
• Single valued attribute has a single value for a particular
entity.
• E.g.: age of employee. There can be only one value for this.
Multi-valued Attribute
• Multi-valued attribute has multiple values.
• Example: skill set of employee
• Another example, employee entity set with the attribute
phone number.
• An employee may have zero, one or several phone numbers.
Derived Attribute and Stored Attribute
• The value of this type of attribute can be derived
from the values of other related attributes or
entities.
E-R Diagram with Composite, Multi-valued, And Derived Attributes
Mapping Cardinalities
• Mapping cardinality or cardinality ratio express the number
of entities to which another entity can be associated via a
relationship set.
• Most useful in describing binary relationship sets, although
they can contribute to the description of relationship sets
that involve more than two entity sets.
• For a binary relationship set R between entity sets A and B,
the mapping cardinalities must be one of the following:
• One to one
• One to many
• Many to one
• Many to many
Participation Constraints
• Total Participation − Each entity is involved in the relationship.
Total participation is represented by double lines. E.g. every loan
entity to be related to at least one customer through borrow
relationship.

• Partial participation − Not all entities are involved in the

relationship. Partial participation is represented by single lines.
E.g. the participation of customer in the borrower relationship
set is partial as not all customer has borrowed loan from bank.
 E-R Diagrams
 An E-R diagram can express the overall logical structure
of a database graphically.
 Rectangles represent entity sets.
 Diamonds represent relationship sets.
 Lines link attributes to entity sets and entity sets to
relationship sets.
 Ellipses represent attributes
 Double ellipses represent multi-valued attributes.
 Dashed ellipses denote derived attributes.
 Underline indicates primary key attributes.
 Double Lines indicate total participation of an entity in
a relationship set.
 Double rectangles represent weak entity sets.
Example 1
• Library System
Example 2
• Banking System
Guidelines to design E-R Diagram
• During requirement elicitation process, the requirements should
be collected in such way that we can evolve input, output data
objects & external entities for system modelling.
• The analysis & customer should be in position to define
relationship between data objects.
• When connection between data objects is identified the object
relationship pair must be established.
• For each object relationship pair the cardinality & modality is set.
• The attributes of each entity must be defined.
• The entity relationship diagram is formalized & reviewed.
59
• All the above steps are repeated until data modelling is
complete.
 Data Flow Model
• The data flow diagram depict the information flow & transforms
that are applied on the data as it moves from input & output.
• The data flow diagrams are used to represent the system at any
level of abstraction.
• The DFD can be partitioned into levels that represent increase in
information flow & detailed functionality.
• A level 0 DFD is called as ‘fundamental system model’ or ‘context
model’ representing the entire system.
• Each process shown in level 1 represents the sub functions of
overall system.
• The number of levels in DFD can be increased until every process
represents the basic functionality.
60
• As the number of levels gets increased in the DFD, information
flow gets refined.
Notations
Process

Data Store

External Entity

Flow of Data
Guidelines to design DFD
• Level 0 DFD i.e. context level DFD should depict the system as
a single bubble(process).
• Primary input & output should be carefully identified.
• While doing the refinement isolate process, data objects &
data stores to represent the next level.
• All the processes & arrows should be appropriately named.
• One process at a time should be refined.
• Information flow continuity must be maintained from level to
level.
62
 Rules for designing DFD
• No process can have only outputs or inputs. The process have both inputs
and outputs.
• The verb phrases in the problem description can be identified as
processes in the system.
• There should not be a direct flow between data stores and external
entity. This flow should go through a process.
• Data store labels should be noun phrases from problem description.
• No data should move directly between external entities.
• Generally source and sink labels are noun phrases.
• Interactions between external entities is outside scope of the system and
therefore not represented in DFD.
• Data flow from process to a data store is managed (U/I/D). 63
• Data flow from data store to process is for retrieving using information.
• Data flow labels are noun phrases from problem description.
 Process Decomposition
1.1 1.2
1.0
Record Receive
Sale
Order Payment

2.1 2.2 2.3

2.0
Serve Produce Store
Production
Product Product Product

0.0
Lemonade
System 3.1
3.0 3.2 3.3
Produce
Procure- Receive Pay
Purchase
ment Items Vendor
Order

4.1 4.3
4.2
4.0 Record Pay
Calculate
Payroll Time Employe
Payroll
Worked e

Context Level (Level 0) Level 1 Level 2

Example (Library System DFD)

65

Fig: Level - 0 Context Level DFD

Continued…

66

Fig: Level - 1 DFD

Continued…

67

Fig: Level - 2 DFD

 Control Flow Model (CFD)
• The CFD shows the same processes as in DFD but rather than
showing data flow they show control flows.
• CFD show how events flow among processes. It also shows how
external events activate the processes.
• The dashed arrow is used to represent the event.
• A solid bar is used to represent the window. This window is used
to control the processes used in the DFD based on the event that
is passed through the window.
• Instead of representing control process directly in the model the
specifications are used to represent how processes are controlled.
• When a data input is given to the process a data condition should
occur to get the control output.
68
• There are two commonly used representation of specification:
Control Specification(CSPEC) & Process Specification (PSPEC).
Designing Control Flow Diagrams
• There are certain applications which are event driven rather than being
data driven. They produce control information rather than producing
data. Such applications can be modeled with the control information
along with data flow modeling.
• A graphical model used to represent the control information along with
the data flow model is called control flow model.
• Following guidelines are used to draw CFD:
• List all sensors that can be read.
• List all the interrupt conditions.
• List all the data conditions.
• List all the switches actuated by the operator.
• Use noun/verb parsing techniques to identify control information.
• Describe behaviour of system by identifying the states. Define the 69
transition between the states.
• Avoid common errors while specifying the control.
Example (CFD)
CFD DFD

Obtained temperature

Maximum Check &

temperature convert
temperature Converted
temperature

PSPEC
If obtained temp > max temp
set above_temp = TRUE
Else
set above_temp = FALSE
Begin 70
temp_conversion algorithm
End
End if;
Control Specification (CSPEC)
• The CSPEC is used to represent two things –
• The behaviour of the system when an event occurs.
• The processes that get invoked on occurrence of particular event.
• The CSPEC represents the system in two ways –
• State Transition Diagram
• It is a collection of states and events.
• Program Activation Table
• The program activation table represents the input events, output
and process activation in tabular form.

71
Process Specification (PSPEC)
• The PSPEC is used to describe the inner workings of the
process represented in a data flow diagram.
• The process specification describes the input to the function,
the algorithm, constraints imposed by the function,
characteristics of the process.
• The process specification is used to describe the working of
the process.
• The process specification is given by Program Design Language
(PDL).
72
 Data Dictionary
• The data dictionary can be defined as an organized collection of all
the data elements of the system with precise and rigorous
definitions so that user and system analyst will have a common
understanding of inputs, outputs, components of stores and
intermediate collection.
• The data models are less detailed hence there is a need of data
dictionary.
• Data dictionaries are lists of all the names used in system models.
• Descriptions of the entities, relationships and attributes are also
included in data dictionary.
• The data dictionaries are implemented as a part of structured
analysis and design tool. 73
 Continued…
• Data dictionary stores following information:
Name Description
Name Primary name of data or control item, the data store or external entity
Alias Other name used for the name
Where-used or Describes where the data control item is used and how the item is
how is used used

• Notations used in data dictionary are:

Data Construct Notation Meaning
Composition = Is composed of
Sequence + And
Selection [|] Or
Repetition { }N Repetition of N items
74
( ) Optional data
*…* Commented information
Continued…
• The data dictionary defines the data unambiguously.
• One can give the detailed description of data items using data
dictionary.
• For large systems size of data dictionary will be large and will
be hard to maintain manually. So for such large system
automated tools (CASE) is used.

75
 Example
Name: Passenger
Alias: None
Where used/ How used: Passenger’s query (input)
Ticket (output)
Description:
Passenger = Passenger_Name + Passenger_Address
Passenger_Name = Last_name + First_name + Middle_name
Passenger_Address = Local_address + Community_address + Zip_code
Local_Address= House_number + Street_name + (Appartment_name)
Community_Address= City_name + [State_name | Province_name]

76