UNIT -II

CHAPTER 3
SYSTEM MODELS
 SYSTEM MODELS

• 1.Context models
• 2. Behavioural models
• 3.Data models
• 4.Object models
• 5.Structured model
 SYSTEM MODELS

• System modeling is the process of developing

abstract models of a system, with each model
presenting a different view or perspective of
that system.
• most models use some kind of graphical
notation representing a system, which is now
almost always based on notations in the Unified
Modeling Language (UML)
 SYSTEM MODELS
• Model-driven analysis is a problem-solving approach to
understanding the functionality of the system and models
are used to communicate with customers graphical system
models to document and validate both existing and/or
proposed system.
• Benefits of System Modeling
• Ease project management tasks.
• Can provide complete views of a system, as well as
detailed views of subsystems.
• Clarify structures and relationships.
• Offer a communication framework for ideas within and
between teams.
 Types of ModelS
• Different models may represent a system from
different perspectives. For example:
• An external perspective model representing the
context or environment of the system
• An interaction perspective Model where the
interactions between a system and its environment or
between the components of a system is represented.
• A structural perspective model showing the
organization of a system or the structure of the data
that is processed by the system.
• A behavioral perspective, where the model shows the
dynamic behavior of the system and how it responds
to events.
 Types of ModelS

• 1.Context models
• 2. Behavioural models
• 3.Data models
• 4.Object models
• 5.Structured model
 Context Models

• A context model is a model that shows how a

system fit into the context of the environment.
• Shows the scope and boundaries of a system at
a glance including the other systems that
interface with it
• No technical knowledge is assumed or required
to understand the diagram
 Context Models
• Easy to draw and amend due to its limited
notation
• Easy to expand by adding related systems
• Can benefit a wide audience including
stakeholders, business analyst, data analysts,
developers
• Context models provide an overview
(abstraction) of an entire system, and shows the
most important aspects.
• Details are not included.
 Context Models
 Context models are most useful in the
requirements analysis and design stages.
• A context model is a model that shows how a
system fit into the context of the environment.
• The context is the environment in which the
object of our interest exists.
• Context models capture how the central
object interacts with its environment, be it
exchanging data, physical objects, or funds.
 Context Models
• a simple context model of a catering company
 Context Models
• These models can be used to confirm project
scope, identify potential impacts of changes, and
start requirements discovery.
• The key elements are:
• Boxes: external entities that the main entity
interacts with (organizations, departments,
systems, or processes)
• Connectors: interactions between entities
• Flows: interactions are labelled to show the flow
of data, physical objects, or funds between the
entities.
 Context Models
• Simple and powerful. This basic diagram can help
discover gaps, missed impacts, interactions and
requirements early in the project.
• And early is the best time, so that the scope of the
project can be defined more accurately and
realistically, and so that the analysis does not miss
any important interactions
3.2 BEHAVIORAL
MODELS
 3.2Behavioral Model
• behavioral model describe the overall behavior of
the system.
• There are two types of behavioral models that are
used to describe the system behavior.
• Data processing model (DFD)
• State machine models(State Transition Diagram.)
• Data processing models are also known as DFD
(Data Flow Diagram) which is used to show how
data is processed as it moves through the system
• State machine model is also known as State
diagram which is used to show how the system
will react with external events.
 Data Flow Diagram

• Data flow diagram is used to model the system’s data

processing.
• It is also the Functional model as it is a graphical
representation of an enterprise function within a
defined scope. Data flow diagram shows end to end
data processing.
• It can be easily converted into software as they just
represent flow of the data objects. DFD diagram
enable Software engineer to develop a model of the
information domain and Functional domain at the
same time.
• It provide a logical model of the system and show the
flow of the data and the flow of logic involved.
 Characteristics of Data Flow Diagram

• It shows the process, that transforms incoming

data flows into outgoing data flows.
• Process that performs this transformation
normally creates as well as uses data.
• External entities send and receive data flow
from the systems.
• It is also called a bubble chart.
• Data flow diagram support a top-down
approach for analysis.
 Data Flow Diagram Notation

• Data flow diagram consists of a series of symbols

joined together by a line.
• Data objects are represented by circles which are
also called bubble charts.
• Data flow diagram are represented in hierarchical
order. The first level data flow model is also called
as DFD 0 level or context diagram which
represents the system as a whole.
• Second level data flow model refines the context
diagram and provides more details of first-level
DFD. In a similar way, third level DFD refines the
second level DFD
 Notations of data flow diagram
• Circle: A circle (bubble) shows a process that
transforms data inputs into data outputs.
• Data Flow: A curved line shows the flow of data into or
out of a process or data store.
• Data Store: A set of parallel lines shows a place for the
collection of data items. A data store indicates that the
data is stored which can be used at a later stage or by
the other processes in a different order. The data store
can have an element or group of elements.
• Source or Sink: Source or Sink is an external entity and
acts as a source of system inputs or sink of system
outputs.
DFD Level 0
DFD Level 1
 2-Level DFD
2-level DFD goes one process deeper into parts of 1-level DFD. It
can be used to project or record the specific/necessary detail
about the system's functioning.
2-Level DFD
 State Transition Diagram
• It is a collection of states and events.
• It usually describes overall states that a system
can have and events which are responsible for
a change in state of a system.
• Example :
Consider an Elevator. This elevator is for n
number of floors and has n number of buttons
one for each floor
 State Transition Diagram
• Elevator buttons are type of set of buttons
which is there on elevator.
• For reaching a particular floor you want to
visit, “elevator buttons” for that particular
floor is pressed.
• Pressing, will cause illumination and elevator
will start moving towards that particular floor
for which you pressed “elevator buttons”.
• As soon as elevator reaches that particular
floor,
illumination gets canceled.
 State Transition Diagram

• Floor buttons are another type of set of buttons

on elevator.
• If a person is on a particular floor and he wants
to go on another floor, then elevator button for
that floor is pressed.
• Then, process will be same as given above.
Pressing, will cause illumination and elevator to
start moving, and when it reaches on desired
floor, illumination gets canceled.
• When there is no request for elevator, it remains
closed on current floor.
 Advantages
• Behavior and working of a system can easily be
understood without any effort.
• Results are more accurate by using this model.
• This model requires less cost for development as
cost of resources can be minimal.
Disadvantages
• This model does not have any theory, so trainee is
not able to fully understand basic principle and
major concept of modeling.
• This modeling cannot be fully automated.
• Sometimes, it’s not easy to understand overall
result.
 3.3 DATA MODELING
• Data modeling is the process of documenting a
complex software system design as an easily
understood diagram, using text and symbols to
represent the way data needs to flow.
• The diagram can be used as a blueprint for the
construction of new software or for re-engineering
a legacy application
• The most widely used data Model by the Software
engineers is Entity- Relationship Diagram (ERD), it
addresses the issues and represents all data
objects that are entered, stored, transformed, and
produced within an application.
 DATA MODELING
• Data Objects
• Data Attributes
• Relationships
• Data Objects
• A data object is a representation of composite
information that must be understood by
software.
• A data object can be an external entity (e.g.,
anything that produces or consumes
information),
 DATA MODELING
• a thing (e.g., a report or a display)
• an occurrence (e.g., a telephone call)
• event (e.g., an alarm)
• a role (e.g., salesperson)
• an organizational unit (e.g., accounting
department)
• a place (e.g., a warehouse)
• a structure (e.g., a file).
 DATA MODELING

• For example
• a person or a car can be viewed as a data object
in the sense that either can be defined in terms
of a set of attributes. The description of the data
object incorporates the data object and all of its
attributes.
• the data object can be represented as a table as
shown in following table. The headings in the
table reflect attributes of the object.
DATA MODELING
 DATA MODELING
• Data Attributes
• Data attributes define the properties of a data
object and take on one of three different
characteristics.
• They can be used to
• (1) name an instance of the data object,
• (2) describe the instance
• (3) make reference to another instance in
another table.
 DATA MODELING
• Relationships
• Data objects are connected to one another in
different ways. Consider the two data objects,
person and car.
• These objects can be represented using the
following simple notation and relationships are
• 1) A person owns a car,
• 2) A person is insured to drive a car