System models

• Context model
• Behavioral models
• Data and object models
• Structured methods
 System Modeling
• System modeling is the process of developing abstract
models of a system, with each model presenting a
different view or perspective of that system.
• System modeling mean representing a system using
some kind of graphical notation, which is now almost
always based on notations in the Unified Modeling
Language (UML).
• System modelling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers.
 System Modeling
• Models are used:-
 during the requirements engineering process
to help derive the requirements for a system
 during the design process to describe the
system to engineers implementing the system
and
 after implementation to document the
system’s structure and operation
 System Modeling
• They help clarify what the existing system does and
can be used as a basis for discussing its strengths
and weaknesses which can lead to requirements for
the new system.
• Models of the new system used during requirements
engineering help to explain the proposed
requirements to other system stakeholders
[Engineers use these models to discuss design
proposals and to document the system for
implementation]
 System Perspectives
• An external perspective, where you model the context
or environment of the system.
• An interaction perspective, where you model the
interactions between a system and its environment, or
between the components of a system.
• A structural perspective, where you model the
organization of a system or the structure of the data that
is processed by the system.
• A behavioral perspective, where you model the dynamic
behavior of the system and how it responds to events.
 UML Diagram Types
• Activity diagrams, which show the activities involved in a
process or in data processing .
• Use case diagrams, which show the interactions
between a system and its environment.
• Sequence diagrams, which show interactions between
actors and the system and between system components.
• Class diagrams, which show the object classes in the
system and the associations between these classes.
• State diagrams, which show how the system reacts to
internal and external events.
 2.1 Context Models
• Context models are used to illustrate the
operational context of a system - they show what
lies outside the system boundaries.
• Social and organizational concerns may affect the
decision on where to position system boundaries.
• Context models simply show the other systems in
the environment, not how the system being
developed is used in that environment.
Context model-ATM System
Context of MHC-PMS (Medical Health Care
Patient Management System)
 2.2 Behavioral Models
• Behavioral models are models of the dynamic behavior of a
system as it is executing.
• They show what happens or what is supposed to happen
when a system responds to a stimulus from its environment.
• Two types of stimuli:
1. Data->Some data arrives that has to be processed by the
system.
2. Event->Some event happens that triggers system
processing. Events may have associated data, although this
is not always the case.
 Behavioral Models-Data Driven
• Data-driven models show the sequence of actions
involved in processing input data and generating the
associated output.
• This is very useful during the analysis stage since
they show end-to-end processing in a system which
means that they show the entire action sequence of
how input data become output data i.e. it shows the
response of the system to particular input.
• In UML, activity and sequence diagrams can be used
to describe such data flows.
 Behavioral Models-Event Driven
• Event-driven modeling shows how a system
responds to external and internal events
(stimuli)
• It is based on the assumption that a system has
a finite number of states and that an event
(stimulus) may cause a transition from one state
to another
• The UML supports event-based modeling
using state machine diagrams
 Data Model
• Data modeling in software engineering is the
process of creating a data model for an information
system by applying certain formal techniques.
• It is used to define and analyze
data requirements needed to support the business
processes within the scope of corresponding
information systems in organizations.
• UML diagrams, ER-diagram, Data flow diagram
assists data modeling.
 Uses of data model
• To assist in understanding and use an agreed
upon semi-formal model that encompasses
the concepts of the organization and how they
relate to one another
• To manage data as a resource
• To integrate information systems
• To design databases/data warehouses (aka
data repositories)
 Object Models
• Object models describe the system in terms of object
classes and their associations.
• An object class is an abstraction over a set of objects
with common attributes and the services (operations)
provided by each object.
• An object data model provides support for objects as
the basis for modeling in a database application.
• Various Object model may be produced: 1. Inheritance
model, 2. Aggregation model, 3. Interaction model.
• Object-diagram assists object modeling.
 Object Model
• An object is an instance of a class, which is a complex
type specification that defines both the state of its
instance fields and the behavior provided by its
methods.
• Object features also include a unique object identifier
that can be used to refer to the object, as well as the
organization of data into class hierarchies that support
inheritance of state and behavior.
• Object data model encompasses the data model for
both object-oriented databases and object-relational
databases.
 Structured methods
• Structured methods were invented to support function-
oriented design
• Structured ‘methods’ are really standard notations and
embodiments of good practice.
• Following these methods and applying the guidelines can
result in a reasonable design.
• A structured method includes a design process model,
notations to represent the design, report formats, rules and
design guidelines.
• Structured methods may support some or all of the
following models of a system:-(next slide)
 Structured Methods
• An object model that shows the object classes
used in the system and their dependencies.
• A sequence model that shows how objects in
the system interact when the system is
executing.
• A state transition model that shows  system
states and the triggers for the transitions from
one state to another.
 Structured Methods
• A structural model where the system components and
their aggregations are documented.
• A data flow model where the system is modeled using
the data transformations that take place as it is
processed [frequently used in real-time and business
system design also]
• A use-case model that shows the interactions between
users and the system.
[The unification of different structured methods for object
oriented design led to the development of the UML]
UML Modeling Diagrams
 UML Diagrams
• Structure diagrams show the things in the
modeled system. In a more technical term,
they show different objects in a system. 
• Behavioral diagrams show what should
happen in a system. They describe how the
objects interact with each other to create a
functioning system.
 Use Case Modeling
• Use cases were developed originally to support
requirements elicitation and now incorporated into
the UML.
• Each use case represents a discrete task that
involves external interaction with a system.
• Actors in a use case may be people or other systems.
• Use cases can be represented using a UML use case
diagram and in a more detailed textual/tabular
format.
Simple Use Case for MHC-PMS
Use Case Description (in tabular format)
Use case title Transfer data

A receptionist may transfer data from the MHC-PMS to a general patient record
database that is maintained by a health authority. The information transferred may
Description
either be updated personal information (address, phone number, etc.) or a summary of
the patient's diagnosis and treatment.

Actor(s) Medical receptionist, patient records system (PRS)

Patient data has been collected (personal information, treatment summary);

Preconditions The receptionist must have appropriate security permissions to access the patient
information and the PRS.

Postconditions PRS has been updated

1. Receptionist selects the "Transfer data" option from the menu.

2. PRS verifies the security credentials of the receptionist.
Main success scenario
3. Data is transferred.
4. PRS has been updated.

2a. The receptionist does not have the necessary security credentials.
Extensions 2a.1. An error message is displayed.
2a.2. The receptionist backs out of the use case.
Use Case Diagram for ATM
 Sequence Diagrams
• UML sequence diagrams are used to model the
interactions between the actors and the objects within a
system.
• A sequence diagram shows the sequence of interactions
that take place during a particular use case or use case
instance.
• The objects and actors involved are listed along the top of
the diagram, with a dotted line drawn vertically from these.
• Interactions between objects are indicated by annotated
arrows.
Sequence diagram for View patient
information
Sequence Diagram for ATM System
 Structural models
• Structural models of software display the
organization of a system in terms of the components
that make up that system and their relationships.
• Structural models may be static models, which show
the structure of the system design, or dynamic
models, which show the organization of the system
when it is executing.
• You create structural models of a system when you
are discussing and designing the system architecture.
 Class Diagrams
• Class diagrams are the main building block of any object-
oriented solution.
• It shows the classes in a system, attributes, and operations
of each class and the relationship between each class.
• A class has three parts, Name at the top, attributes in the
middle and operations or methods at the bottom.
• In a large system with many related classes, classes are
grouped together to create class diagrams.
• Different relationships between classes are shown by
different types of arrows.
Class Diagram
 Component diagram
• A component diagram displays
the structural relationship of components of a
software system.
• These are mostly used when working with
complex systems with many components.
Components communicate with each other
using interfaces.
• The interfaces are linked using connectors. 
Component Diagram
 Object Diagrams
• Object Diagrams, sometimes referred to as Instance
diagrams are very similar to class diagrams.
• Like class diagrams, they also show the relationship
between objects but they use real-world examples.
• They show how a system will look like at a given time.
• There is data available in the objects so they are used
to explain complex relationships between objects.
Object Diagram
 Use case diagram
• Use case diagrams give a graphic overview of
the actors involved in a system, different
functions needed by those actors and how
these different functions interact.
• It’s a great starting point for any project
discussion because you can easily identify the
main actors involved and the main processes
of the system.
 Activity diagram
• Activity diagrams represent workflows in a
graphical way.
• They can be used to describe the business
workflow or the operational workflow of any
component in a system.
• Sometimes activity diagrams are used as an
alternative to State machine diagrams.
Activity Diagram
 State Machine Diagram

• State machine diagrams are similar to activity

diagrams, although notations and usage
change a bit.
• They are sometimes known as state diagrams
or state chart diagrams as well.
• These are very useful to describe the behavior
of objects that act differently according to the
state they are in at the moment.
State Machine Diagram
 Data Flow Diagram (DFD)
• A DFD is a way of representing a flow of data
through a process or a system (usually
an information system).
• The DFD also provides information about the
outputs and inputs of each entity and the
process itself.
• It has no control flow, there are no decision
rules and no loops.
 Data flow Diagram
• Also known as bubble chart
• DFDs may be partitioned into levels that
represent increasing information flow and
functional detail.
• Levels in DFD are numbered 0, 1, 2 or beyond.
 0-Level
• It is also known as fundamental system model, or
context diagram represents the entire software
requirement as a single bubble with input and
output data denoted by incoming and outgoing
arrows.
• Then the system is decomposed and described as a
DFD with multiple bubbles.
• Parts of the system represented by each of these
bubbles are then decomposed and documented as
more and more detailed DFDs.
0-level
 1-level
• In 1-level DFD, a context diagram is
decomposed into multiple bubbles/processes.
In this level, we highlight the main objectives
of the system and breakdown the high-level
process of 0-level DFD into subprocesses.
 2-level
• 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.
 Assignment 2
• Define system modeling. Explain different
perspective of system.
• What are different models used in system
modeling? Explain with examples of each.
• Explain different levels (0 and 1) of DFD with
example.