System Modelling

 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 has generally come to mean
representing the system using some kind of
graphical notation, which is now almost always
based on notations in the Unified Modeling
Language (UML).
 It is also possible to develop formal models of a
system, usually as a detailed system
specification.
Why Models
 Models help clarify what the existing system
does and can be used as a basis for discussing
its strengths and weaknesses. .
 Models of the new system are used during
requirements engineering to help explain the
proposed requirements to other system
stakeholders.
 Engineers use these models to discuss design
proposals and to document the system for
implementation.
 In a model-driven engineering process, it is
possible to generate a complete or partial
system implementation from the system model.
Perspective of different system models
 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.
Essential Diagram for System Models
 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.
Context Model
 Context model of a system, decide boundaries
of the system.
 This involves working with system stakeholders
to decide what functionality should be included
in the system and what is provided by the
system’s environment.
 The boundary between a system and its
environment is relatively clear.
 The definition of a system boundary is not a
value-free judgment.
 Social and organizational concerns may mean
that the position of a system boundary may be
determined by non-technical factors.
Interactions Model
 Interaction model involves user inputs and
outputs, interaction between the system being
developed and other systems or interaction
between the components of the system.
 It helps us understand if a proposed system
structure is likely to deliver the required system
performance and dependability.
Approaches of Use case Modeling
 Use case modeling, which is mostly used to
model interactions between a system and
external actors (users or other systems).
 Sequence diagrams, which are used to model
interactions between system components,
although external agents may also be included.
Use case Modelling
 use case modeling is widely used to support
requirements elicitation. A use case can be
taken as a simple scenario that describes what
a user expects from a system.
 Each use case represents a discrete task that
involves external interaction with a system.
 In its simplest form, a use case is shown as an
ellipse with the actors involved in the use case
represented as stick figures.
 In some cases single composite use case can
be used. However, it may be impossible
because of number of use case. In such cases,
you may develop several diagrams, each of
which shows related use cases.
Sequence Diagram
 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.
 The rectangle on the dotted lines indicates the
lifeline of the object concerned.
 The annotations on the arrows indicate the calls
to the objects, their parameters, and the return
values.
Structural Model
 Structural models display the organization of a
system in terms of the components that make
up that system and their relationships.
 It may be static models, which show the
structure of the system or dynamic models,
when it is executing.
 These are not the same things—the dynamic
organization of a system as a set of interacting
threads may be very different from a static
model of the system components.
 Architectural design is a particularly important
topic in SE and UML component, package, and
deployment diagrams may all be used when
presenting architectural models.
Class Diagram
 Class diagrams are used when developing an
object-oriented system model to show the
classes in a system and the associations
between these classes.
 An object class can be thought of as a general
definition of one kind of system object.
 An association is a link between classes that
indicates that there is a relationship between
these classes.
 Consequently, each class may have to have
some knowledge of its associated class.
 At early stages of the software engineering
process, objects represent something in the real
world, such as a patient, a prescription, a doctor.
Generalization
 It is a process of extracting common information
from two or more classes and combining them
into generalized super class. It is also known as
Is-A Relationship.
 Generalization is a technique that we use to
manage complexity.
 it is often useful to examine the classes in a
system to see if there is scope for generalization.
 In object-oriented languages, such as Java,
generalization is implemented using the class
inheritance mechanisms built into the language.
Generalization
 In a generalization, the attributes and operations
associated with higher-level classes are also
associated with the lower-level classes.
 The lower-level classes are subclasses inherit
the attributes and operations from their super
classes.
 These lower-level classes then add more
specific attributes and operations.
 Aggregation - It shows how classes that are
collection are composed of another class. It
refers to formation of a class as a result of
different other class being aggregated. Diamond
shape is used to show whole part relationship.ss
Behavioural Model
 Behavioral model show what happens or what is
supposed to happen when a system responds
to a stimulus from its environment.
Two stimuli of Behavior:
Data
Events
 Many business systems are data processing
systems that are primarily driven by data.
 They are controlled by the data input to the
system with relatively little external event
processing.
Data Driven Modelling
 Data-driven models show the sequence of
actions involved in processing input data and
generating an associated output.
 They show the entire sequence of actions that
take place from an input being processed to the
corresponding output, which is the system’s
response.
 Data-flow models are useful for tracking and
documenting associated data with a particular
process helps analysts and designers
understand what is going on.
 Data-flow diagrams are simple and intuitive to
explain them to potential system users who can
then participate in validating the model.
Data Driven Continue
 The UML does not support data-flow diagrams
as they were originally proposed and used for
modeling data processing.
 The reason is that DFDs focus on system
functions and do not recognize system objects.
 However, because data-driven systems are so
common in business, UML introduced activity
diagrams, which are similar to data-flow
diagrams.
 In this diagram, you can see the processing
steps (represented as activities) and the data
flowing between these steps (represented as
objects).
Event Driven Modelling
 Event-driven modeling shows how a system
responds to external and internal events.
 It is based on the assumption that a system has
a finite number of states and that events
(stimuli) may cause a transition from one state
to another.
 The UML supports event-based modeling using
state diagrams, State diagrams show system
states and events that cause transitions from
one state to another.
 They do not show the flow of data within the
system but may include additional information
on the computations carried out in each state.
Event Driven Modelling
 In UML state diagrams, rounded rectangles
represent system states. They may include a
brief description (following ‘do’) of the actions
taken in that state.
 The labeled arrows represent stimuli that force
a transition from one state to another. You can
indicate start and end states using filled circles,
as in activity diagrams.
 The UML notation lets you indicate the activity
that takes place in a state. In a detailed system
specification you have to provide more detail
about both the stimuli and the system states.
Model Driven Engineering
 Model-driven engineering (MDE) is an approach
to software development where models rather
than programs are the principal outputs of the
development process.
 Model-driven engineering has its roots in model-
driven architecture (MDA) which was proposed
by the Object Management Group (OMG) in
2001 as a new software development paradigm.
 Topics such as model-based requirements
engineering, software processes for model-
based development, and model based testing
are part of MDE but not, currently, part of MDA.
Why MDE
 It allows engineers to think about systems at a
high level of abstraction, without concern for the
details of their implementation.
 This reduces the likelihood of errors, speeds up
the design and implementation process, and
allows for the creation of reusable, platform-
independent application models.
 Therefore, to adapt the system to some new
platform technology, it is only necessary to write
a translator for that platform.
 When this is available, all platform-independent
models can be rapidly rehosted on the new
platform.
Why Not MDE
 MDE does not always follow that the
abstractions that are supported by the model
are the right abstractions for implementation.
 We may create informal design models but then
go on to implement the system using an off-the-
shelf, configurable package.
 Furthermore, the arguments for platform
independence are only valid for large long-
lifetime systems where the platforms become
obsolete during a system’s lifetime.
 However, for this class of systems, we know
that implementation is not the major problem—
requirements engineering, security and
dependability, integration with legacy systems.
Model Driven Architecture (MDA Abstract System)
 computation independent model (CIM) that
models the important domain abstractions used
in the system. CIMs are sometimes called
domain models.
 A platform independent model (PIM) that
models the operation of the system without
reference to its implementation. The PIM is
usually described using UML models that show
the static system structure.
 Platform specific models (PSM) which are
transformations of the platform independent
model with a separate PSM for each application
platform.
Model Driven Architecture Transformation
Model Driven Architecture Continue
 At the time of writing, automatic CIM to PIM
translation is still at the research prototype
stage.
 The translation of PIMs to PSMs is more mature
and several commercial tools are available that
provide translators from PIMs to common
platforms such as Java and J2EE.
 Although MDA-support tools include platform-
specific translators, it is often the case that
these will only offer partial support for the
translation from PIMs to PSMs.
 There is an uneasy relationship between agile
methods and model-driven architecture.
Executable UML
 The fundamental notion behind model-driven
engineering is that completely automated
transformation of models to code should be
possible.
 UML was designed as a language for
supporting and documenting software design,
not as a programming language.
 The designers of UML were not concerned with
semantic details of the language but with its
expressiveness.
 They introduced useful notions such as use
case diagrams that help with the design but
which are too informal to support execution.
Types of model to create UML Subset
 Domain models identify the principal concerns
in the system. These are defined using UML
class diagrams that include objects, attributes,
and associations.
 Class models, in which classes are defined,
along with their attributes and operations.
 State models, in which a state diagram is
associated with each class and is used to
describe the lifecycle of the class.