Unit-3

Data Oriented
Analysis & Design
1
 Unit – 3 Syllabus
• Building the analysis model:
• Data modeling concepts
• Scenario –based modeling
• Flow-Oriented modeling
• Class based modeling and creating a behavioral
model.
• User interface design:
• The Golden rules
• User interface analysis and design
• Interface analysis
• Interface design steps
2
• Design evaluation
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
3
 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.

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

5
Links and Associations

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

7
Generalization

• Relationship between superclass and subclasses.

8
Visibility

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

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

9
N-ary associations

10
Aggregation

• Aggregation is string form of association in which an

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

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

12
Example Airline System

13
14
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.

15
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. 16
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.

17
Conti…
UML use case diagrams are ideal for:
• Representing the goals of system-user interactions
• Defining and organizing functional requirements in a system
• Specifying the context and requirements of a system
• Modeling the basic flow of events in a use case
Use case diagram symbols
and notation
• Use cases: Horizontally shaped ovals that represent the different
uses that a user might have.
• Actors: Stick figures that represent the people actually employing
the use cases.
• Associations: A line between actors and use cases. In complex
diagrams, it is important to know which actors are associated with
which use cases.
• System boundary boxes: A box that sets a system scope to use
cases. All use cases outside the box would be considered outside
the scope of that system. For example, Psycho Killer is outside the
scope of occupations in the chainsaw example found below.
• Packages: A UML shape that allows you to put different elements
into groups. Just as with component diagrams, these groupings are
represented as file folders.
20
Use Case Relationships

• Include relationship

21
• Exclude relationship

22
• Generalization relationship

23
24
25
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.

27
Sequence Model
• A sequence diagram shows participants in an interaction
and the sequence of messages among them.
• Components of Sequence Model:
• 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. 28
29
30
31
32
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.

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

34
35
36
37
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.

39
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 data
obtain information
• Data alone is not useful • Information itself is
• Can be collected in any significant
random manner • Must be collected in 40
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 41
 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 (reports etc), Occurrences
Attributes (alarm etc), Roles (manager etc), Places (workshops etc), 42
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.

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

44
 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.
64
• The entity relationship diagram is formalized & reviewed.
• All the above steps are repeated until data modelling is
 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 ‘fun damental 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.
65
• 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.
67
 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).
• Data flow from data store to process is for retrieving using information. 68

• Data flow labels are noun phrases from problem description.

 Process Decomposition
1.2
1.1
1.0 Receive
Record
Sale Payme
Order
nt

2.2
2.0 2.1 2.3
Produc
Producti Serve Store
e
on Product Product
Product
0.0
Lemona
3.1
de
Produc
System 3.0 3.2 3.3
e
Procure- Receive Pay
Purcha
ment Items Vendor
se
Order

4.1 4.2 4.3

4.0 Record Calcula Pay
Payroll Time te Employ
Worked Payroll ee

Context Level (Level 0) Level 1 Level 2

Example (Library System DFD)

70

Fig: Level - 0 Context Level DFD

Continued…

71

Fig: Level - 1 DFD

Continued…

72

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. 73
• 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
transition between the states. 74
• 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 75
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.
76
 State(Behavioural) Model
• There are two types of diagrams in UML :
1. Structure Diagrams – Used to model the static structure of a
system, for example- class diagram, object diagram etc.
2. Behavior diagram – Used to model the dynamic change in the
system over time. They are used to model and construct the
functionality of a system. for example- Interaction diagrams and
State diagrams.
• A state diagram is used to represent the condition of the system
or part of the system at finite instances of time. It’s
a behavioral diagram and it represents the behavior using finite
state transitions. State diagrams are also referred to as State
machines, state transition diagram and State-chart Diagrams.
• State diagram is used to model the dynamic behavior of a class in 77
response to time and changing external stimuli.
Basic components of a state
chart diagram
• Initial state – We use a black filled circle represent the initial
state of a System or a class.

• Transition – We use a solid arrow to represent the transition

or change of control from one state to another. The arrow is
labelled with the event which causes the change in state.
Conti…
• State – We use a rounded rectangle to represent a state. A
state represents the conditions or circumstances of an object
of a class at an instant of time.

• Fork – We use a rounded solid rectangular bar to represent a

Fork notation with incoming arrow from the parent state and
outgoing arrows towards the newly created states. We use
the fork notation to represent a state splitting into two or
more concurrent states.
• Join – We use a rounded solid rectangular bar to represent a
Join notation with incoming arrows from the joining states
and outgoing arrow towards the common goal state. We use
the join notation when two or more states concurrently
converge into one on the occurrence of an event or events.
• Self transition – We use a solid arrow pointing back to the
state itself to represent a self transition. There might be
scenarios when the state of the object does not change upon
the occurrence of an event. We use self transitions to
represent such cases.
• Composite state – We use a rounded rectangle to represent
a composite state also. We represent a state with internal
activities using a composite state.

• Final state – We use a filled circle within a circle notation to

represent the final state in a state machine diagram.
Example

82
 Program Activation Table
• (PAT)
The PAT represents information contained in the State Diagram
in the context of processes, not states. i.e., the table indicates
which processes in the flow model will be invoked when an event
occurs. The PAT can be used as a guide for a designer who must
build an executive that controls the processes represented at this
level.

85
 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).
PSPEC (PDL)
If obtained temp > max temp
set above_temp = TRUE
Begin
temp_conversion algorithm 86
End
End if;
 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 87
analysis and design tool.
 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 how Describes where the data control item is used and how the item is used
is 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
88
( ) 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.

89
 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]

90
Thank You

91