UNIT 5 ARCHITECTURE MODEL

Structure Page No.

5.0 Introduction
5.1 Objectives
5.2 Model
5.2.1 Modeling
5.3 Architecture Modeling
5.3.1 Aspects of Architecture Modeling
5.3.2 Logical Architecture
5.3.3 Physical Architecture
5.4 Implementation Diagram
5.4.1 Component Diagram
5.4.2 Deployment Diagram
5.5 Collaboration
5.6 Summary
5.7 Solutions/Answers
5.8 References/Further Readings

5.0 INTRODUCTION

We know that object-oriented concepts play an important role in the development of

the software system. So, the question is that how do we apply these concepts
efficiently? The answer is simple; we need to model using object-oriented concepts.
Also, while designing the system, we need to apply the object-oriented concepts
appropriately and efficiently to develop error-free software. Such modeling provides
us with a goal-oriented way of analysing real-world problems. System modeling is
required to better understand the assigned problems and understand the better
coverage of the developing stages of the software system. To build any system, model
provides us with a better template. If we want to visualise the structure or behaviour of
the system, the model provides a blueprint of such a system.
This unit will cover the concepts of the architecture model, its importance, component,
and deployment model using relevant examples.

5.1 OBJECTIVES

After going through this unit, you should be able to:

 explain the concept of system modeling,
 explain different aspects of architecture modeling,
 describe the difference between logical and physical architectural model,
 describe the concept of the implementation diagram, and
 differentiate the component and deployment diagram.

5.2 MODEL

A model is an abstract representation of a system, which promotes a better

understanding of its representation. It helps to give better insight into the development
of the system among communication of project team members. The model also gives

1
us an overview of the system's planning, design, testing, and implementation. A model
is a way to represent something in the same or in a different medium. It always
captures the important aspect of a thing and omits the unwanted attributes or
components associated with it. We need a convenient medium to express the model. If
you want to design a software system model, you need a modelling language such as
UML. The model includes pictures as well as text for a better understanding of the
model. Models are the best way to handle large software development more
economically. They also deal better with complex systems. Such complex systems
may be difficult to handle directly. By observing the model, you can analyse the
possible impact of any change before developing the model. Selection of the best-
suited model is important. It helps to solve the problems in a better way. Also, it helps
in handling the related issues during the software development.
The best thing about the model is that it represents the abstract view of the required
structure of a system. The model helps to provide a partial or full description of the
system. You can obtain the full description of a system by carefully observing the
abstract model of that system. Models may have different levels as per stakeholders'
requirements. These different levels and forms serve different purposes. Relationships
between models of different levels of abstraction are important. Two main
classifications of the model are Static and Dynamic models.
Static features are easier to model as they do not include changes over time. The static
model specifies the structure of the system using the object's operations and
association. If you observe and analyse carefully, such structures exist in the problem
statement itself. The static model encapsulates only those characteristics of the system
which are independent of time and presents the state of a system at a given moment. It
includes class diagrams, use case diagrams and composite structure diagrams. The
dynamic model represents the object interactions during runtime and expresses the
system's behaviour over time with the help of the system's dynamic behaviour. It
includes sequence, activity, collaboration, and state chart diagrams.

5.2.1 Modeling
Modeling is a critical part of any developing software project. It always leads to the
final deployment of a good software system. If you want to understand the system in a
better way, you need the modeling of the system. Modeling helps to visualise and
control the system's architecture. System modelling is the best possible way to
manage the risk and explore your system's desired structure and behavior. For the
different goals, designers build different types of models before constructing and
developing the system.
Semantic information and notations are involved in the modelling process. Semantic
involves the classes, relationships, states, and communication. The details of the
syntactic structure can be obtained by using it because elements in this model carry
the meaning of the model. The notations in modelling also play a significant role.
They provide a visual representation and a better understanding of the model.
Modeling is part of the larger environment which involves various modelling tools,
languages, implementing constraints etc. It includes numerous information about the
software system environment like project management, code generation etc.
According to Grady Booch "Modeling is a central part of all the activities that lead up
to the deployment of good software. We build models to communicate the desired
structure and behavior of our system. We build models to visualise and control the
system's architecture. We build models to better understand the system we are
building, often exposing opportunities for simplification and reuse. And we build
models to manage risk."
So we can summarise the Modeling as:
 Object Oriented
 Provides the visualisation of the system as per our needs, Analysis and UML
 Help us to reduce the complexity of the system,
 Facilitate a template for constructing a system,
 Supports in the testing of the system before its implementation, and
 Provides communication with the end-users.

As a further extension of modeling concepts, we will discuss architecture modeling in

the next section.

5.3 ARCHITECTURE MODELING

To understand the complete picture of the UML, various components can be linked in
distinct ways, which are considered as a diagram. The main purpose of showing a
diagram is to view the visual representation of the system.
The architecture of software deals with the design and implementation of the high-
level structure of the software. It involves the association of various architectural
components to show the correct functional and non-functional requirements of the
system. For a better understanding of the architecture of a software system, there are
different diagrams and models. Among these, architectural model has its own
importance. Various modeling elements and techniques are required to describe the
architectural model. According to Taylor et al, "An architectural model is an artifact
that captures some or all of the design decisions that comprise a system's architecture.
Architectural modeling is the reification and documentation of those design decisions.
An architectural modeling notation is a language or means of capturing design
decisions."
The success of object-oriented systems mostly depends upon the architectural model
of the system. Architectural model represents the complete framework and outline of
the complete software system. The architectural model contains both structural and
behavioural diagrams of the system and can be defined at both a logical and physical
level. The logical level shows the architecture's common view, whereas the physical
level shows more details about how the software and systems are designed. It also
includes detail about different technologies that exist within the organisation. In the
architectural models, dependencies exist; for example, one system component, or
package, is dependent on another.
We use a model composed of multiple views or perspectives to describe a software
architecture. Architectural modeling provides a view that is important to solve various
problems in a software system. This modelling typically includes a logical view, a
process view, a physical view, a deployment view, and a use case view. Architectural
modelling is centred on the idea of reducing the complexity of software through
abstraction, separation of concerns, and reuse. There are numerous concepts which
need to be modelled like components, connectors, interfaces, rationale etc.

5.3.1 Aspects of The Architectural Modeling

There are various aspects of architectural modelling. It focuses on that what do you
model? These aspects are static, dynamic, functional, non-functional etc.
The collection of components represents the static aspect of an architectural model.
They may form a component hierarchy. In this hierarchy, components are represented
as sub-components and interactions between them. The static aspects are stable as
they represent those parts of a system that forms the system's main structure. Static
parts of the system are represented by classes, interfaces, objects, components, and
nodes. Static aspects of a system do not change when a system runs or is executed i.e.
3
it does not involve system's behaviour while execution for e.g. topologies, assignment
of components/connectors to hosts etc. It includes static diagrams like class diagram,
component diagram and deployment diagram.
The dynamic aspect of the architectural model is represented by a collection of
component and connection configurations which are controlled by nodes. The
dynamic aspect is suitable for handling the runtime modification of the structure of a
system. This aspect is concerned with the time and sequencing of the operations.
Dynamic aspects emphasise the system's dynamic behaviour by showing
collaborations among objects and changes to the internal states of objects. Note that
dynamic aspects of a system do change during a system's runs. It shows the system's
run time behaviour, e.g., state of individual components or connectors, state of a data
flow through a system, etc. It includes dynamic diagrams like use case, sequence,
activity, and state chart diagrams.
The functional aspect of the architectural model includes the system functions and the
data-flows i.e. interaction between them. It defines how the functions will operate
together to perform the system goal. The functional aspect is necessary in architectural
modelling because it helps to identify the different functionalities in software systems
and explores how software components interact among them and with the outer
components of the system. The functional aspect describes what transactions the
software product must carry out to satisfy the specified requirements. The functional
aspect is used to support functional and performance test development. The functional
aspect usually drives the definition of the other architectural views like information,
concurrency, deployment, operational etc.
The non-functional aspect of the architectural model describes the system's
operational capabilities and constraints that enhance its functionality. To accomplish
the non-functional aspect of any architectural modeling is a difficult task. Finding the
non-functional aspect and matching them with architectural concerns are more
complicated than dealing with functional requirements. Non-functional aspects are the
needs of a system to carry out its operations under constraints and quality
expectations. Non-functional aspects are often captured less rigorously, as they are
qualitative and subjective. Non-functional aspects are related to the quality of service
for a software system. These aspects are usually very abstract and stated only
informally. They refer to both observable qualities and internal characteristics of a
software system. To satisfy non-functional aspects, the software architect applies
architectural strategies to the system design, such as design patterns, layering
techniques, etc.

5.3.2 Logical Architecture

If we want to understand the structure and organisation of the system's design, we use
an architectural view which is also known as logical architecture or logical view. The
logical architecture starts with the end user's functional requirements and provides a
top-down abstraction of the system's overall design. A logical model provides the
static view of the objects and classes of the system. Object-oriented systems intend for
layered architecture. It is concerned with the functionality that the system provides to
end-users. UML diagrams used to represent the logical architecture for object-oriented
systems include class diagrams, object diagrams, sequence diagrams, activity
diagrams, and state diagrams. Figure 5.1 shows the representation of the logical
architecture of a system.
 Object Oriented
Analysis and UML

Figure 5.1: Logical Architecture of a system

The logical architecture consists of software classes and sub classes into different
elements like packages, subsystems, and layers. It consists of the subset of the
classes, subsystems and packages, and use-case realisations. The name, logical
architecture is called due to there is no focus on how these elements are deployed
across the software system. This architecture focuses only on the main components,
their association, and data flow between them while structuring and grouping the
elements into larger-scale modules.

Head Office Bank/Branch

-branch name -Bank code
-branch code -Bank address
-Bank Manager

add-branch () add-account ()
del-branch () del-account ()
get-branch () get-account ()

Account Statement

Acct-No -date
Acct-Balance -content
Acct-description

add-account ()
del-account ()

Current Act Saving Act

add-cust () add-cust ()
del-cust () del-cust ()

Customer

 id
 name
 address
 email
 Phone No
 Password

Figure 5.2: Logical architecture of banking management system as a class diagram

5
5.3.3 Physical Architecture

The physical architectural models are the systems' dynamic (run time) architecture. It
shows the configuration of the topology of software components on the physical layer
as well as the physical connections between these components. This model provides
detailed information about how elements or components will be deployed across the
system infrastructure. It maps the software elements and artifacts to its platforms,
including the hardware elements (nodes), the network, and the supporting software
platforms. This model focuses on detail about network resources, server
configuration, hardware information and other relevant information which are
required to develop and deploy the software system. The main objective of modeling
physical architecture is to satisfy the proposed logical architecture elements and
defined requirements of the system. This architecture supports the physical view of
the system, and the deployment diagram of UML is used to represent it. Such a
diagram is very beneficial because it clarifies which packages should be installed on
which nodes. Basically, the physical architecture helps the system designers and
administrators recognise the software's physical locations, linkage between nodes,
deployment, and [Link] implemention of physical architecture, you will study
it in detail via implementation of the deployment diagram in subsequent sections by
using real-life examples.

☞ Check Your Progress 1

1) What is a model? Why they are important for a software system.

…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

2) What are the basic principles of modeling? Explain briefly.

…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

3) Explain the use of modeling for the development of an efficient software

system.
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

4) Describe how the nature of components, the significance of the links, and
the layout play an important role in the architectural model?
 Object Oriented
………………………………………………………………………………… Analysis and UML
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

5) How can you say that an architectural model contains both structural and
behavioural diagrams of the system and can be defined logically and
physically? Explain.
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

6) Differentiate the following with respect to the aspects of architectural

modelling.
a. Static and dynamic aspects
b. Functional and non-functional aspects
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

Now, you are familiar with architectural modeling. In the next section, we will
explore how to implement architectural modelling by using suitable UML
diagrams. Now, let us discuss the basic concept of the implementation
diagram.

5.4 IMPLEMENTATION DIAGRAM

The diagram, which is closely correlated with the Use Case, is the implementation
diagram. The purpose behind this coupling is to highlight which types of design
elements will implement the functionality of Use Case in a novel system. This
diagram provides the physical environment of our system. The implementation view
of a system incorporates the components that are used in the physical system. Using
this view, one can address the various components of the system which are required
for the configuration of the system. The implementation diagram is very much helpful
in the physical implementation of the design. To illustrate the details of
implementation, the most used diagrams are the component diagram and the
deployment diagrm. Both diagrams are part of structural modeling. These diagrams
are explained in the following sections.

7
5.4.1 Component Diagram

Component diagrams are used to show how the physical components in a system have
been organised. It shows the set of components and their relationships in the system. It
helps in understanding if the system's functional requirements are covered by planned
development. The relationship among components are called dependencies. This
diagram models the physical aspect of the system, including software components,
source code, runtime code, & executables. To provide the details about a system's
static design implementation view, such diagrams are very helpful. it represents the
high-level parts that make up the system. They help us frame large systems by using
smaller components and become necessary when designing and building complex
systems. According to R. A. Maksimchuk and E. J. Naiburg, it is important to develop
software based on multiple smaller parts (components), which you can use to
assemble the overall system. This enables you to reuse software components instead
of writing them all from scratch. They further explained and suggested that you can
use a component diagram and components to model the architecture of different parts
of your system. You can also use them to model the application internals, as we just
discussed, as well as to view how different applications work [Link] component
diagram also represents the collaborations and internal structure of components. These
components may be nested and are present as internal structure in components
diagram along with class and its interfaces. Component diagrams commonly contain
components, interfaces and dependency, generalisation, association, and realisation
relationships, which also help specify the components' details for constructing an
executable system.

Graphically, a component diagram is a collection of vertices and arcs. The essential

components of component diagrams are :

 components,
 interfaces
 ports and
 connectors

Components-
In the component diagram, the component represents a reusable piece of software and
is the physical and replaceable unit of the system. According to G. Booch, at the
lowest level, a component is a cluster of classes that are themselves cohesive but are
loosely coupled relative to other clusters. He suggested that each class in the system
must live in a single component or at the top level of the system. Components are
represented as rectangle with tab having the name of the object in it. A component
may also contain other components. The components do not directly depend on other
components but on interfaces. Dependencies may also exist among the components,
which cause changes in components due to changes in one or more components. It
represents by a dashed line in the component diagram. The component's name should
be unique in the specified component diagram.

<<Component>>
Banking System

Figure 5.3: Component

 Object Oriented
Interfaces- Analysis and UML
Components of the system use interfaces to communicate with each other. It defines
the component's interaction details. It is a collection of operations that are used to
specify a service of a class or a component. The interfaces are shown in the ball-and-
socket notation or as a typical class with the stereotype of <<interface>>. In
interfaces, the ball notation is used to specify the component's functionality. A
component collaborates with other components through well-defined interfaces that
specify the system's functionality to the environment. If a component provides service
through interface to other component, then its called a provided interface, and it is
shown as a straight line from the component box with an attached circle (ball). If a
component receives the services from other components through the interface, it is
called as a required interface, and it is shown as a straight line from the component
box with an attached half-circle (socket).

Balance

<<Component>> <<Component>>
Banking System Bank Customer

Person

Figure 5.4: Interface

Ports-
Ports are used by the component for its interactions with its environment and also to
control the implementation of all the operations in the component. Along the edge of
the component, a port is shown as a small square. Ports provide encapsulation to the
structured classifier. Ports have public visibility, but components may also have
hidden ports. Interfaces may be linked to the port, but one-to-one relationship between
ports and interfaces is not required. Generally, ports are unnamed, but you can provide
the a name as port name: Port Type.

<<Component>>
Banking System
Cash Withdrawal

Figure 5.5: Port

Connectors-
A connector is used to show a link between the ports of components. It also specifies
the communication between two or more classifiers. If one port provides the interface
required by the other port, they can be linked together. There are mainly two types of
connectors: the viz delegation connector and the assembly connector. Delegation
connector links together the port of a part and port of a component, thus providing the

9
interface. Delegation Connectors are used when ports inside the composition need to
be connected with ports outside the composition.

Assembly connector: It connects two or more components that define services

provided by one component to another.

<<Component>> <<Component>>
Bank Account Credit Card

Payment in Shop direct Connector

Figure 5.6: Connectors

Example: Component diagram of ATM System

ATM
ATM Transaction
Machine

Account Customer
Information Console

Bank Card
Database Reader

Client
Console

Web Web
Page Merchant
Transaction
Client
Control
Transaction
Online
Transaction

Figure 5.7: Component diagram of ATM System

 Object Oriented
5.4.2 Deployment Diagram Analysis and UML
To address the static deployment view of architecture, we use the deployment
diagrams. Deployment diagrams are related to component diagrams in which a node
typically encloses one or more components. Deployment diagrams are used during
development of the system. In this diagram we use to indicate the physical collection
of nodes that serve as the platform for execution of our system. Before execution,
developed components of a software system must be deployed on some set of
hardware. Deployment diagram it represents the configuration of runtime processing
nodes and the components that live on them. A deployment diagram consists of nodes
and their relationships where a node may consists of one or more artifacts. This
diagram helps us in the allocation of artifacts to nodes in the physical design of a
system. It also helps us visualise, specify, and document embedded, client/server, and
distributed systems. The three main elements of a deployment diagram are artifacts,
nodes, and their connections.

Artifacts

An artifact represents physical entity that is used in software design or produced by

software development process. As artifacts are physical entities deployed on nodes,
devices, and executable environments, it is the source of a deployment to a node.
Artifacts can be involved in associations with other artifacts, such as a dependency of
one artifact on another artifact. Dependency between artifacts is notated as a general
dashed line with an open arrowhead directed from client to supplier artifact. The
notation for an artifact consists of a class rectangle containing the name of the artifact,
the keyword label «artifact», and an optional icon that looks like a sheet of paper with
the top right-hand corner folded over.

<<artifacts>>
Banking [Link]

Figure 5.8: Artifact of Banking System

Node
Node, just like component, is an important building block in modeling the physical
aspects of a system on which artifacts are deployed for execution. It exists at run time
and represents a computational resource, generally having memory and processing
capability. By using a node, we can easily model the topology of the hardware on
which the system executes. Components may be deployed on nodes because nodes
generally represent a device and execution environment. A device is a piece of
hardware capable of executing programs and can have a list of processes on it, such as
a computer, a modem, or a sensor. A device is a piece of hardware incapable of
executing program. At the same time, the execution environment is software that
provides for the deployment of specific types of executing artifacts. Execution
environments are typically hosted by a device. In the deployment diagram, a node is
represented as a cube with the name of the object in the deployment diagram. The
node must have a name in the diagram, and it should be unique i.e., different from
another node.

11
 <<device>> <<execute environment>>
node node

Figure 5. 9: Nodes

Connections
Communication is required among nodes in the deployment diagram. Nodes
communicate with each othe, via messages and signals, through a communication
path indicated by a solid line. This line is known as a connection. It represents the
communication path used by the hardware to communicate with nodes.
Communication paths may be unidirectional or bidirectional. Each communication
path may include an optional keyword label that provides information about the
connection. With the help of connections in nodes, we may represent the association,
dependency, generalisation, and realisation. An association represents a physical
connection or link among nodes using a solid line. We may use associations to model
indirect connections, such as a satellite link between distant processors. Dependency
indicates that a node dependent on another node using a dashed line. Generalisation is
a relationship between a parent node and child node using a solid line with a triangle
between nodes. The realisation is a relationship between interface and classes or
components that realise them using a dashed line with the hollow triangle.

<<device>> <<device>>
web server client console
Port 80

<<TCP/IP>>

Application server
<<device>>

Figure 5.10: Connections

 Object Oriented
Example: Deployment Diagram of Banking Management System Analysis and UML

Figure 5.11: Deployment diagram of Banking System

5.5 COLLABORATION

Collaboration defines an interaction and describes how the elements work together to
provide the system's behavioural requirements so that it must be larger than the
combination of all elements. Here, the combination of elements may be classes,
objects, interfaces, components, nodes, use cases or other elements. Even
collaboration describes the dynamic interactions of classifier instances though it also
has both types of dimensions, structural as well as behavioural. The structural
dimension focuses on how elements work together, and the behavioural dimension
focuses on the run time interaction of these elements. So, it covers both aspects, static
as well as dynamic. Collaboration plays an important role in constituting a system by
specifying the role of classifiers, structure of collaborating elements, operations,
required functionality, etc. The main objective of the collaboration is to describe the
working of the system, so it includes only important aspects of those elements which
are helpful to define the system. Embedded collaborations may exist, and this nesting
supports the abstraction concept.

We express the details about collaboration by using the collaboration diagram, which
is part of the interaction diagram. Collaboration is represented in the form of the
ellipse with dashed lines in its graphical form. It represents cooperating entities and
connectors. Collaboration acts like a template in which roles are defined for
classifiers, and during runtime, these classifiers are bound to their respective roles
joined by the connectors. The entities show collaboration characteristics, and the
connectors show the communication path between entities. Collaboration has a name,
and it must be unique within its enclosing package. Roles are also marked with a
name and their type. The role name is for a specific classifier instance, and the type is
a constraint for this instance of classifier without considering its internal design
structure or implementation detail.

With the help of a collaboration diagram, you can wire all components together, and
complex systems can be represented in a simple illustration. In the collaboration
diagram, we define the structure of collaborating elements which is known as role.
This role is played by the instances. This diagram represents the association and
13
interaction among these instances also. The interaction or message passing is required
to obtain the certain required result known as a task. In the collaboration diagram, we
represent the objects by using the box. The messages are represented by using
numbering on them. The following diagram represents the collaboration diagram for a
banking system.

Figure 5.12: Collaboration Diagram for Banking System

☞ Check Your Progress 2

1) What do you mean by component? How does it help to implement the
system?
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

2) Give the main advantages of the component diagram.

…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

3) Draw the component diagram for the online banking system.

…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
 Object Oriented
4) What role does physical architectural play in the design process of a Analysis and UML
software system?
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

5) Write the main advantages of the deployment diagram.

…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

6) Draw the deployment diagram for the ATM system

…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………

5.6 SUMMARY

The model helps us to give a better understanding of the development of the [Link]
also helps in communication among project team members. The static model specifies
the structure of the system using object operations and association. The dynamic
model focuses on the system's dynamic behaviour to express the system's behaviour
over time. Modeling includes the numerous information about the environment of
software system like project management, code generation etc. The architectural
model represents the complete framework and the outline of a complete software
system that contains both structural and behavioural diagrams of the system. The
logical model is a static view of the objects and classes that make up the
design/analysis space and leans on patterns the most. The model provides details
about how elements or components will be deployed across the system infrastructure.
The implementation diagram is very much helpful in the physical implementation of
the design. On the other hand, component diagram models the physical aspect of the
system, including software components, source code, runtime code, & executables.
Deployment diagrams are related to component diagrams in that a node typically
encloses one or more components. In the collaboration diagram, collaboration acts
like a template in which roles are defined for classifiers, and during runtime, these
classifiers are bound to their respective roles (instances) joined by the connectors.
This diagram represents the association and interaction among these instances also.
This unit explains the architectural modelling and deployment diagram in detail.

15
5.7 SOLUTIONS / ANSWERS

Check Your Progress 1

1) Model is way to represent something in same/different medium. It provides
abstract representation of a system, which promotes the better understanding by
its representation. It helps to give better insight about the development of system
among communication ofproject team members. Model also gives us the
overview of planning, design, testing and implementation of the system. Each
model within a design describes a specificaspect of the system under
consideration. Model is important because it provides the information about
organisation of the system and its be behavioural aspect. A model shows the
blueprints of a system for better visualisation of the problem. With the help of
model, you can easily understand the complexity level of any system in simplest
way.

2) Model is a simplified, complete, and consistent abstraction of a system, created

for better understanding of the system. selection of model is very important. It
helps to analyse the model and guide to provide the respective solution. Model
should be able to provide the complexity detail. It may be expressed at different
levels of abstraction. Model should be able to fulfil the gap between analysis and
design of the system. To provide the efficient solution of any problem, no single
model is sufficient. We need to visualise the problem domain as per different
model view.

3) Modeling helps to develop efficient software system. It provides the overall

template of system to be design. It provides the abstract representation of the
system and help development team to deal with the complexity of the problem.
Modeling is helps us to understand the various aspects of software system, its
processes, its organisation and association among different components and
elements. Proper selection of model ensures the best development of software
system even its complex in nature.

4) Components play a very important role in the architectural model. The main
benefit is the reusability because we can use them wherever we require in the
software system. Components also have the capability of encapsulation. Links are
also significant because they involve the association of various architectural
components to show the system's correct functional and non-functional
requirements. For a better understanding of the software system's architecture, the
layout of different diagrams and models is also very significant.

5) As you know, the architectural model represents the complete framework and
outline of the complete software system because this model has both the static and
dynamic aspects of the system. The static aspect is related to the structural model
that forms the main structure of the model. It focuses on the system's static
structure using objects, attributes, operations, and relationships. By this model,
you can obtain the significant concepts which are related at the abstraction and
implementational levels. The behavioural model is linked with the dynamic aspect
and contains the changeable components of the model. So, by using an
architectural model, we can easily represent the structural and behavioural
models. The logical level shows the common view of the architecture, whereas the
physical level shows more details about how the software and systems are
designed.
 Object Oriented
Analysis and UML
6)
a. The static aspect of the architectural model is represented by the collection of
components. In this aspect, components are represented as sub-components,
including the interaction between them. Static aspects of a system do not change
as a system runs. Static aspects represent those parts of a diagram which are
stable. Such aspects are represented by classes, interfaces, objects, components,
and nodes.

The dynamic aspect of the architectural model is represented by the collection of

component and connection configurations that are controlled by nodes. This
aspect is concerned with the time and sequencing of the operations. The dynamic
aspect is suitable for handling the runtime modification of a system's structure and
focuses on the system's dynamic behaviour. Such aspects are represented by use
case diagram, sequence diagram, activity diagram and statechart diagram.

b. The functional aspect defines how the functions will operate together to perform
the system goal. This aspect describes the software product's transactions to
satisfy the specified requirements. It is used to support functional and
performance test development. The Functional aspect usually drives the definition
of views like information, concurrency, Deployment, operational etc.

The non-functional aspect of the architectural model describes the system's

operational capabilities and constraints that enhance its functionality. Non-
functional aspects are the needs of a system to carry out its operations under a set
of constraints and quality expectations. These aspects are usually very abstract
and stated only informally.

Check Your Progress 2

1) The component represents a reusable piece of software and is the physical and
replaceable unit of the system. A component may also contain other components.
The components do not directly depend on other components but on interfaces.
Dependencies may also exist among the components, which cause changes in
components due to changes in one or more components. The component's name
should be unique in the specified component diagram. This diagram helps to
model the implementation detail of the system and ensure that system is
functioning as per requirement or not.

2) The main advantages of the component diagrams are as follow:

a. It represents the arrangement of the various components of the system and

how they are associated with each other.
b. It helps to understand the functionality of the system caused by the interaction
of components with each other.
c. It helps to visualise the dynamic behaviour of components.
d. It helps to develop the component-based software system by focusing on the
association between components and their dependencies.
e. It helps to visualise the physical structure of the system and the behaviour of
its services to the interfaces.

3)
17
 Debit
Card

Credit
Card
Cash
Withdrawal
Person Direct
Connector
Bank Bank
Customer Account

Balance
Saving
Account

Current
Account

Figure 5.13: Component diagram for the online banking system.

4) A physical architecture model provides the details about how components will be
arranged in the system. It shows the arrangement of physical elements that
provide the solution for a product, service, or enterprise. As you know, the
software design process describes a system that will be able to accomplish the
established tasks and provides a base for developing software structure. The
physical architecture model accomplishes this structure. Using this model, you
can easily identify the major components like modules, architecture, data etc.,
based on the provided requirements along with their responsibilities and the
association among them.

5) The main advantages of the deployment diagrams are as follow

a. It helps to visualise the hardware components and elements of the system that
are required to be physically deployed on the hardware.
b. Helps to understand the execution of artifacts used by participating nodes i.e.
physical hardware during the run time of the system.
c. It helps to model the details of the hardware topology of the system.
d. It is used to describe the distribution and relation of components in the
physical architecture.
 Object Oriented
6) Analysis and UML

Cash
Dispenses

Log
Display Device

Keypad Card
ATM reader
Node

ATM Customer Interface Receipt

ATM network Interface Printer
Network Device Controller
Interface

Network
Device

Processor: 200MHZ
Pentium
Network Bank Memory: 64MB
Connection Server

Figure 5.14: Deployment diagram for ATM system

5.8 REFERENCES/FURTHER READINGS

 Grady Booch, James Rumbaugh and Ivar Jacobson, " The Unified Modeling
Language User Guide", 2nd Edition, Addison-Wesley Object Technology Series,
2005.
 Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young, Jim
Conallen, Kelli A. Houston, "Object-Oriented Analysis and Design with
Applications," 3rd Edition, Addison-Wesley, 2007.
 James Rumbaugh, Ivar Jacobson, and Grady Booch, "Unified Modeling Language
Reference Manual," 2nd Edition, Addison-Wesley Professional, 2004.
 John W. Satzinger, Robert B. Jackson, and Stephen D. Burd, "Object-oriented
analysis and design with the Unified process," 1st Edition, Cengage Learning
India, 2007.
 Brett McLaughlin, Gary Pollice,and Dave West, "Head First Object-Oriented
Analysis and Design: A Brain Friendly Guide to OOA&D," Shroff Publisher,First
edition,2006.

19
 Object Modeling
UNIT 6 OBJECT MODELING
Structure Page Nos.
6.0 Introduction
6.1 Objectives
6.2 Advanced Modeling Concepts
6.2.1 Aggregation
6.2.2 Abstract Class
6.3 Multiple Inheritance
6.4 Generalization and Specialization
6.5 Meta Data and Keys
6.6 Integrity Constraints
6.7 An Object Model
6.8 Summary
6.9 Solutions/Answers
6.10 References/Further Readings

6.0 INTRODUCTION
In the previous Blocks of this course, we have learned the basics of OOA and
OOAD. Also, we have seen how to draw and use different UML diagrams for
visualizing, specifying, constructing, and documenting. According to Grady Booch,
“Object-oriented design is a method of design encompassing the process of object-
oriented decomposition and a notation for depicting both logical and physical as well
as static and dynamic models of the system under design”. Proper analysis of the
system helps in identifying proper system requirements and finally in good designing
of the system.
The goal of object design is object-oriented decomposition which leads to identifying
the object that the system contains and the interactions between them. The system
implements the specification. The goals of object-oriented design are:
(1) closer to the problem domain
(2) Incremental change is easy
(3) It supports reuse. Objects during Object-Oriented Analysis OOA focuses on a
problem or, in other words, semantic objects. In Object-Oriented Design we
focus on defining a solution. Object-Oriented modeling has three phases object
modeling, dynamic modeling, and function modeling. In this Unit, we will
discuss the concepts of object modeling. We will also discuss aggregation,
multiple inheritance, generalization in different forms and metadata.

In this unit, we will discuss Advanced Modeling Concepts, including, Aggregation &
Abstract Class, Generalization & Specialization, Multiple Inheritance and designing of
an Object Model

6.1 OBJECTIVES
After going through this unit, you should be able to:
 describe and apply the concept of aggregation,
 use the concepts of abstract Class, multiple Inheritance in designing systems,
 apply generalization as an extension,
 apply generalization as a Restriction, and
 explain the concept of metadata and constraints.

1
6.2 ADVANCED MODELING CONCEPTS
The object model describes the structure of the objects in a [Link] have to follow
certain steps for object-oriented design. These steps for OO Design methodology are:
1) produce the object model
2) produce the dynamic model
3) produce the functional model
4) define the algorithm for major operations
5) optimize and package.

The first step for object-oriented design is object modeling. Before we go into details
of object modeling, we should first know “what is object modeling”? You can say that
Object modeling identifies the objects and classes in the problem domain, and
identifies the relationship between objects. The goal of object model design is to
capture those aspects/concepts of the underlying system that are important to represent
the system in real-world in the context of the problem to be solved.

In this object modeling process, we first have to identify objects, then structures,
attributes, associations, and finally services. The object models are represented using
object diagrams containing objects and classes.
6.2.1 Aggregation
Aggregation represents the has-a or part-of relationship. Aggregation is tightly
coupled form of association. An aggregation depicts a complex object as an assembly
of many object components. Where these components are also objects, you may
characterize a house in terms of its roof, floors, foundation, walls, rooms, windows,
etc. A room may, in turn, be, composed of walls, ceiling, floor, windows, and doors,
as represented in Figure 6.1. Hence a house can be seen as an aggregation of many
objects. The decomposing of a complex object into its component objects can be
extended until the desired level of detail is reached. In UML, a link is placed between
the “whole “and “parts” classes, with a diamond head as shown in Figure-6.1,
attached to the whole class to indicate the aggregation. In aggregation, multiplicity is
specified at the end of the association for each part-of classes to indicate the
constituent parts of the association.

House

Roofs Roofs

Doors Windows Walls

Figure 6.1: A house and some of its component

Object aggregation is very helpful in describing models of the real-world that are
composed of other models. When describing a complex system of aggregates, System
analysts need to describe them in enough detail for the system at hand. For example,
2
 Object Modeling
in the case of a customer order and services, a customer order is composed of header
information and the detail lines. Also, the header and detail lines may each have
attached public and private customer service comments. In an order entry system,
detailed technical information about a product item appearing on a customer order line
may be accessible as well. This complex object called an order can be modeled
naturally using a series of aggregations. An order processing system can then be
constructed to closely model the natural aggregations occurring in the real world.
As mentioned earlier, aggregation is a concept that is used to express “part of” types
of associations between objects. An aggregate is, a conceptually, an extended object
viewed as a single UNIT by some operations, but it can actually be composed of
multiple objects. One aggregate in the system may contain multiple whole-part
structures. Also, each part is viewable as a distinct aggregate. Components of the
system may or may not exist in their own right and may or may not appear in multiple
aggregates. Also, an aggregate’s components may themselves have their own
components.

Aggregation is a special kind of association, adding additional meaning in some

situations. Two objects form an aggregate if a whole-part relationship tightly connects
them. If the two objects are typically viewed as independent objects, their relationship
is usually considered an association. Grady Booch suggests these tests to determine
whether a relationship is an aggregation or not:

 Would you use the phrase “part of” to describe it?

 Are some operations on the whole automatically applied to its parts?
 Are some attribute values propagated from the whole to all or some parts?
 Is there an intrinsic asymmetry to the association, where one object class is
subordinate to the other?
You have an aggregation if your answer is yes to any of these questions. Aggregation
is not the same as a generalization. Generalization relates distinct classes to structure
the definition of a single object. Superclass and subclass refer to the properties of one
object. A generalization defines objects as an instance of a superclass and an instance
of a subclass. It is composed of classes that describe an object (often referred to as a
kind of relationship). Aggregation relates object instances: one object that is part of
another. Aggregation hierarchies are composed of object occurrences that are part of
an assembly object (often called a part of a relationship). A complex object hierarchy
can consist of both aggregations and generalizations.

0..n 0..n
Person Company Division Department

Position

Total

Starting Date

Salary

Figure 6.2: Example of a composition

3
Composition: A stronger form of aggregation is called composition, which implies
exclusive ownership of the part of classes by the whole class. Composition means
parts of the system may be created after a composite system is created. Remember that
in such systems parts will be explicitly removed before the destruction of the
composite. In UML, filled diamonds, as shown in Figure 6.2, indicate the composition
relationship.
Figure 6.2 shows that a person works for a company, the company has many
divisions, which are part of the company, and each division has many departments,
which are again part of the division.
6.2.2 Abstract Class
An abstract class is used to specify the required behaviors (operations or methods )
of a class without providing their actual implementations. In other words, you can
say that methods without implementation (body) are part of abstract classes. An
abstract object class has no occurrences. Objects of abstract classes are not created but
have child categories containing actual occurrences. A “concrete” class has actual
occurrences of objects. If a class has at least one abstract method, it becomes, by
definition, an abstract class, because it must have a subclass to override the abstract
method. An abstract class must be subclassed; you cannot instantiate it directly.

Here you may ask one question: Why are abstract classes created? So the answer to
this question is:
 To organize many specific subclasses with a superclass that has no concrete
use,
 An abstract class can still have methods that are called by the subclasses. You
have to take is this correct point into consideration in the case of abstract
classes,
 An abstract method must be overridden in a subclass; you cannot call it
directly, and
 Only a concrete class can appear at the bottom of a class hierarchy.
Another helpful question to ask is: why create the abstract class method? The answer
to this question is:
 To contain functionality that will apply to many specific subclasses but will have
no concrete meaning in the superclass.

Shape
-orange
-color

+ move ()
+ resize ()
+draw ()

Rectangle Polygon Circle

+draw () +draw () +draw ()

Figure 6.3: How abstract and concrete classes are related. Consider the example of
shapes.

4
 Object Modeling
For example, in Figure 6.3, you can see that the shape class is a natural superclass for
the shapes Rectangle, Polygon, Circle, etc.

Every shape requires a draw () method. But the method has not been provided with
any meaning in the superclass Shape, so we make it an abstract class.

Subclasses provide another implementation to the method as per their need. The
subclasses provide the implementations of their draw methods since Rectangle,
Polygon and Circle can be drawn differently. A subclass overrides the implementation
of an operation inherited from a superclass. In this example, the draw method of the
Rectangle class overrides the implementation of the draw operation inherited from the
Shape class. The same applies to the draw methods of Polygon and Circle.
Abstract classes can appear in the real world and be created by modelers to promote
the reuse of data and procedures in systems. They are used to relate concepts that
are common to multiple classes. An abstract class can be used to model an abstract
superclass to group classes that are associated with each other or aggregated together.
An abstract class can define methods inherited by subclasses or define the procedures
for an operation without defining a corresponding method. The abstract operation
defines the pattern or an operation, which each concrete subclass must define in its
implementation in its own way.

 Check Your Progress 1

Give a right choice for the followings:
1) A class inherits its parent’s….
(a) Attribute, links
(b) Operations
(c) Attributes, operations, relationships
(d) Operations, relationships, link
…………………………………………………………………………….……
……………………………………………………………………….……
……………………………………………………………………….
2) Which of the following is not characteristic of an object?
(a) Identity
(b) Behavior
(c) Action
(d) State
…………………………………………………………………………….……
……………………………………………………………………….……
……………………………………………………………………….
3) Which of the following is not characteristic of an abstract class?
(a) At least one abstract method
(b) Methods may or may not have an implementation(body)
(c) Subclass must implement the abstract methods of superclass
(d) None of the above
…………………………………………………………………………….……
……………………………………………………………………….……
……………………………………………………………………….
4) When abstract classes are to be used in a system?
…………………………………………………………………………….……
……………………………………………………………………….……
……………………………………………………………………….

5
Now, you are familiar with aggregation and abstract classes. As a further extension of
object-oriented concepts, in the next section, we will discuss multiple inheritance.

6.3 MULTIPLE INHERITANCE

Inheritance allows a class to inherit features from the parent class (s). Inheritance
allows you to create a new class from one or more existing class(es)
Inheritance gives several benefits such as:
 Reduce duplication and increase reusability by building on what you have
already created.
 Organize theee classes of the system in the ways it may appear in real-world
situations in the problem domain.

PERSON
Fname, Lname

EMPLOYEE
Fname, Lname
Id
Pay ();
hire();

Figure 6.4: Example of Inheritance

For example, in Figure 6.4, you can see that the EMPLOYEE class is inherited from
the PERSON class.
Multiple inheritance extends this concept to allow a class to have more than one parent
class and inherit features from all parents. Thus, information may be mixed from
multiple sources. It is a more complex form of generalization. Multiple inheritances
does not restrict a class hierarchy to a tree structure (as you will find in single
inheritance). Multiple inheritance provides greater modeling power for defining
classes and enhances opportunities for reuse. Using multiple inheritance object models
can more closely reflect the structure and function of the real world. The disadvantage
of such models is that they become more complicated to understand and implement.
For an example of multiple inheritance, see Figure 6.5. In this example, the VAN
classes have inherited properties from class Cargo Vehicle and class Passenger
Vehicle.
Vehicle

Figure 6. 5: Example of Multiple Inheritance

The advantage of multiple inheritance is that it facilitates the reuse of existing classes
much better than in single inheritance. If the properties of two existing classes have to
beCargo
reused and only single inheritance is available, then one of the two classesPassenger
Vehicle would Vehicle
have to be changed to become a subclass of the other class.
However, multiple inheritance should be used rather carefully. The inheritance
relationships that will be created through multiple inheritance may become rather
complex and relatively difficult to understand. It is seen as a controversial aspect of
object–orientation and, therefore, not implemented in some object-oriented languages,
Cargo RAIL Cargo Shop
such
CAN
as Smalltalk, because sometimes multipleVANinheritance canCAR
lead to ambiguous BUS
situations.
While designing the system, you may observe that:

6 Fulsize VAN Mini VAN

 Object Modeling
 Rumbaugh et al. discuss the use of delegation as an implementation mechanism
by which an object can forward an operation to another object for execution.
Working with multiple inheritance can be difficult in implementation, when
only single inheritance is supported, but analysis and design models can be
restructured to provide a usable model. The recommended technique for
restructuring includes:
“Delegation using an aggregation of roles, a superclass with multiple
independent generalizations can be recast as an aggregate in which each
component replaces a generalization”.
For this, you have to:
 Inherit the most important class and delegate the rest. Here a join class is made
a subclass of its most important superclass.
 Nested generalization: factor on one generalization first, then the other,
multiplying out all possible combinations.
Rumbaugh suggests issues to consider when selecting the best workaround:

 If the subclass has several superclasses, all of equal importance, it may be best
to use delegation and preserve symmetry in the model
 If one superclass seems to dominate and the others are less important,
implementing multiple inheritance via single inheritance and delegation may be
best idea.
 If the number of combinations is small, consider nested generalization;
otherwise, avoid it.
 If one superclass has significantly more features than the other superclasses or
one superclass seems to have a performance bottleneck, preserve inheritance
through this path.
 If nested generalization is chosen, factor in the most critical criterion first, then
the next most important, etc.
 Try to avoid nested generalization if large quantities of code must be
duplicated.
 Consider the importance of maintaining strict identity (only nested
generalization preserves this).
Now, let us discuss the concept and specialization of generalization, an essential
concept of object-oriented modeling.

6.4 GENERALIZATION AND SPECIALIZATION

Generalization means extracting common properties from a collection of classes and
placing them higher in the inheritance hierarchy in a superclass.
Generalization and specialization are the reverse of each other. An object type
hierarchy that models generalization and specialization represents the most general
concept at the top of an object type: hierarchy as the parent and the more specific
object types as children.
When generalizing (as in the real world), care should be taken so that the property
makes sense for every single subclass of the superclass. If this is not the case, the
property must not be generalized.
Employee

Salaried Hourly
Worker Worker 7
 Figure 6.6: Generalization hierarchy of employee class

Specialization involves the definition of a new class which inherits all the
characteristics of a higher class and adds some new ones in a subclass so that the
derived class have some additional features compared to the [Link] other
words, specialization is a top-down activity that refines the abstract class into more
concrete classes, and generalization is a bottom-up activity that abstracts certain
principles from existing classes to find more abstract classes.

We often organize information in the real world as generalization/specialization

[Link] creation of a particular class involves a first or second activity
depends on the stage and state of analysis and whether the initial classes suggested are
very general or very particular. You can see an example of
generalization/specialization in Figure- 6.6.

For instance, an employee may either be a salaried or an hourly worker. A salaried

worker can be a manager. Also, in turn, that employee can be an executive department
manager or a unit supervisor. The employee classification is most general, the
salaried worker is more specific, and also, the Unit supervisor is most specific. Of
course, you might not model the world exactly like this for all organizations, but you
get the idea. Unit Supervisor is a subtype of salaried worker, which is a subtype of
the employee. Employee is the highest-level supertype, and the salaried worker is the
supertype of executive, department manager, and Unit supervisor. An object type
could have several layers of subtypes and subtypes of subtypes.
Generalization/specialization hierarchies help describe application systems and
indicate where inheritance should be implemented in object-oriented programming
language environments.
Any occurrence of a particular class is an occurrence of all ancestors of that class; so
all features of a parent class automatically apply to subclass occurrences. A child class
cannot exclude or suppress an attribute of a parent. Any operation on a parent must
apply to all children. A child may modify an operation’s implementation but not its
public interface definition. A child class extends parent features by adding new
features. A child class may restrict the range of allowed values for inherited parent
attributes.
In design and construction, operations on object data types can be overridden, which
could substantially differ from the original methods (rather than just refining original
methods). Method overriding is performed to override for extension, restriction,
optimisation, or for convenience. Rumbaugh et al. propose the following semantic
rules for inheritance:
 All query operations (ones that read, but do not change, attribute values) are
inherited by all subclasses.
8
 Object Modeling
 All update operations (ones that change attribute values) are inherited across all
extensions.
 Update operations that change constrained attributes or associations are blocked
across a restriction.
 Operations may not be overridden to make them behave differently from
inherited operations in their externally visible manifestations. All methods that
implement an operation must have the same protocol.
 Inherited operations can be refined by adding additional behaviour.

Both generalization and specialization can lead to complex inheritance patterns,

mainly via multiple inheritance. It is suggested that before making a final decision on
generalization/specialization you should understand these rules very carefully and
make the right choice for the following in respect of your system.

 Check Your Progress- 2

1) Polymorphism can be described as ___________
(a) Hiding many different implementations behind one interface
(b) Inheritance
(c) Aggregation and association
(d) Generalization
………………………………………………………………………………………….
……………………………………………………………………………..……
……………………………………………………………………………………
………………………………………………………………………………
2) What phrase best represents a generalization relationship?
(a) is a part of
(b) is a kind of
(c) is a replica of
(d) is composed of
………………………………………………………………………………………….
…………………………………………………………………………...………
……………………………………………………………………………………
………………………………………………………………………………
3) All update operations in inheritance are updated
(a) across all extensions
(b) across only some of the extensions
(c) only first extension
(d) None of the above.
………………………………………………………………………………………….
…………………………………………………………………………...………
……………………………………………………………………………....

4) Is generalisaaation and specialization reverse of each other? Why?

………………………………………………………………………………………….
…………………………………………………………………………...………
……………………………………………………………………………....

In the next section, we will discuss the concept of metadata and keys in
RDBMS.
9
6.5 METADATA AND KEYS
Let us first discuss metadata. As you know, RDBMS uses metadata for storing
information of the database tables. Metadata can be defined as “ such set of data
which describes other data”. For example, when you have to describe an object, you
need to have a description of the class from which the object is instantiated. Here, the
data you are using to describe class will be treated as metadata. You can say that
every real-world thing may have metadata, because every real-world thing has a
description for them. Let us take the example of an academic institutin and its
directors. You can store that deparrrtttment A is having X as its director, and
department B is having Y as its director, and so on. Now, you have concrete
information to keep in metadata that every department in the institute has a director.
KEY
To identify an object, attribute or combination of attributes is used. This attribute or ,
combination of attributes called a key. A primary key is an attribute (or combination
of attributes) that uniquely identifies an object instance and corresponds to the
identifier of an actual object. For example, customer number would usually be the
primary key for customer object instances. Two, or more, attributes in combination
sometimes may be used to uniquely identify an object instance. For example, the
combination of last name, first name, and middle initial might be used to identify a
customer or employee object instance. Here, you can say that sometimes more than
one attribute gives a better chance of identifying an object. For example, last name
alone would not suffice because many people might have the same last name. The first
name would help, but there is still a problem with uniqueness. All three parts of the
name are better still, although a system-generated customer or employee number is
bests used as an identifier if absolute uniqueness is desired. Possible Primary Keys
that are not actually selected and used as the primary keys are called candidate keys.
A secondary key is an attribute (or combination of attributes) that may not uniquely
identify an object instance but can describe a set of object instances that share some
common characteristic. An attribute (customer type) might be used as a secondary
key to group customers as internal to the business organization (subsidiaries or
divisions) or external to it. Many customers could be typed as internal or external at
the same time, but the secondary key is useful to identify customers for pricing and
customer service reasons.

6.6 INTEGRITY CONSTRAINTS

You have already studied integrity constraints in the DBMS course. Here, we will
have a look at how these constraints are applied in the object-oriented model.
Referential Integrity
Constraints on associations should be examined for referential integrity implications
in the database models. Ask when referential integrity rules should be enforced.
Immediately, or at a later stage? When you are modeling object instances over time,
you may need to introduce extra object classes to capture situations where attribute
values can change over time. For instance, if you need to keep an audit trail of all
changes to an order or invoice, you could add a date and time attribute to the order or
invoice objects to allow for storage of a historical record of their instances. Each
change to an instance would result in another instance of the object, stamped for data
and time of instance creation.
Insert Rules
These rules determine the conditions under which a dependent class may be inserted,
and they deal with restrictions that the parent classes impose upon such insertions.
The rules can be classified into six types.

10
 Object Modeling
Dependent: Permit insertion of child class instance only when the matching parent
class instance already exists
Automatic: Always permit insertion of a child class instance. If the parent class
instance does not exist, create one
Nullify: Always permit insertion of the child class instance.
Default: Always permit insertion of a child class in séance.
Customized: Allow child class instance insertion only if certain validity constraints
are met.
No Effect: Always permit insertion of the child class instance. No matching parent
class instances may or may not exist. No validity checking is
performed.
Domain integrity
These integrity rules define constraints on valid values that attributes can assume. A
domain is a set of valid values for a given attribute, a set of logical or conceptual
values from which one or more attributes can draw their values. For example, India
state codes might constitute the domain of attributes for employee state codes,
customer state codes, and supplier state codes. Domain characteristics include such
things as:
 Data type
 Data length
 Allowable value ranges
 Value uniqueness
 Whether a value can be null or not.
The domain describes a valid set of values for an attribute so that domain definitions
can help you determine whether certain data manipulation operations make sense.
There are two ways to define domains.
One way to define domains that define the domains first and then to associate each
attribute in your logical data model with a predefined domain. Another way is to
assign domain characteristics to each attribute and then determine the domains by
identifying specific similar groupings of domain characteristics. The first way seems
better because it involves a thorough study of domain characteristics before assigning
them to attributes. Domain definitions can be refined as you assign them to attributes.
In practice, you may have to use the second method of defining domains due to the
characteristics of available repositories or CASE tools, which may not allow you to
define a domain as a separate modeling construct.
Domain definitions are important because they:
 Verify that attribute values make business sense.
 Determine whether two attribute occurrences of the same value really represent
the same real-world value or not.
 Determine whether various data manipulation operations make business sense.
A domain range characteristics for a mortgage in a mortgage financing system could
prevent a data entry clerk from entering the age of five years. Even though mortgage
age and loan officer number can have the same data type, length and value, they
definitely have different meanings and should not be related to each other in any data
manipulation operations. The values 38 for age and 38 for officer number represent
two entirely unrelated values in the real world, even though they are numerically
identical.
Table 6.1: Typical domain values
Data Characteristic Example
Data type character
Integer
Decimal
Data length 8 characters
8 digits with 2 decimals
11
 Allowable data values x>=21
0<x<100
Data value constraints x in a set of allowable customer
numbers
Uniqueness x must be unique
Null values x cannot be null
Default value x can default the current date
x can default to a dummy inventory
tag number (for ordered items)
It makes little sense to match records based on values of age and loan officer number,
even though it is possible. Matching customer in a customer class and customer
payment in a customer transaction class makes a great deal of sense. Typical domain
characteristics that may be associated with some attributes of a class are shown in
Table-6.1.
Triggering Operation Integrity Rules
Triggering operation integrity rules govern insert, delete, update and retrieval
validity. These rules involve the effects of operations on other classes or other
attributes within the class, including domains, insert/delete, and other attributes within
a class, including domains and insert/delete and other attributes business rules.

Triggering operation constraints involves:

 Attributes across multiple classes or instances
 Two or more attributes within a class
 One attribute or class and an external parameter.
Example triggering constraints include:
 An employee may only save up to three weeks of time off
 A customer may not exceed a predetermined credit limit
 All customer invoices must include at least one line items
 Order dates must be current or future dates.
Triggering operations have two components. These are:
 The event or condition that causes an operation to execute
 The action set in motion by the event or condition.

When you define triggering rules, you are concerned only with the logic of the
operations, not execution efficiency or the particular implementation of the rules. You
will implement and tune the rule processing later when you translate the logical
database model to a physical database implementation. Here, you should note that it is
essential to avoid defining processing solutions (like defining special attributes to
serve as processing flags, such as a posted indicator for invoices) until all information
requirements have been defined in the logical object model, and fully understood.

Triggering operations can be similar to referential integrity constraints, which focus

on valid deletions of parent class instances and insertions of child class instances. Ask
specific questions about each association, attribute, and class in order to elucidate
necessary rules regarding data entry and processing constraints.
Triggering operation rules:
 Define rules for all attributes that are sources for other derived attributes

12
 Object Modeling
 Define rules for subtypes so that when a subtype instance is deleted, the
matching supertype is also deleted
 Define rules for item initiated integrity constraints.

6.7 AN OBJECT MODEL

In this section, let us examine a “sales order system” object model:
In this Sales Order System example, there are three methods of payment: cash, credit
Card or Check. The attribute amount is common to all three payment methods.
However, they have their own individual behaviours. Figure- 6.7 shows the object
model, where the directional association in the diagram indicates the direction of
navigation from one class to the other class.
Order
Order Customer
Customer
0.. n 1
Id Figure 6.7: An object model for Sales OrderName
name
System
Date Address
address
Delivery date& tone Phone
Category
category
 Check
1
Your Progress - 3
1) Explain in a few words whether the following UML class diagrams are correct
or not
1
Primary Courses
Payment Order line
Schedule CourseOffered
1..n quantity

Amount Figure 6.8: A Class Diagram get sub tolar ()

Alternate Courses
………………………………………………………………………………………………………………
o..n
………………………………………………………………………………………………………
Product
………………………………………………………………………………………………
Check Credit Card Cash
2) Card No is built out of one or more CPUs, Sound Card, and
Suppose that a computer
Video. Model Verification
the system with representative classes, and draw the class
Bom ID Code Cash Tendered Unit Price
diagram
brandID.
Check…………………………………………………………………………….……
ID Expire Date
……………………………………………………………………….……
……………………………………………………………………….……
……………………………………………………………………….
3) Suppose that the WindowWithScrollbar class is a subclass of Window and has
a scrollbar. Draw the class diagram (relationship and multiplicity).
………………………………………………………………………….………
…………………………………………………………………….………
……………………………………………………………………………
…………………………………………………………………….………
…………………………………………………………………….………
……………………………………………………………………….
6.8 SUMMARY
This unit explained basic aspects of object modeling, which includes a discussion on
models based on objects (rather than functions) would be more stable over time hence
the object-oriented designs are more maintainable. Objects do not exist in isolation
13
from one another. In UML, there are different types of relationships (aggregation,
composition, generalization) which are used to represent object models. This unit
covers aggregation and emphasizes that aggregation is the has-a or whole/part
relationship. In this unit, we have also seen how using generalization extracting
common properties can be performed from a collection of classes and placing them
higher in the inheritance hierarchy in a superclass. The unit is concluded with a
discussion on integrity constraints and, finally, by giving an object model for the
sales order system.

6.9 SOLUTIONS/ANSWERS TO CHECK YOUR

PROGRESS
Check Your Progress 1
1) c
2) c
3) d
4) Abstract class is used to relate concepts common to multiple classes while
designing a system. It is to be used to model an abstract superclass to group classes
associated with each other or aggregated together. Abstract class provides the
opportunity to model system's common interface, which can be implemented
differently by different subclasses in the system.
Check Your Progress - 2
1) a
2) b
3) a
4) Yes, generalization and specialization are the reverse of each other. An object
type hierarchy that models generalization and specialization represents the most
general concept at the top of an object type: hierarchy as the parent and the more
specific object types as children. When the system is viewed from the children’s
place, the parent in the system looks like a very general form of the children.

Check Your Progress - 3

1) The diagram is incorrect. Classes are not allowed to have multiple associations
unless defined by different roles.

2)
Computer Computer
1. *

1. *
1. *
Sound Card
Video Card

Figure 6. 9: Class Diagram

14
 Object Modeling

3)
Window

WindowWithScrollbar Scrollbar

Figure 6.10: Class Diagram

6.10 REFERENCES/FURTHER READINGS

 Grady Booch, James Rumbaugh and Ivar Jacobson,“ The Unified Modeling
Language User Guide”, 2nd Edition, Addison-Wesley Object Technology Series,
2005.
 Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young, Jim
Conallen, Kelli A. Houston, “Object-Oriented Analysis and Design with
Applications,” 3rd Edition, Addison-Wesley, 2007.
 James Rumbaugh, Ivar Jacobson, and Grady Booch, “Unified Modeling Language
Reference Manual,” 2nd Edition, Addison-Wesley Professional, 2004.
 John W. Satzinger, Robert B. Jackson, and Stephen D. Burd, “Object-oriented
analysis and design with the Unified process,” 1st Edition, Cengage Learning
India, 2007.

15
 Dynamic Modeling
UNIT 7 DYNAMIC MODELING
Structure Page Nos.
70 Introduction
7.1 Objectives
7.2 Events
7.3 State and State Diagram
7.4 Elements of a State Diagram
7.5 Advanced Concepts in Dynamic Modeling
7.6 Concurrency
7.7 A Dynamic Model
7.8 Summary
7.9 Solutions/Answers

7.0 INTRODUCTION
In designing any system or in general life activities, you must have observed that
whenever some actions are triggered, some operation/ something is done. From daily
life, you can see that a ring tone is produced when you press a bell button. This means
some event has taken place as a result of some trigger. The dynamic model covers this
aspect of the systems.
The dynamic model shows the time-dependent behaviour of the system and the
objects in it. Events can be defined as “something that happened at a point of time”.
The logical correctness of events depends on the sequences of interactions or events.
The dynamic model is important for interactive systems
You can understand a system by first looking at its static structure, the structure of its
objects, and their relationships over time. Aspects of a system concerned with time
and changes are represented with the dynamic models. Control describes the
sequences of operations that occur in response to external stimuli, without considering
what operations to do, what they operate on, or how they are implemented.
In this unit, we will discuss the basic concepts of dynamic modeling, covering events
and states. The major dynamic modeling concepts are events, which represent external
stimuli, and states, which represent the values of objects. The state diagram is a
standard computer science concept (a graphical representation of finite state
machines). Emphasis is on using events and states to specify control rather than as
algebraic constructs. We will also cover the state diagram and concept of concurrency.

7.1 OBJECTIVES
After going through this unit, you should be able to:
 explain events and transition,
 design state diagrams,
 explain the elements of the state diagram,
 use advanced concepts in dynamic modeling,
 explain, concurrency, and
 represent the dynamic model of systems.

7.2 EVENTS

1
An event is some action-oriented result, such as mouse click, applying a brake on
a car etc. You might have experienced that the appropriate action takes place
whenever you click on a mouse.

You may observe that an event has no specific time period duration. You can click
on a mouse and keep it pressed as long as you want. So, as far as events are
concerned, nothing is instantaneous. An event is simply an occurrence. An event is
actually a one-way transmission of information from one object to another, but
sometimes it may be an event that occurs on a single object and changes that object's
state.
Two events can take place at the same time or one after the other. Also, any two
events may occur independently of each other or simultaneously. For example, two
trains can depart simultaneously for two different places or depart from the same
place, but one after the other. Any two events can be independent as well as
dependent on each other.
Two events that are unrelated and occur simultaneously are known as concurrent
events. They do not affect each other. In a distributed system, you will notice
concurrent events and activities. You will not find any particular order between the
two events because they can occur in any order.
An object sending an event to another object may expect a reply, but the reply will
be a separate event from the second object. So, you may see conversations between
two objects as a combination of two or more events.
Event Classes: Every event is a unique occurrence; an event class is a name to
indicate common structure and behaviour. Some events are simple signals, but
most event classes have attributes indicating the information they convey. For
example, events like train depart which have the attributes train number, class, city,
etc. Not all the attributes of objects need to contribute to attributes of events.
Here, you must note that the event's time is an implicit attribute of all [Link]
events convey information in the form of data from one object to another. Sometimes,
some classes of events only signal that something has occurred, while other classes of
events convey data values. The data values conveyed by an event are its attributes; it
implies the value of data objects involved in events.
Event class name (attributes)
Sometimes event refers to an event instance or event class. Example of some events:

 Mouse button clicked (left click, location)

 Digit dialled (digit)
 Phone receiver lifted.
Events include error conditions as well as normal occurrences.
Scenario and Event traces
A scenario is seen as a sequence of events that occurs during one particular
execution of a system. As far as the scope of a scenario is concerned, it varies. It may
include all events in the system or only some events from some selected objects
involved in the event. An example of a scenario can be the historical records of
executing a system or a thought experiment of executing a proposed system.
Now, let us discuss states and state diagrams.

7.3 STATE AND STATE DIAGRAM

2
 Dynamic Modeling
The state of an object can be decided by the current values associated with the
attributes of that object.

State
A state is a condition during the life of an object, or an interaction during which it
satisfies some condition, performs some action, or waits for some event to occur. An
object remains in a state for a finite (non-instantaneous) time.
Actions are atomic and non-interruptible. A state may correspond to ongoing
activity, such as activity being expressed as a nested state machine. Alternately,
ongoing activity may be represented by a pair of actions, one that starts the activity on
entry to the state and one that terminates the activity on exit from the state. So
you can see that activities are the agents that are responsible for the change in state.
Also, a state has its duration, and most of the time, a state is associated with some
continuous activity.
A state must have initial states and final states. A transition to the enclosing states
represents a transition to the initial state. A transition to a final state represents the
completion of activity in the enclosing region. Completion of activity in all concurrent
regions represents the completion of activity by the enclosing state and triggers a
“completion of activity event” on the enclosing state. Completion of the outermost
state of an object corresponds to its death.
Notation
A state is shown as a rectangle with rounded corners. It may have one or more
compartments. The compartments are all optional. They are as follows:

 Name compartment holds the (optional) name of the state as a string. States
without names are “anonymous” and are all distinct. It is undesirable to show
the same-named state twice in the same diagram.

 The initial state is shown by a solid circle.

 The final state is shown by a bull’s eye.

Creating a State Diagram
Let us consider the scenario of travelling from station A to station B by the Bus Stand.
Following is the example of a state diagram of such a scenario. It represents the
normal flow. It does not show the substates for this scenario.

Depart
Bus Stand A

Bus Stand B

At Bus Stand
From Bus Stand B

Figure 7.1: An example of flow in a state diagram

Statechart Diagrams

3
Objects have behaviours and states. The state of an object depends on its current
activity or condition. A statechart diagram shows the possible states of the object
and the transitions that cause a change in state.

The statechart diagram shown in Figure 7.2 models the login part of an online banking
system. Logging in consists of entering a valid social security number and personal id
number and then submitting the information for validation.

Figure 7.2: Statechart diagram of login

Getting PIN Submit Validating

Do/ Validate PIN no

[Valid]/ Start
transaction
Initial State
Action [not valid] / Display error message
Press key [key ! = tab]

Rejecting Cancel / Quit

Event Guard

Logging in can be factored into four non-overlapping states: Getting PIN,

Validating, and Rejecting. A complete set of transitions comes from each state that
determine the subsequent state.

States are rounded rectangles. Transitions are arrows from one state to another. Events
or conditions that trigger transitions are written beside the arrows. Our diagram has
self-transition on Getting PIN.

The initial state (black circle) is a dummy to start the action. Final states are also
dummy states that terminate the action.

The action that occurs as a result of an event or condition is expressed in the form of
action. While in its Validating state, the object does not wait for an outside event to
trigger a transition. Instead, it performs an activity. The result of that activity
determines its subsequent state.
You can observe that a statechart diagram shows the sequences of states that an object
or an interaction goes through during its life in response to received stimuli and its
responses and actions. Or, in other words, you can say that:

“The state machine is a graph of states and transitions that describes the
response of an object of a given class to the receipt of outside stimuli. A state
machine is attached to a class or a method”.
A statechart diagram represents a state machine. State symbols represent the states,
and the transitions are represented by arrows connecting the state symbols. States may
also contain sub diagrams by physical containment and tiling.

 Check Your Progress - 1

1) What is a statechart diagram?
…………………………………………………………………………………………
………………………………………………………………………………
2) What is a UML state diagram?
…………………………………………………………………………………………
………………………………………………………………………………

4
 Dynamic Modeling
3) Draw a state diagram for a mobile phone system.
…………………………………………………………………………………………
………………………………………………………………………………
Now, let us discuss the basics components of a state diagram.

7.4 ELEMENTS OF A STATE DIAGRAM

We have seen different symbols used, and their meaning is a state diagram. Table7.1
explain different symbols used in State Diagrams
Table 7.1: State Diagram Symbols

Elements and its Description Symbol

Initial State: This shows the starting point or first activity
of the flow. It is denoted by a solid circle. This is also
called a pseudo state, where the state has no variables
describing it's further and no activities to be done.
State: Represents the state of an object at an instant of
time. There will be multiples of such symbols in a state
diagram, one for each state of the object, denoted by a
rectangle with rounded corners and compartments (such as
a class with rounded corners to denote an object).
Transition: An arrow indicating the object to transition
from one state to the other. The actual trigger event and
action causing the transition are written beside the arrow, Event / Action
separated by a slash. Transitions that occur because the
state has completed an activity are called “triggerless”
transitions.
History States: A flow may require that the object go into
a trance or wait state, and on the occurrence of a certain
event, go back to the state it was in when it went into a H
wait state — its last active state. This is shown in a state
diagram with the help of the letter H enclosed within a
circle.
Event and Action: A trigger that causes a transition to
occur is called an event or action. Every transition need
Event / Action
not occur due to the occurrence of an event or action
directly related to the state that transitioned from one state
to another. As described above, an event/action is written
above a transition that it causes.
Signal: When an event causes a message/trigger to be <<Signal>>
sent to a state that causes the transition, then that message Event/Action
sent by the event is called a signal.
Event / Action

Final State: A bull's eye symbol shows the end of the

state diagram, also called a final state. A final state is
another example of a pseudo state because it does not
have any variable or action described.

5
Note: Changes in the system that occur, such as a background thread while the main
process is running, are called “substates”. Even though it affects the main state, a
substate is not shown as a part of the main state. Hence, it is depicted as contained
within the main state flow.

7.5 ADVANCED CONCEPTS IN DYNAMIC

MODELING
Now let us look into advanced concepts in Dynamic Modeling. Entry and exit actions
are part of every dynamic model. Let us see how they are performed.

Entry and Exit Actions

The following special actions have the same form but represent reserved words that
cannot be used for event names:
‘Entry’ ‘/’ action-expression: An atomic action performed on entry to the state.
‘Exit’ ‘/’ action-expression: An atomic action performed on exit from the state.
Action expressions may use attributes and links of the owning object and parameters
of incoming transitions (if they appear on all incoming transitions).
The following keyword represents the invocation of a nested state machine:
‘do’ ‘/’ machine-name (argument-list).
The machine-name must be the name of a state machine that has an initial and final
state. When this state is entered, after any entry action, the execution of the nested
state machine begins with its initial state. If the nested machine has parameters, then
the argument list must match correctly.
Example
Typing Password

Entry/set echo invisible

Exit/ set echo normal
Character / handle character
Help / display help

Figure 7.3: Entry-exit Action

The internal transition compartment holds a list of internal actions or activities

performed in response to events received while the object is in the state, without
changing state.
The format to represent this is:
event-name argument-list ‘[‘guard-condition’]’ ‘/’ action-expression
Each event name ‘or pseudo-event name’ may appear at most once in a single state.
You can see what happens when an event has to occur after completing some event or
action; the event or action is called the guard condition. This guard
condition/event/action is depicted by square brackets around the description of the
event/action (in other words, in the form of a Boolean expression). The transition
takes place after the guard condition occurs.

 Check Your Progress - 2

1) What is a guard condition? Explain it with an example.
…………………………………………………………………………………………
……………………………………………………………………………………
………………………………………………………………………………

6
 Dynamic Modeling
2) What are two special events?
…………………………………………………………………………………….……
……………………………………………………………………………..……
………………………………………………………………………………
3) What is a self-transition?
…………………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
………………………………………………………………………………
Now, let us discuss the concept of the concurrent object.

7.6 CONCURRENCY
You are already familiar with the term concurrent lines, which goes without affecting
other operations. Similarly, when objects can change state independently in a system,
they are termed concurrent objects.
In a dynamic model, some systems are described as a set of concurrent objects, each
with its own state and state diagram.
An expansion of a state into concurrent substates is shown by tiling the graphic
region of the state using dashed lines to divide it into subregions. Each subregion is a
concurrent substate. Each subregion may have an optional name and must contain a
nested state diagram with disjoined states.
Composite States
You can say that a state can be decomposed using and-relationships into
concurrent substates or using or-relationships into mutually exclusive disjoint
substates. A given state may only be refined in one of these two ways. Its substates
may be refined in the same way or the other way.
A newly-created object starts in its initial state. The event that creates the object may
be used to trigger a transition from the initial state symbol. An object that transitions
to its outermost final state ceases to exist.
An expansion of a state shows its fine structure. In addition to the (optional) name
and internal transition compartments, the state may have an additional compartment
that contains a region holding a nested diagram. The text compartments may be
shrunk horizontally within the graphic region for convenience and appearance.
Sequential Substates
Dial Number
Partial Dial
Figure 7.4: States Sequence
Entry / start dial Entry / member append (n)
In Figure 7.4, you
tone can
exit/ see
stop that dial a number process state is further divided into its
Dial, Validate
dial tone
sequential substrates such as, when it is entering number state then the state can be
named as “Partial Dial” in which the user is still entering
Digit (n)
the number the action is
“append in digits” then next state will validate the number and so on.
A state diagram for an assembly is a collection of state diagrams, one for each
component. Aggregation means concurrency. Aggregation is the “and-
relationship”, you will see, it is the combined states of all component diagrams. For
example, the state of a Car as an aggregation of components states, the Ignition,
Transmission, Accelerator, and Brake. Each component state also has states. The state

7
of the car includes one substate from each component. Each component undergoes
transitions in parallel with all others.
Semantics
An event is a noteworthy occurrence. For practical purposes in state diagrams, it is
an occurrence that may trigger a state transition. Events may be of several kinds
(not necessarily mutually exclusive): The event occurs whenever the value of the
expression changes from false to true. Note that this is different from a guard
condition: A guard condition is evaluated once whenever its event fires; if it is false,
the transition does not occur, and the event is lost. Guarded transitions for one object
can depend on another object being in a given state.

7.7 A DYNAMIC MODEL

Now you are familiar with events and their occurring time. The dynamic model
describes those aspects of the system concerned with the sequencing of operations
and time - events that cause state changes, sequences of events, states that define the
context for events and the organization of events and states. The dynamic model
captures control information without regard for what the operations act on or how
they are implemented.
The dynamic model is represented graphically by state diagrams. A state is an
abstraction of an object’s attribute values and links, where sets of values are grouped
together into a state according to properties that affect the general behavior of the
object. A state corresponds to the interval between two events received by an object
and describes the “value” of the object for that time period. Each state diagram shows
the state and event sequences permitted in a system for one object class. State
diagrams also refer to other models: actions correspond to functions in the functional
model; events correspond to operations on objects in the object model.
The state diagram should adhere to OMT’s notation and exploit the capabilities of
OMT, such as transition guards, actions and activities, nesting (state and event
generalization), and concurrency.
Here is the sate transition diagram for a digital watch.

Mode Button
Display Set Hours
Press
Button/change
Do/Display Current Time Do/Display Hours Hours

Mode Button

Set seconds Set Minutes

Mode
Do/Display Seconds Do/Display Minutes
Button
Press
Press Button
Button Change Change
Seconds Minutes

Figure 7.5: State Transition diagram for digital watch

In Figure 7.5, you can see that the state diagram of a digital watch is given where the
user wants to set Hours, set Minutes, and then set seconds.

8
 Dynamic Modeling
 Check Your Progress - 3
1) Give a Concurrent substates diagram for classroom and exam held.
…………………………………………………………………………….……
……………………………………………………………………….……
……………………………………………………………………….
2) Describe the Dynamic Model.
…………………………………………………………………………….……
……………………………………………………………………….
3) Give a sample of a Dynamic Model.
…………………………………………………………………………….……
……………………………………………………………………….……
……………………………………………………………………………
……………………………………………………………………….
4) Show, with an example, that relatively high-level transitions result when outside
events stimulate the system or program.
…………………………………………………………………………….……
……………………………………………………………………….……
……………………………………………………………………….……
……………………………………………………………………….

7.8 SUMMARY
This unit explained dynamic modeling. The dynamic model is the model which
represents the control information: the sequence of events, states and operations that
occur within a system of objects. It has scenarios to occur with meaningful
constraints. This unit explained events and [Link] event is triggered by an
instantaneous action. One kind of action is sending an event to another object. An
external event, also known as a system event, is caused by something outside our
system boundary. An internal event is caused by something inside our system
boundary. States may be “nested.” A nested state usually indicates a functional
decomposition within the “super” state. The term macro-state is often used for the
superstate. The macro-state may be composed of multiple micro-states.

The basic notion is that the system is always in one state, and never in more than one
state (at any given level). The system remains in that state until a transition is
triggered by an external event. Transitions take no time to occur. There is no time in
which the system is not in one of the defined states. State diagrams must be created
for state-dependent objects with complex behaviour like Use Cases, Stateful
session, Systems, Windows, Controllers, Transactions, devices, and role mutators.
Actions are associated with transitions and are considered as processes that occur
quickly and are not interrupted.

7.9 SOLUTIONS/ANSWERS TO CHECK YOUR

PROGRESS

9
Check Your Progress - 1
1) State diagrams (State Chart Diagram) describe all the possible states that a
particular object can get into and how the object’s state changes as a result of
events that reach the object. It states all possible states and transitions.
2) The UML state diagram is used to represent the states and behaviour of the
system. It shows the events and their impact on the states of the objects in the
system. Also, using a state diagram, one can notice the behaviour of an object in
reaction to an event.
3)
Time out
After 20 Sec
Dial Dight Do/ Play message

Press Buttons After 20 Sec

Dialed digit (n)

Dialing

Invalid

Do / Play message Invalid number

Dialed digit
valid/connect

Busy busy Connecting

Do / Play message

Ringing
Talking
Do/ Play ring tone

Figure 7.6: State Diagram for a Mobile

Check Your Progress - 2

1) The guard-condition is a Boolean expression written in terms of parameters of
the triggering event and attributes and links of the object that owns the state
machine. The guard condition may also involve tests of concurrent states of the
current machine (or explicitly designated states of some reachable object); for
example, “in State1” or “not in State2”. State names may be fully qualified by
the nested states that contain them, yielding path names of the form ''State1:
State2::State3''; this may be used if the same state name occurs in different
composite states regions of the overall machine.
2) There are two special events, “entry” and “exit”. Any action that is marked as a
link to the entry event is executed whenever the given state is entered via
transition. The action associated with the exit event is executed whenever the
state is left via transition.
3) If there is a transition that goes back to the same state, it is called “self-
transition.” The exit action would be executed first with a trigger action, then
the transition’s action and finally the entry action. If the state has an associated
activity as well, that activity is executed after the entry action.
Check Your Progress - 3
1)
Taking Class

Incomplete

10
Minor 1 Minor 2
 Dynamic Modeling

Figure 7.7: Concurrent Substate diagram

Figure 7: concurrent substates for Classroom Examination

In Figure 7.7, concurrent substates have been taken. After passing Minor 1 test, you
can give Minor 2 test. Term minor project of that semester minor should be done
before the Major exam of that semester.
2) The dynamic model specifies allowable sequences of changes to objects from
the object model. It includes event trace diagrams describing scenarios. An
event is an external stimulus from one object to another, occurring at a
particular time. An event is a one-way transmission of information from one
object to another. A scenario is a sequence of events that occurs during one
particular execution of a system. Each basic execution of the system should be
represented as a scenario.
3) Dynamic model for Car:
Accelerator and Brake Applies Accelerator or Brake
Accelerator Applies Accelerator
Brake Applies Brake
off Put off the car
on Put on the car
off
on
press Accelerator
release Accelerator
press brake
release brake
4) In this diagram, you can observe if that initial state is state X; if event Z occurs,
then state X is terminated, and state Y is entered.

X
State (Event dependency)

Figure 7.8: State event dependency

11
7.9 REFERENCES/FURTHER READINGS

 Grady Booch, James Rumbaugh and Ivar Jacobson,“ The Unified

Modeling Language User Guide”, 2nd Edition, Addison-Wesley Object
Technology Series, 2005.
 Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young,
Jim Conallen, Kelli A. Houston, “Object-Oriented Analysis and Design
with Applications,” 3rd Edition, Addison-Wesley, 2007.
 James Rumbaugh, Ivar Jacobson, and Grady Booch, “Unified Modeling
Language Reference Manual,” 2nd Edition, Addison-Wesley Professional,
2004.
 John W. Satzinger, Robert B. Jackson, and Stephen D. Burd, “Object-
oriented analysis and design with the Unified process,” 1st Edition,
Cengage Learning India, 2007.

12
UNIT 8 FUNCTIONAL MODELING
Structure Page No.

8.0 Introduction
8.1 Objectives
8.2 Functional Models
8.3 Data Flow Diagrams
8.4 Features of a DFD
8.4.1 Processes
8.4.2 Data Flows
8.4.3 Actors
8.4.4 Data Stores
8.4.5 Output symbol
8.4.6 Constraints
8.4.7 Control Flows
8.5 Design Flaws in DFD
8.6 A Sample Functional Model
8.7 Functional Vs. Object Vs. Dynamic Model
8.8 Summary
8.9 Solutions/ Answer to Check Your Progress
8.10 References/Further Reading

8.0 INTRODUCTION
Object Modeling Technique (OMT) is a very popular and established approach for the
development of object-oriented systems. OMT model deploys many visualization
techniques to explain the working of complex systems in a simple manner. OMT finds
application in real-world application domains like the field of medical and health care,
telecommunications, transportation and tourism, online shopping etc.
The basis of the OMT model is three main types of models as proposed by James
Rambaugh. The first is Object Model, which is based on classes and objects and the
features like encapsulation, inheritance, concurrency and abstraction. Next is
Dynamic, which depicts states of objects, transition between states and events that
trigger the transition from one state to another. The third and final model is the
Functional model, which elaborates on concepts like how data flows between various
objects called actors, processes, and data stores. This unit focuses on the functional
model and all its features explained with the help of data flow diagrams up to level 3
decomposition.

8.1 OBJECTIVES

After going through this unit, you should be able to:

 Explain the functional model,
 Comprehend Data Flow Diagram(DFD) and its purpose in OMT,
 Describe the features of DFD and various symbols used in it,
 Explain the common design flaws in making a DFD,
 Describe the working of a Sample Functional Model (DFD up to 3rd Level) ,
and
 Describe the relation of functional model to object and dynamic model.

1
Functional Modeling
8.2 FUNCTIONAL MODELS

A functional model is a graphical representation of the object-oriented analysis model

and focuses on various processes to be performed on input data to obtain the desired
output. Here, the system is viewed as a black box that accepts inputs, transforms them
by applying various processes/functions and then produces the outputs. A functional
model does not show how the transformations occur, when they are performed and
why there is a need to do the calculations.

The input to the system can be numbers typed by an operator or control signals
produced by a sensor, or some big data files received over a network. The processes
that work on the inputs may be performing some arithmetic or logical calculations or
applying some algorithm to generate one or more outputs in the form of some
numerical value or some control signals that may be used to drive other devices. We
use data flow diagrams (DFD) to explain the flow of data from input to output. We
can also say that by using the functional model, the Software Requirements
Specification (SRS) document is converted to the Data Flow Diagram (DFD) model.

8.3 DATA FLOW DIAGRAM

The DFD is a simple graphical technique that represents an entire software system in
terms of inputs fed to it, processing applied on these inputs and the outputs produced
by the system, and various data stores used internally to store the data/results. The
focus is on the flow of data input to a system by a source, transformed by the
application of various processes and then sent to a destination as output. The sources
that produce data and the destination that consumes the processed data are known as
Actor objects.

It is very easy to understand the functionality of a system with DFD as there are very
few symbols used in it, and the basis of DFD is to divide a complex problem into
smaller components. Also, it is said that human intellect works on the fundamental of
the division of complex concepts into smaller and greater numbers of concepts to
make the understanding easier. Hence, DFD uses a hierarchical approach that starts
from an abstract model that depicts high-level functions and further introduces details
as we go down the hierarchy and create sub-functions. DFD is also called as a bubble
chart.

8.4 FEATURES OF A DFD

The features of DFD can be explained with the help of primitive symbols used. There
are five different symbols used to draw a DFD, as shown in Figure 8.1.
1. Circle: Labelled circles called bubbles are used to show the processing or
transformations applied on data. The name of the corresponding function is
written inside the bubble.
2. Arrow: A labelled arrow is used to represent information and/or data flow
occurring between two processes or between an external entity and a process.
3. Rectangle: It is used to show an actor who communicates with the software
system. The actor may give input (source) to the system or consume the
output produced (sink). An actor may be a human being e.g. accountant, or
any hardware, maybe a sensor that is feeding signal as input to a process.

2
 4. Two parallel lines or rounded rectangle: It is used to represent a Data Store Modeling
whose name is written between these two parallel lines. The data store is
connected to a process that uses it.
5. A rectangle with the right top corner chopped off represents the output in
the form of a hard copy.

Figure 8.1: Symbols used to draw DFD

Now let us discuss all components of DFD in detail.

8.4.1 Processes

A circle represents a process and the name of function performed by it is written

inside the circle. Process denotes a function that is to be performed on one or more
inputs to produce one or more outputs. The purpose of the process is to transform
data. An example of a process can be Calculate_sum. This process is given three
integers as input, and it produces the result as a sum (an integer), as shown in Figure
8.2. Another example is shown in Figure 8.3 where a process Perform_division
accepts the dividend and divisor as input and produces quotient and remainder as
outputs.

sum
b
Calculate_sum

Figure 8.2: Process Calculate_Sum

3
Functional Modeling

dividend Quotient

Perform
_
division
Remainder
divisor
Figure 8.3: Process Perform-division

A process may get input from an external entity called an actor (as shown in Figure
8.4) or from another process (i.e. the output of one process may be input to another
process). The number of inputs and outputs for a process is fixed. There may be some
non-functional components that provide inputs to a process. For example, a data store
may be read to collect input from a file residing on it. Under such circumstances, the
process may have side effects because of which the functional model can not provide
results of the process. Also, in this situation, the results of the process will depend
upon the behaviour of the software system, as explained by the dynamic model.
number

Log-
User calculator

log of number
Figure 8.4: Process accepting input from an actor

8.4.2 Data Flows

It denotes the flow of data between any two processes or between a process and an
actor, or between a process and a data store. It is represented by an arrow or a directed
arc annotated with the name of the data item that it carries at that point in time. Data
flow does not modify the content that it carries.
The data item carried by the data flow arrow may be sent to more than one
destination. There are two ways in which the data value is forked.
1. A single same value can be sent to more than one place as indicated by a fork
with 3 outputs, where each of the arrows would be connected to a different
process. As shown in Figure 8.5, the value square_root can be sent to three
different places. In this case, there is no need to give a label as the value
remains the same as the input.
4
 Modeling

Square_root

Figure 8.5: Single value sent to three different places

2. An aggregate value can be split into many components. Each of the component
is sent to a different process or actor. A fork has depicted this with three
arrows coming out of it. In this case, label is written on each arrow, as shown
in Figure 8.6
address line

city

Address
State

Figure 8.6: Aggregate value Address split in three components

SYNCHRONOUS VS ASYNCHRONOUS DATA FLOW

The DFD in Figure 8.7 shows three data flows—the data item integer flowing into
read_number process, the data item named integer flowing from the read_number
process to find_modulus process, data item named Modulus_number flowing out from
the process find_modulus.
In order to explain this concept, we have shown a part of a software system that reads
a number and then finds its modulus. In the case of Synchronous data flow, the output
produced by process “read_number” is immediately used by the process
“find_modulus”, a data flow arrow that directly connects both processes. Hence the
speed of operation of both the processes is the same. This is depicted in Figure 8.7.

number

read_ find_
data-item number modulus
Modulus_number

Figure 8.7- Synchronous data flow

In the case of Asynchronous data flow, as shown in Figure 8.8, there sits a data source
between these two processes. So, the first process produces the data stored in the data
5
Functional Modeling source. Later on, another process can use this as we can see that the two processes are
independent of each other. This type of data flow is called asynchronous.

read_ find_
number modulus
Modulus_number
data-item

number

Figure 8.8- Asynchronous data flow

8.4.3 Actors

An actor is represented using a rectangle. An actor is an external entity that produces

the data for the system or consumes the information produced by the system. Actors
lie at the boundary of the system. They are also called terminators because the data
flow is terminated at the input as a source or output as a sink of the system.
We can also say that actors are those that perform some action, for example, a
customer of a sales system or a sensor in a temperature management system. The
actions performed by actors are explained in the dynamic model in detail, and with
reference to DFD, the actor's role is confined only to providing input to system or
accepting output produced by the system. The symbol used to represent an actor is a
rectangle. An example of two actors, namely Employee and Accountant, interacting
with the Payroll_Processing system is shown in Figure 8.9.

Employee Salary_information

Payroll_Proc Salary_information
Employee- essing
details

Accountant

Figure 8.9: Actors interacting with a system

8.4.4 Data Store

A data store is a passive object that represents a repository of data in the software
system and is represented using two parallel lines. A data store symbol represents
either a data structure or a physical file residing on the disk. We need a data store
when the system must store the data for future use by a process. Each data store is
connected to one or more processes. Since the data store is a passive object, it does
not generate any operation and is used only for reading or writing data into it. Data
can be written/modified into the data store using the input arrow, or data may be
retrieved from the data store represented using the output arrow. The output arrow is
annotated with the name of content retrieved from the data store; if unlabeled, it

6
denotes full data retrieval. If the arrow is two-way, it represents both storage and Modeling
retrieval.

Examples of data stores are inventory, library bookstores, payments databases, etc. An
example of a Library_Database is shown in Figure 8.10. Another data store named
Sales_Database that stores sales details like item name, quantity, cost, date, etc., is
being used by the process Find_Average_Sales to retrieve the average value of sales
in Figure 8.11.

Books_details

Library_Database

Books_details
Figure 8.10: Library data store

Sales_details

Sales_Database

Find_
Average
_Sales Average-Sales

Figure 8.11: Sales-database used by process

Find_Average_Sales

8.4.5 Output Symbol

Whenever a hardcopy is generated, we use the output symbol which is a rectangle

with the top right corner chopped off.

8.4.6 Constraints

A constraint represents the relationship between two different objects at the same time
or between different values of the same object at different times. Constraints mean the
conditions or limitations required to be fulfilled over a period of time. One can add
new principles or modify the existing ones with the help of constraints.
All models of object-oriented analysis can have constraints in them, as explained
below: -.

7
Functional Modeling 1. Object Modelling: Here, constraints show the relationship between objects.
In this type of modelling, constraints represent the relationship between the
different values that an object may take at different times.
2. Dynamic Modelling: Here, the constraints define the relationship between
the states and events of different objects.
3. Functional Modelling: In this, the constraints define the limitations on the
transformations and computations that can be done on objects.

A constraint between values of an object over time is often called an invariant. For
example, in Physics, when a vector is rotated, its length does not change, so the length
of a vector is invariant during rotation. The behaviour of operations can be explained
with the help of invariants. A constraint is represented in DFD as a string written
inside braces.

Figure 8.12 shows a DFD in which, depending on the department of an employee,

either he is given an incentive or an increment. As it is visible, if a department is
Sales, then the incentive is calculated, and if the department is HR, then an increment
is calculated.

Incentive
{Dept: Sales} Calculate_
Incentive

Employee database

Calculate_ Increment
{Dept: Sales} Increment

Figure 8.12: Constraints in DFD

8.4.7 Control Flows

A control flow signal is generated by a process so as to inform other processes to start

or stop its processing. This is typically a Boolean value passed to another process on
the basis of which the other process decides its course of action. It is denoted by a
dotted line.
An example of control flow is shown in Figure 8.13. The customer enters the
password in a net banking website, which is verified. Only after that, he can transfer
money to somebody else’s account.

8
 Modeling

Verify Bank database

Password

Password

Customer amount

Transfer_
Amount
Confirmation

Figure 8.13: Control How to inform Transfer_amount process to start processing

8.5 DESIGN FLAWS IN DFD

There are certain limitations of the DFD, which may lead to a few design flaws. The
most disturbing limitation is that with DFD, we cannot visualize the complete picture
of the software system and hence some of the essential physical entities are left out.
Also, at times, it can be tough to conceptualize an object-oriented structure in a
hierarchical format.

There are different categories of design flaws:

1. Flaws committed by beginners:
 The context diagram must have just one bubble that represents the
complete software system at an abstract level and has arrows of input
and output interactions corresponding to data flows with the world.
Many designers draw more than one bubble in the context diagram,
which must be avoided.
 External entities are drawn only in the context diagram. However,
many designers represent the external entities at all levels of DFD,
which is not correct.
 Each process/ bubble should be decomposed into between 3 to 7
bubbles, but sometimes designers do not follow this principle.
Different levels of DFD must be balanced. Balancing of DFD means
that the data flow into or out of a process symbol must match the flow
at the next higher Level of the DFD.
2. Representing control information in a DFD:
One must clearly understand that DFD is not a flow chart. DFDs cannot
capture the following important features ( When, Why and How): -
 When: As the Time-dependent behaviour of a software system cannot
be shown in a DFD, therefore the transformations are done by
processes that cannot be shown in a DFD.
 Why: DFDs cannot specify why the value of an object has changed.

9
Functional Modeling  How: DFDs cannot mention the frequency of transformations done on
an object.
 If a bubble X invokes either the bubble Y or the bubble Z depending
upon some conditions, we need only to represent the data that flows
between bubbles X and Y or bubbles X and Z and not the conditions
depending on which the two modules are invoked.
3. Mistakes arising out of poor Diagramming approach: Black holes, miracles
and grey holes.
Such design flaws occur when the outputs from a process do not match its
inputs. A few examples of this design flaw are listed below:
 Black hole: If a processing step has just input flows, but no output
flows.
 Miracle: If a processing step has just output flows, but no input
flows.
 Grey hole: As the name suggests that it is a confusing situation. Such
a situation may arise when a processing step has outputs that are
greater than the sum of its inputs - e.g., its inputs could not produce
the output shown.
4. Illegal data flows with data store: It is very important to realize that a store
can only be connected to bubbles using data arrows. A data store can never be
connected to another data store or to an external entity.

☞ Check Your progress-1

1) What is the Functional model? Why is it required in Object-oriented analysis
and design?

2) What do the data stores represent in a DFD?

3) What do you understand by Data Flow Diagram? Explain with a diagram.

10
 Modeling

4) Differentiate between Synchronous and Asynchronous data flow.

5) What do you understand by “balancing a DFD”? Explain.

6) Explain the design flaws arising out of a poor Diagramming approach.

8.6 A SAMPLE FUNCTIONAL MODEL

(EXAMPLE DFD UPTO 3rd LEVEL)

Before you learn to draw a DFD for a complex system, a few important guidelines for
drawing a functional diagram are mentioned below:

1. Every process must have a meaningful name which is unique and a unique
number as its identifier.
2. The Level-0 DFD, also called a Context Diagram, must have just one process.
3. Every data flow arrow must be named.
4. A bubble should be decomposed into a minimum of three and a maximum of
seven bubbles in further level. Hence, each DFD can have no more than seven
processes.
5. A process can be connected only with another process, external entity and
data store.
6. No two external entities can be connected directly with each other.
7. No loop is allowed in a DFD.
8. There should be logical consistency in all levels of DFD.
9. The data flow of DFD should be easy to understand.
10. We should try to use arrow's direction to depict the order of events. For
explaining the order of occurrence of the event, a flow chart should be used.
11
Functional Modeling 11. The numbering of the bubbles is to be done very carefully. Each bubble is
given a unique identification number. The bubble in the context diagram that
is Level- 0 is given “0” number. Bubbles in level-1 are numbered like 0.1, 0.2,
0.3 and so on. Bubbles in level-2 that are formed after factoring/ decomposing
each of the bubbles of level 1. Say 0.1 bubble (of level 1) is factored, its
children are numbered as 0.1.1, 0.1.2, 0.1.3, 0.1.4 and so on. Hence, we can
say if a bubble having the number “x” is exploded, its children (that is,
bubbles at the next Level of DFD) are numbered as x.1, x.2, x.3 and so on.
So, suppose a bubble has number 0.4.5, it means it belongs to Level- 2 (Level
is equal to the number of dots), and it is 5th bubble after decomposing 0.4th
bubble (which was at level- 1). That means every bubble number will start
with “0”.

A complete working example of DFD up to level-3 is has been explained here. In

order to represent the DFD of a system, first of all level-0 DFD, also called as Context
diagram is drawn. It represents the complete software system at an abstract level by
showing just one bubble having arrows of input and output interactions,
corresponding to data flows, with the world.

The bubble is labelled as per the main context of the system, which is usually written
using a noun. The data flow arrows are annotated corresponding to various data items
that would be either supplied to system or generated from the system. This bubble is
numbered as “0”.

Functional Model for Online Shopping System

We have taken an example of DFDs up to level-3 for a website for Online Shopping
System (OSS) for buying products of various categories viz. apparel,food and
beverages, electronic items etc. There are two types of users, also called actors, who
interact with this OSS. These are the Administrator and the customer. The
Administrator is the sole incharge of the website and is responsible for all features and
facilities offered by the site.

Level- 0 DFD
Only the Login request and response for customer and Administrator are depicted in
this. The name of the process is “Online Shopping system” which is a noun. The
context diagram is shown in Figure 8.14.

Admin details Customer details

Online
Administrator Shopping Customer
System
Response Response

Figure 8.14: Context diagram for Online Shopping System

Level- 1 DFD
The context diagram is further decomposed in a hierarchical way to explain the
system's entire working. This is done by converting the Level-0 bubble into three to
seven bubbles which generally have labels denoting the functionality using verbs.
This produces level-1 DFD.

Since there are many functions pertaining to the customer side and administrator side,
the Level- 1 DFD for both is shown separately.

12
 Modeling
Level- 1 DFD : Customer side
The customer can interact with the OSS in one or more of the following ways.
1. Registration
2. Customer Login
3. Manage account
4. Purchase items
5. Make payment
6. Return item
The Level- 1 DFD is shown in Figure 8.15.

0.1 ctm database

Register

0.2
Login

0.3
Manage
Account

Customer
0.4 Item database/
Purchase
Item Order database

0.5 Credit card

Make
Payment company database

0.6
Return Order database
Item

Figure 8.15: Level 1 DFD for costumer side

In Level- 1 DFD, we have shown all the databases that are used by various processes.
As we can see, the process module's numbering is of type 0.x where 0 denotes that
this process’s parent is level 0. The DFD that is 0.x means this process module
belongs to Level- 1, x denotes the unique serial number in a DFD.

The process modules except Register, Login and Return items are complex in nature,
so they will be further decomposed into sub-processes in the next higher Level DFDs.
Hence, they are not explained here.

A new customer uses the Register module to register himself/herself by giving the
email id, username, password and mobile number for verification with OTP (one-
time-password).

These are stored in the customer database. Only after successful registration the
customer can login. While logging in, the credentials (username and password) are
validated by checking the customer database. Once it is validated, the customer can
Manage accounts, Purchase items, Make Payments and Return items if required.
13
Functional Modeling As we know, using DFD, the “when” part or the control flow cannot be explained, so
there is not any timing information.

Level- 1 DFD: Administrator side

The Administrator is the only person managing the addition of new items, managing
orders received by the company, taking care of deliveries, checking whether payments
are received or not, and generating various reports. The functions that the
Administrator can perform are listed here.
1. Admin Login
2. Manage category
3. Manage item
4. Manage order
5. Manage report
Various databases that are used by each process module are shown in Figure 8.16.

0.7 Administrator
Admin
database
Login

0.8 Category
Manage
category database

0.9
Manage Item database
Item

Administrator
0.10
Manage Order database
order

User database/Order
0.11
database/ Item
Manage
Reports database/Category
database/ Credit card
company database

Figure 8.16: Level 1 DFD for administrator side

14
Now, each of the processes of Level- 1 DFD may or may not be exploded into more Modeling
process modules depending upon the complexity of functionality performed by it.
Here, Login module is not exploded into submodules because the purpose of this is
quite simple, just the Administrator is going to Login to the OSS by using his
username and password, and this process module accesses the Admin database for the
same. The Administrator can perform the rest of the functionalities.

Level- 2 DFD
Again, each of the bubbles of level-1 DFD maybe decomposed into three to seven
more bubbles so that the functions can be explained at an atomic level. This expansion
generates level 2 DFD. Hence each process is decomposed into many sub-processes
so that all functions can be explained in a simpler manner. In most situations,
decomposition up to Level- 2 is sufficient to explain the functionality of the entire
software system. Level-2 DFDs for the Customer side and Administrator side are
shown separately.

Level -2 DFD: Customer side

Now, we have explained the customer side processes from Level- 1 DFD, one by one,
starting from DFD number 0.3 to 0.5.

Level- 2 DFD: Customer side, for “Manage Account” Module 0.3 of Level 1 DFD
The process “Manage Account” has been decomposed into three sub-processes View
Account, Change Password and Edit Profile. All of these three sub-processes interact
with the customer database, as shown in Figure 8.17.

Figure 8.17: Level 2 DFD of “Manage Account” process (0.3) of customer side

Level- 2 DFD: Customer side, for “Purchase Items” Module 0.4 of Level 1 DFD

15
Functional Modeling While purchasing items, the customer can search for an item (apply filters for color
selection and price range selection), search for available offers, and manage his
shopping cart. Different data stores that are accessed by these processes are shown in
Figure 8.18. The process “Manage cart” is further exploded to show all sub-processes
involved, in Figure 8.24 (Level 3DFD).

Customer credentials

0.4.1
Search
Item

Item database

0.4.2
Search
Offers

0.4.3
Manage
Cart Order database

Figure 8.18: Level 2 DFD of “Purchase item” (0.4) of customer side

Level- 2 DFD : Customer side, for “Make Payment” Module 0.5 of Level 1 DFD

To make a payment, the customer types in his / her credit card details that are verified
by the payment gateway by contacting the credit card database. After the payment is
made, the customer can cancel the order if he desires to. If not cancelled in the
stipulated time, the item details of the placed order are added to the company's order
database. This DFD is shown in Figure 8.19.

16 Figure 8.19: Level 2 DFD for “Make payment” (0.5) of customer side
Level -2 DFD: Administrator side Modeling

Now, we have explained the administrator side processes from Level 1 DFD, one by
one, starting from DFD number 0.8 to 0.11.

Level- 2 DFD: Administrator side, for “Manage Category” Module 0.8 of Level 1
DFD

The process “Manage Category” is meant to add a new category of items on the
website. In this new category, new items are added. An existing category may be
updated by changing its name or shifting the items here and there among existing
categories; maybe an item belongs to more than one category like Milk falls in the
Dairy products category as well as the Daily needs category. If the OSS company
thinks of not selling a few categories completely, then that particular category can be
deleted altogether. The categories list can also be viewed. The DFD, with all the sub-
processes explained here, is shown in Figure 8.20.

Figure 8.20 : Level 2 DFD “Manage category” (0.8) of administrator side

Level - 2 DFD : Administrator side, for “Manage Items” Module 0.9 of Level 1
DFD
Within the “Manage Items” process, the Administrator can add an item, delete item,
view an item, and update an item. Update item is considered here at an abstract level,
and its sub-processes are explained in Level 3 DFD, Figure 8.21.

17
Functional Modeling Administrator
credentials

0.9.1
Add
Item

0.9.2
Delete
Item

Item database
0.9.3
Update
Item

0.9.4
View
Item

Figure 8.21: Level 2 DFD for “Manage item” (0.9) of administrator side

Level- 2 DFD : Administrator side, for “Manage Order” Module 0.10 of Level 1
DFD
Corresponding to the “Manage orders” process bubble, the Administrator can
perform the followings:

 Acknowledge the order,

 View order details (cost of each item with item description and total bill),
cancel the order (in case the item is not available), and
 Dispatch the order (this includes sub-processes related to supplier, shipment,
returned item pick up; hence it is taken up in Level 3 DFD.).

For all these, the Order database has been accessed. This is shown in Figure 8.22.
Administrator
credentials

0.10.1
Acknowledge
Order

0.10.2
View Order

Order database

0.10.3
Cancel/
Review Order

0.10.4
Dispatch
Order

18 Figure 8.22: Level 2 DFD for “Manage order” (0.10) of Administrator side
Level 2 DFD – Administrator side, for “Manage Report” Module 0.11 of Level 1 Modeling
DFD

Corresponding to the process “Manage Report”, the Administrator can apply various
types of filters on different databases to generate various reports as required. For
example, given below a list of few reports that can be generated.
1. The report of users details along with their orders in a particular time duration
can be generated.
2. The report on items that are delivered can be generated.
3. The report on payments received by the company can be generated.
4. The report on various suppliers can also be generated by this process.
Various databases namely user, item, category, credit card company database are
accessed according to type of reports required. This DFD is shown in Figure 8.23.

Administrator
credentials

0.11.1
Generate users
reports User database

Order database
0.11.2
Generate delivery
reports

0.11.3 Credit card company

Generate payments
database
reports

0.11.4
Generate
suppliers Supplier database
reports

Figure 8.23: Level 2 DFD for “Manage Reports” (0.11) of Administrator side

Level- 3 DFD : Customer side, for “Manage Cart” Module 0.4.3 of Level 2 DFD

Further, we can see the decomposition of the “Manage cart” process of Level 2 DFD
on the customer side. Here, all sub-processes involved are Add item, View Cart, Edit
Cart, and check out. The corresponding databases that are accessed by each of the
processes are shown in Figure 8.24.

19
Functional Modeling

Customer
Credentials

[Link]
Add Items Item database

[Link]
View Cart

[Link] Order database

Edit Cart

[Link]
Checkout

Figure 8.24: Level 3 DFD corresponding to decomposition of “Manage cart” (0.4.3) of level 2 of
customer side

Level- 3 : DFD – Administrator side, for “Dispatch order” Module 0.10.4 of

Level 2 DFD
The sub-process “Dispatch order” comprises many sub-functions Hence, it is
exploded into three sub-processes: Contact Supplier, Contact Delivery Agent, Manage
Returns, and the corresponding databases, as shown in Figure 8.25.

Order Placed

[Link]
Contact
Supplier

Supplier database

[Link]
Contact Delivery
Agent

Shipment
database

[Link]
Manage Returns

Figure 8.25: Level 3 DFD after decomposing “dispatch order” (0.10.4)

bubble of Level 2 of administrator side

20
 Modeling
8.7 FUNCTIONAL Vs. OBJECT Vs. DYNAMIC
MODEL
The object-modeling technique (OMT) consists of three models that explain the
different aspects of the software system. These three models are as given below: -
1. Object Model: The purpose of this model is to show the static aspect of the
software system, including depicting the attributes and operations that an
entity can perform, i.e. Here, the focus is on how an object can be
implemented and what operations an object is capable of performing.
Diagrams: In an Object model, we use object diagram and class diagram.

2. Dynamic Model: The purpose is to show the control aspect, as well as the
temporal and behavioural nature of the software system. The sequencing of
operations is shown in the dynamic model. The focus is on when the
operations are done in response to an external stimuli.
Diagrams: We model the states, transitions, events and actions with the help
of interaction diagrams (like sequence and collaborative diagrams) and state
transition diagrams.

3. Functional Model: This model is used to depict the functional aspects by

showing various processes that include many sub-processes within them,
along with various transformations applied to data as it moves in the system.
This model focuses on what the operations do in terms of transformations on
objects.
Diagrams: We use data flow diagrams to show collaboration between
different objects to achieve the system's desired behaviour.

In order to explain any software system in totality, we need to understand the

relationship between all these three models. These three models work hand in hand for
the implementation of methods. The functional model acts as a guide to the methods.
The processes in the functional model correspond to operations in the object model.
Most of the time, there is a direct relationship between each Level.

A top-level process resembles an operation on a complex object. In contrast, lower-

level processes correspond to operations on more basic objects that are part of the
complex object or that implement it. Sometimes, one process corresponds to several
operations, and one operation corresponds to several processes.
In a functional model, various processes show objects that are related by function.
Most of the time, one of the inputs to a process can be identified as the target object,
and the remaining inputs are the parameters to the operations. The target object is a
client of the other objects because the target object uses other objects to perform the
operations. The target has complete knowledge of the clients, but the clients may not
know the target. The target object class is dependent on the argument classes for its
operations. Client-supplier relationships create the implementation dependencies
among classes. The clients' implementation is done by using supplier classes; hence,
client class depends upon the supplier classes.
A process is implemented as a method. If the same class of object is an input as well
as an output, then the object is usually the target, and the other inputs are arguments.
Data store is always considered as a target, irrespective of the situation, whether it is
input or output to a data store.

Whenever there is a process that interacts with a data store (provides input to data
store or gets output from the data store), it uses two methods, of which one is an
implicit selection or update of the data store. Further, if an input to or output from a
data store is provided or obtained by an actor, then the actor itself is the target.

21
Functional Modeling In the object model, if an input is an object and an output is a part of the object or a
neighbor of the object, then the object is considered as the target. If an output object is
created by making use of input parts, then the process represents a class method. If
none of these situations is true, then the target is often implicit and is not one of the
inputs or outputs. In most situations, the target of a process is the target of the whole
sub-diagram. In the object model, actors are explicit objects. Whenever there is any
interaction between the data store and actor, it is considered as operations with the
actor (which is nothing but object). The data flow values are the arguments or results
of the operations. Because actors are self-motivated objects, the functional model is
not sufficient to indicate when they act. The dynamic model for an actor object
specifies when it acts.

Data stores are also objects in the object model or attributes of objects. Each flow into
a data store is called an update operation. Each flow out of a data store is a query
operation with no side effects on the data store object. Data stores are passive objects
that respond to queries and updates, so the dynamic model of the data store is
irrelevant to its behaviour. A dynamic model of the actors in a diagram is necessary to
determine the order of operations. Data flows are values in the object model. Many
data flows are simply pure values, such as numbers, strings, or lists of pure values.
Pure values can be modeled as classes and implemented as objects in most languages.

Relation of Functional Model to Object Model

In the functional model we use four components that have one to one correspondence
with components of the object model. These are explained here.
Processes: Processes are the functions/ methods that are implemented in the objects in
Object Model.
Actors: Correspond to the object of Object Model.
Data Stores: These are nothing but the objects of the Object Model or the attributes of
the Objects.
Data Flow: Data flow that occurs as a result of operations performed on an object, is
shown in Object Model. We depict data flow to or from the data store corresponding
to a query or update operation in an Object Model.

Relation of Functional Model to Dynamic Model

In the functional model, we can specify how the operations are performed and which
arguments were required for those operations, whereas the dynamic model depicts the
timing of an operation. The dynamic model specifies when it acts on an active object
only, i.e. on an actor of functional model. The dynamic model does not mention
anything related to data stores as it is a passive object. The data store responds only to
the updates and queries that too in the functional model only.

☞ Check Your Progress - 2

1) State True / False for the followings:
a) External entities may appear at all levels of DFDs
b) A DFD captures the order in which the processes (bubbles) operate
c) A DFD model of a system represents the functions performed by
the system and the data flow taking place among these functions.

22
 2) What type of information can be represented in a dynamic model? Modeling

3) Why do we need many different levels in a DFD? What is the purpose of each
of them?

4) Draw a DFD up to level-1 to show the registration system to register a student

for subjects in a semester.

8.8 SUMMARY
In OMT there are three models namely Object Model, Dynamic Model and Functional
Model that are required to be generated in order to explain the detailed working of any
Software System in totality. In this unit, we have seen the design and working of the
functional model in order to address the question “What” the software system is
doing, and we have used Data Flow Diagrams to explain this. We have discussed the
features of a DFD in terms of different symbols used along with their purpose. The
symbols are used to denote process, data flow, actor, data store, constraints and
control flows. Next, the design flaws that can occur while making a DFD have also
been explained in detail in this unit. Further for the practical understanding of the
topic, generation of DFDs up to Level-3 has been done for an Online Shopping
System by decomposition of processes as we go from Level-0 to Level-3. Finally, an
attempt has been made to throw some light on the relation between the functional
model and the relation of the functional to the dynamic model.

23
Functional Modeling
8.9 SOLUTIONS / ANSWERS TO CHECK YOUR
PROGRESS

☞ Check your progress -1

1) Functional Model: A functional model provides a framework to demonstrate
the working of a software system in a graphical manner. It explains the
functions of internal processes with the help of DFD (Data Flow Diagram).

Importance of Functional model in OOAD: The Functional Model plays a

key role in the OOAD process as it describes the functions and processes,
assists with the discovery of information needs, helps in identifying
opportunities, and establishes a basis for determining product and service
costs. This model is similar to a real system, which helps the analyst
understand and predict the effect of changes on the system. In a simple term,
modelling is creating a model which represents a system, including all of its
properties.

2) Data stores: They show data collection without mentioning how the data is
stored. It represents the databases or any other medium of storage of data.

3) Data flow diagram: A data flow diagram (DFD) charts out the flow of
information for any software system. It makes use of symbols to denote the
flow of data from input to output. DFD can be a simple hand-drawn one or
maybe a detailed multi-level one that shows the complete in-depth handling of
the data. As we know, “A picture is worth a thousand words.”, so a DFD can
explain so many things that are difficult to explain in words and also, it can be
understood by top management easily who is non-technical in nature.
Below is a DFD that explains that input being fetched from the database
passes through the system and produces the desired output for the customer.

Figure 8.26: A data flow diagram

4) Synchronous vs Asynchronous data flow: Synchronous data flow is a

situation when a data flow directly connects the two processes. Both
processes must have the same speed of operation as there is no storage/buffer
between the two processes to temporarily hold the data to adjust for the speed
mismatch of the two processes. Hence, both processes are dependent on each
other directly. In case there sits a data source between the two processes, the
first process produces the data, which is stored in a data source. Later on, this
can be used by another process. This type of data flow is called asynchronous.

5) Balancing a DFD means that the data that flow into or out of a bubble must
match the data flow at the next Level of DFD.

6) Design flaws arising out of poor Diagramming approach: A poor

diagrammatic approach poses many challenges and issues in understanding a
software system. Many design flaws crop in because of this. The design flaws

24
 occur when the outputs from a process does not match its inputs. A few Modeling
examples of this design flaw are listed below: -
 Black hole: If a processing step has just input flows but no output
flows.
 Miracle: If a processing step has just output flows, but no input flows.
 Grey hole: As the name suggests that it is a confusing situation. Such
a situation may arise when a processing step has outputs greater than
the sum of its inputs - e.g., its inputs could not produce the output
shown.

☞ Check your progress -2

1) State True / False

a) False. ( External entities may appear only at level 0 of DFD.)
b) False.
c) True

2) Dynamic Model depicts the time and sequencing of the operations. We use it
to specify and implement the control aspect of the system. State diagrams are
used to show all such information.

3) Data flow diagrams can be made in several nested layers. Many different
levels in a DFD are required in order to explain the functions of the software
system in a deep and detailed manner. Level-0 DFD is a top-level data flow
diagram (also known as "A context diagram”). It only contains one process
node ("Process 0") that generalizes the function of the entire system in
relationship to external entities.
In level-1 data flow diagram, the single process node from the context
diagram is broken down into subprocesses. As these processes are added, the
diagram will need additional data flows and data stores to link them together.
In a similar way, Level-1 DFD is exploded into further detailed sub-sub-
processes to depict basic modules in the system and the flow of data among
various modules and produces Level-3 DFD.

4) DFD upto level- 1 to show the registration system to register a student

for subjects in a semester.

Registration
form

Student Registration Registrar

System

Course
Registered

Figure 8.27: Context Diagram (Level- 0) for Student Registration

System

25
Functional Modeling

Figure 8.28: Level 1 DFD for Registration of Students for

Subjects in a semester

8.10 REFERENCES / FURTHER READING

 Grady Booch, James Rumbaugh and Ivar Jacobson,“ The Unified

Modeling Language User Guide”, 2nd Edition, Addison-Wesley Object
Technology Series, 2005.
 Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J.
Young, Jim Conallen, Kelli A. Houston, “Object-Oriented Analysis and
Design with Applications,” 3rd Edition, Addison-Wesley, 2007.
 James Rumbaugh, Ivar Jacobson, and Grady Booch, “Unified Modeling
Language Reference Manual,” 2nd Edition, Addison-Wesley
Professional, 2004.
 Rajib Mall ,“Fundamentals of Software Engineering”, PHI, 2018.
 Bruce R. Maxim, and Roger S. Pressman, “Software Engineering: A
Practitioner’s Approach”, McGraw Hill Education, 8th edition,2019.
 [Link]
al_modeling.htm
 [Link]
analysis-and-design/
 [Link]
 [Link]
 [Link]
 [Link]

26