Unit :03

System Modeling
 System Modeling: System modelling is the process of developing
abstract models of a system.

Each model presents a different view or perspective of that system.

Represent the system using some kind of graphical notation (Mostlybased
on UML).

System modelling helps the analyst to understand the functionality of the

system and models are used to communicate with customers.

It also provides the developer and the customer with the means to assess
quality, once the software is built.

System modeling may represent a system using graphical notation, e.g.

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 Perspectives:
An context/external perspective :
model the context or environment of the system.
An interaction perspective :
model the interactions between a system and its environment, or between the
components of a system.
A structural perspective :
model the organization of a system or the structure of the data that is processed
by the system.
A behavioral perspective :
model the dynamic behavior of the system and how it responds to events.
UML diagram types :
Class Diagram:
Class diagrams are the most common diagrams used in UML. Class diagram
consists of classes, interfaces, associations, and collaboration. Class diagrams
basically represent the object-oriented view of a system, which is static in
nature.
Active class is used in a class diagram to represent the concurrency of the
system.
Class diagram represents the object orientation of a system. Hence, it is
generally used for development purpose. This is the most widely used diagram
at the time of system construction.
Object diagrams :
It can be described as an instance of class diagram. Thus, these diagrams are
more close to real-life scenarios where we implement a system.
Object diagrams are a set of objects and their relationship is just like class
diagrams. They also represent the static view of the system.
The usage of object diagrams is similar to class diagrams but they are used to
build prototype of a system from a practical perspective.
Use case diagrams :
A set of use cases, actors, and their relationships. They represent the use case
view of a system.
A use case represents a particular functionality of a system. Hence, use case
diagram is used to describe the relationships among the functionalities and their
internal/external controllers. These controllers are known as actors.
Sequence diagram:
is an interaction diagram. From the name, it is clear that the diagram deals with
some sequences, which are the sequence of messages flowing from one object
to another.
Interaction among the components of a system is very important from
implementation and execution perspective. Sequence diagram is used to
visualize the sequence of calls in a system to perform a specific functionality.
The UML diagrams are categorized into structural diagrams, behavioral
diagrams, and also interaction overview diagrams. The diagrams are
hierarchically classified in the following figure:
 1. Structural Diagrams:
Structural diagrams depict a static view or structure of a system. It is widely
used in the documentation of software architecture. It embraces class diagrams,
composite structure diagrams, component diagrams, deployment diagrams,
object diagrams, and package diagrams. It presents an outline for the system. It
stresses the elements to be present that are to be modeled.
o Class Diagram: Class diagrams are one of the most widely used
diagrams. It is the backbone of all the object-oriented software systems. It
depicts the static structure of the system. It displays the system's class,
attributes, and methods. It is helpful in recognizing the relation between
different objects as well as classes.
o Composite Structure Diagram: The composite structure diagrams show
parts within the class. It displays the relationship between the parts and
their configuration that ascertain the behavior of the class. It makes full
use of ports, parts, and connectors to portray the internal structure of a
 structured classifier. It is similar to class diagrams, just the fact it
represents individual parts in a detailed manner when compared with
class diagrams.
o Object Diagram: It describes the static structure of a system at a
particular point in time. It can be used to test the accuracy of class
diagrams. It represents distinct instances of classes and the relationship
between them at a time.
o Component Diagram: It portrays the organization of the physical
components within the system. It is used for modeling execution details.
It determines whether the desired functional requirements have been
considered by the planned development or not, as it depicts the structural
relationships between the elements of a software system.
o Deployment Diagram: It presents the system's software and its hardware
by telling what the existing physical components are and what software
components are running on them. It produces information about system
software. It is incorporated whenever software is used, distributed, or
deployed across multiple machines with dissimilar configurations.
o Package Diagram: It is used to illustrate how the packages and their
elements are organized. It shows the dependencies between distinct
packages. It manages UML diagrams by making it easily understandable.
It is used for organizing the class and use case diagrams.
2. Behavioral Diagrams:
Behavioral diagrams portray a dynamic view of a system or the behavior of a
system, which describes the functioning of the system. It includes use case
diagrams, state diagrams, and activity diagrams. It defines the interaction within
the system

o State Machine Diagram: It is a behavioral diagram. it portrays the

system's behavior utilizing finite state transitions. It is also known as
the State-charts diagram. It models the dynamic behavior of a class in
response to external stimuli.
o Activity Diagram: It models the flow of control from one activity to the
other. With the help of an activity diagram, we can model sequential and
concurrent activities. It visually depicts the workflow as well as what
causes an event to occur.
o Use Case Diagram: It represents the functionality of a system by
utilizing actors and use cases. It encapsulates the functional requirement
of a system and its association with actors. It portrays the use case view
of a system.
 Context Model:
A context model (or context modeling) defines how context data are
structured and maintained (It plays a key role in supporting efficient
context management).
It aims to produce a formal or semi-formal description of the context
information that is present in a context-aware system.
In other words, the context is the surrounding element for the system,
and a model provides the mathematical interface and a behavioral
description of the surrounding environment.
A key role of context model is to simplify and introduce greater structure
into the task of developing context-aware applications.
At an early stage in the specification of a system, you should decide on
the system boundaries. 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.
You may decide that automated support for some business processes
should be implemented but others should be manual processes or
supported by different systems.
You should look at possible overlaps in functionality with existing
systems and decide where new functionality should be implemented.
These decisions should be made early in the process to limit the system
costs and the time needed for understanding the system requirements and
design.
For example:
where an automated system is replacing an existing manual or
computerized system, the environment of the new system is usually the
same as the existing system’s environment. In other cases, there is more
flexibility, and you decide what constitutes the boundary between the
system and its environment during the requirements engineering process
 Figure 3.1. Context model of the online store.

 Interaction Model:
Modeling user interaction is important as it helps to identify user
requirements.
Modeling system-to-system interaction highlights the communication
problems that may arise.
Modeling component interaction helps us understand if a proposed
system structure is likely to deliver the required system performance and
dependability. Use case diagrams and sequence diagrams may be used
for interaction modeling.
All systems involve interaction of some kind. This can be user
interaction, which involves user inputs and outputs, interaction between
the system being developed and other systems or interaction between the
components of the system.
Modeling user interaction is important as it helps to identify user
requirements. Modeling system to system interaction highlights the
communication problems that may arise.
Modeling component interaction helps us understand if a proposed
system structure is likely to deliver the required system performance and
dependability.
 Sommerville covers two related (complementary) approaches to
interaction modeling:
1. Use case modeling, which is mostly used to model interactions
between a system and external actors (users or other systems).
2. Sequence diagrams, which are used to model interactions between
system components, although external agents may also be included.
o 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.
Represented diagramatically to provide an overview of the use case
and in a more detailed textual form. A Use Case Model describes the
proposed functionality of a new system.
A Use Case represents a discrete unit of interaction between a user
(human or machine) and the system.
This interaction is a single unit of meaningful work, such as Create
Account or View Account Details.
Each Use Case describes the functionality to be built in the proposed
system, which can include another Use Case's functionality or extend
another Use Case with its own behavior.
Fig 1: Use cases describing interactions to Bank and Shipping system
(external systems).
Fig 2: Use cases describing interactions to Accounting system (external
systems).
  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.
1. Class diagram :
Class diagram is a static diagram. It represents the static view of an application.
Class diagram is not only used for visualizing, describing, and documenting
different aspects of a system but also for constructing executable code of the
software application.
Class diagram describes the attributes and operations of a class and also the
constraints imposed on the system.
The class diagrams are widely used in the modeling of objectoriented systems
because they are the only UML diagrams, which can be mapped directly with
object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations,
collaborations, and constraints. It is also known as a structural diagram.
 Purpose of Class Diagrams
The purpose of class diagram is to model the static view of an
application.
Class diagrams are the only diagrams which can be directly mapped with
object-oriented languages and thus widely used at the time of
construction.
UML diagrams like activity diagram, sequence diagram can only give the
sequence flow of the application, however class diagram is a bit different.
It is the most popular UML diagram in the coder community.
The purpose of the class diagram can be summarized as –
 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.

 Class Diagram Example

A class diagram describing the sales order system is given below.
 2.Object diagram :
Object diagrams are derived from class diagrams so object diagrams are
dependent upon class diagrams.
Object diagrams represent an instance of a class diagram. The basic concepts
are similar for class diagrams and object diagrams. Object diagrams also
represent the static view of a system but this static view is a snapshot of the
system at a particular moment.
Object diagrams are used to render a set of objects and their relationships as an
instance.
Object diagrams are dependent on the class diagram as they are derived from
the class diagram. It represents an instance of a class diagram.
The objects help in portraying a static view of an object-oriented system at a
specific instant.
Both the object and class diagram are similar to some extent; the only difference
is that the class diagram provides an abstract view of a system. It helps in
visualizing a particular functionality of a system.
 Purpose of Object Diagrams
 The purpose of a diagram should be understood clearly to implement it
practically. The purposes of object diagrams are similar to class diagrams.
 The difference is that a class diagram represents an abstract model
consisting of classes and their relationships. However, an object diagram
represents an instance at a particular moment, which is concrete in nature.
 It means the object diagram is closer to the actual system behavior. The
purpose is to capture the static view of a system at a particular moment.
 It is used to perform forward and reverse engineering.
 It is used to understand object behavior and their relationships practically.
 It is used to get a static view of a system.
 It is used to represent an instance of a system.
 The purpose of the object diagram can be summarized as −
 Forward and reverse engineering.
 Object relationships of a system
 Static view of an interaction.
 Understand object behaviour and their relationship from practical
perspective

 Example of Object Diagram

 Behavioral models:
Behavioral diagrams portray a dynamic view of a system or the behavior of a
system, which describes the functioning of the system.
 It includes use case diagrams, state diagrams, and activity diagrams. It
defines the interaction within the system.
o State Machine Diagram: It is a behavioral diagram. it portrays the
system's behavior utilizing finite state transitions. It is also known as
the State-charts diagram. It models the dynamic behavior of a class in
response to external stimuli.
o Activity Diagram: It models the flow of control from one activity to the
other. With the help of an activity diagram, we can model sequential and
concurrent activities. It visually depicts the workflow as well as what
causes an event to occur.
o Use Case Diagram: It represents the functionality of a system by
utilizing actors and use cases. It encapsulates the functional requirement
of a system and its association with actors. It portrays the use case view
of a system.
Behavioral models are models of the dynamic behavior of the 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.
You can think of these stimuli as being of two types:
1. Data: Some data arrives that has to be processed by the system.
2. Events: Some event happens that triggers system processing. Events
may have associated data but this is not always the case.
 Data-driven modelling:
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.
In ither words, it shows the response of the system to particular input.
Data Driven Modeling (DDM) is a technique using which the configurator
model components are dynamically injected into the model based on the data
derived from external systems such as catalog system, Customer
Relationship Management (CRM), Watson, and so on.
The basic processes of the online store (starting from the insertion of a new
product through browsing and selecting products to buy till tracking the
order's delivery and provide feedback) is shown on the following activity
diagram.
  Event-driven modelling:
The event driven modeling is a programming technique in which system
response to external and internal events such as user actions, mouse
clicks, key pressing, message from other threads on the based of an
events the flow of the program is determined.
The event driven modeling technique is based on the thinks that the
system has a finite state and event is a reason of moving from one state to
another state. The graphical user interfaces and other applications (e.g.
java script, web application) use event driven programming techniques to
performing certain type of action in response to a user action.
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
 State machine diagrams
A state machine diagram models the behaviour of a single object, specifying
the sequence of events that an object goes through during its lifetime in
response to events. It contains the following elements:
 State. A state is denoted by a round-cornered rectangle with the
name of the state written inside it. There are two special states:
o Initial state. The initial state is denoted by a filled
black circle and may be labeled with a name.
o Final state. The final state is denoted by a circle
with a dot inside and may also be labeled with a
name.
 Transitions. Transitions from one state to the next are denoted
by lines with arrowheads. A transition may have a trigger, a
guard and an effect, as below. Trigger is the cause of the
transition, which could be a signal, an event, a change in some
condition, or the passage of time. Guard is a condition which
must be true in order for the trigger to cause the
transition. Effect is an action which will be invoked directly on
the object that owns the state machine as a result of the
transition.
 State action. State actions describe effects associated with a
state. A state action is an activity label/behavior expression
pair. The activity label identifies the circumstances under which
the behavior will be invoked. There are three reserved activity
labels:
 o entry: the behavior is performed upon entry to the
state,
o do: ongoing behavior, performed as long as the
element is in the state,
o exit: a behavior that is performed upon exit from
the state.
 Self-transition. A state can have a transition that returns to
itself. This is most useful when an effect is associated with the
transition.
 Entry point. If we do not enter the machine at the normal
initial state, we can have additional entry points.
 Exit point. In a similar manner to entry points, it is possible to
have named alternative exit points.
Fig:State machine diagram of the class ShoppingCart

A less detailed state machine diagram showing a possible set

of order statuses is shown below:
Fig :State machine Order
  Model-driven engineering:
MDA is a model-focused approach to software design and implementation
that uses a subset of UML models to describe a system.
Models at different levels of abstraction are created. From a high-level,
platform independent model, it is possible, in principle, to generate a
working program without manual intervention.
The programs that execute on a hardware/software platform are then
generated automatically from the models. Proponents of MDE argue that this
raises the level of abstraction in software engineering so that engineers no
longer have to be concerned with programming language details or the
specifics of execution platforms.
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. Model-driven engineering and model-
driven architecture are often seen as the same thing. However, I think that
MDE has a wider scope than MDA.

 Model-driven architecture:
Model-driven architecture (Kleppe, et al., 2003; Mellor et al., 2004; Stahl and
Voelter, 2006) is a model-focused approach to software design and
implementation that uses a sub-set of UML models to describe a system. Here,
models at different. Model-Driven Architecture (MDA) is a framework for
software development processes that is at the core of the Object Management
Group's (OMG) recommendations:

levels of abstraction are created. From a high-level platform independent

model it is possible, in principle, to generate a working program without
manual intervention. The MDA method recommends that three types of
abstract system model should be produced:
1.A computation independent model (CIM) that models the important
domain abstractions used in the system. CIMs are sometimes called
domain models. You may develop several different CIMs, reflecting
different views of the sys- tem. For example, there may be a security CIM
in which you identify important security abstractions such as an asset and
 a role and a patient record CIM, in which you describe abstractions such
as patients, consultations, etc.

2.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 and how
it responds to exter- nal and internal events.

3. Platform specific models (PSM) which are transformations of the

platform- independent model with a separate PSM for each application
platform. In principle, there may be layers of PSM, with each layer
adding some platform- specific detail. So, the first-level PSM could be
middleware-specific but database independent. When a specific database
has been chosen, a database- specific PSM can then be generated.
As I have said, transformations between these models may be defined
and applied automatically by software tools.

This is illustrated in above Figure, which also shows a final level of

automatic transformation.

A transformation is applied to the PSM to generate executable code

that runs on the designated software platform.

At the time of writing, automatic CIM to PIM translation is still at the

research pro- totype stage.

It is unlikely that completely automated translation tools will be

available in the near future. Human intervention, indicated by a stick
figure in above Figure, will be needed for the foreseeable future. CIMs
are related and part of the translation
 Executable UML:
The fundamental notion behind model-driven engineering is that
completely automated transformation of models to code should be
possible.
To achieve this, you have to be able to construct graphical models
whose semantics are well defined.
You also need a way of adding information to graphical models about
the ways in which the operations defined in the model are implemented.
This is possible using a subset of UML 2, called Executable UML or
xUML (Mellor and Balcer, 2002).
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. To create an executable sub-set of UML, the number
of model types has therefore been dramatically reduced to three key
model types:
 1. Domain models identify the principal concerns in the system.

These are defined using UML class diagrams that include objects,
attributes, and associations.

2. Class models, in which classes are defined, along with their attributes
and operations.
3. State models, in which a state diagram is associated with each class
and is used to describe the lifecycle of the class.

 Architectural design:
Architecture design is concerned with understanding how a system
should be organized and designing the overall structure of that system.
In agile processes, it is generally accepted that an early stage of the
development process should be concerned with establishing an overall
system architecture.
Incremental development of architectures is not usually successful. While
refactor- ing components in response to changes is usually relatively easy,
refactoring a sys- tem architecture is likely to be expensive.
1. Architecture in the small is concerned with the architecture of
individual pro- grams.
At this level, we are concerned with the way that an individual
program is decomposed into components.
2. Architecture in the large is concerned with the architecture of
complex enter- prise systems that include other systems, programs,
and program compo- nents.
These enterprise systems are distributed over different computers,
which may be owned and managed by different companies.
Software architecture is important because it affects the
performance, robustness, distributability, and maintainability of a
system (Bosch, 2000).
As Bosch discusses, individual components 41 implement the
functional system requirements.
The non- functional requirements depend on the system
architecture—the way in which these components are organized
and communicate.
In many systems, non-functional requirements are also influenced
by individual components, but there is no doubt that the
architecture of the system is the dominant influence.

 Architectural design decisions

 Architectural design is a creative process where you design a
system organization that will satisfy the functional and non-
functional requirements of a system.
Because it is a creative process, the activities within the process
depend on the type of system being developed, the background
and experience of the system architect, and the specific
requirements for the system.
It is therefore useful to think of architectural design as a series of
decisions to be made rather than a sequence of activities.
During the architectural design process, system architects have to
make a number of structural decisions that profoundly affect the
system and its development process.

 The non-functional system requirements:

1. Performance If performance is a critical requirement, the
architecture should be designed to localize critical operations
within a small number of com- ponents, with these components all
deployed on the same computer rather than distributed across the
network.
This may mean using a few relatively large com- ponents rather
than small, fine-grain components, which reduces the number of
component communications.
You may also consider run-time system organiza- tions that allow
the system to be replicated and executed on different processors.

2. Security If security is a critical requirement, a layered structure

for the architec- ture should be used, with the most critical assets
 protected in the innermost lay- ers, with a high level of security
validation applied to these layers.

3.Safety If safety is a critical requirement, the architecture should

be designed so that safety-related operations are all located in
either a single component or in a small number of components.

This reduces the costs and problems of safety val- idation and
makes it possible to provide related protection systems that can
safely shut down the system in the event of failure.

4. Availability If availability is a critical requirement, the

architecture should be designed to include redundant components
so that it is possible to replace and update components without
stopping the system.

5. Maintainability If maintainability is a critical requirement,

the system architec- ture should be designed using fine-grain, self-
contained components that may readily be changed.
Producers of data should be separated from consumers and shared
data structures should be avoided.
 Architectural views:
Used when there are multiple ways to view and interact with data. Also
used when the future requirements for interaction and presentation of data
are unknown.
Advantages Allows the data to change independently of its representation
and vice versa.
 Supports presentation of the same data in different ways with changes
made in one representation shown in all of them.
Disadvantages Can involve additional code and code complexity when
the data model and interactions are simple.

basis for model-driven development. However, I believe that informal

models and notations, such as the UML, will remain the most commonly
used ways of docu- menting system architectures.
 Architectural patterns:

The idea of patterns as a way of presenting, sharing, and reusing knowledge

about software systems is now widely used. The trigger for this was the
publication of a book on object-oriented design patterns (Gamma et al.,
1995), which prompted the development of other types of pattern, such as
patterns for organizational design (Coplien and Harrison, 2004), usability
patterns (Usability Group, 1998), interaction (Martin and Sommerville,
2004), configuration management

For example, above Figure describes the well-known Model-View-

Controller pattern.

This pattern is the basis of interaction management in many web-based

systems.

The stylized pattern description includes the pattern name, a brief description
(with an associated graphical model), and an example of the type of system
where the pattern is used (again, perhaps with a graphical model).

You should also include information about when the pattern should be used
and its advantages and disadvantages.

Graphical models of the architecture associated with the MVC pattern are
shown in following Figures.
 These present the architecture from different views— above Figure is a
conceptual view and following Figure shows a possible run-time architecture
when this pattern is used for interaction management in a web-based system.

Layered architecture

 The notions of separation and independence are

fundamental to architectural design because they
allow changes to be localized.
 The MVC pattern, shown in Figure, separates
elements of a system, allowing them to change
independently.
 For exam- ple, adding a new view or changing an
existing view can be done without any changes to the
underlying data in the model.
  The layered architecture pattern is another way of
achieving separation and independence.
 This pattern is shown in Figure.
 Here, the system functionality is organized into
separate layers, and each layer only relies on the
facilities and services offered by the layer immediately
beneath it.
 This layered approach supports the incremental
development of systems.
 As a layer is developed, some of the services provided
by that layer may be made avail- able to users.

Figure :- The layered architecture pattern

 Application architectures

Application systems are intended to meet a business or organizational need.

All busi- nesses have much in common—they need to hire people, issue
invoices, keep accounts, and so on.
Businesses operating in the same sector use common sector- specific
applications.

Therefore, as well as general business functions, all phone companies need

systems to connect calls, manage their network, issue bills to customers, etc.

Consequently, the application systems used by these businesses also have

much in common.

Application architectures encapsulate the principal characteristics of a class

of systems.

For example, in real-time systems, there might be generic archi- tectural

models of different system types, such as data collection systems or
monitoring systems.

There are many types of application system and, in some cases, they may
seem to be very different.

However, many of these superficially dissimilar applications actu- ally have

much in common, and thus can be represented by a single abstract applica-
tion architecture.

I illustrate this here by describing the following architectures of two types of

application:

1. Transaction processing applications

2. Language processing systems
1. Transaction processing applications:
Transaction processing applications are database centered
applications that process user requests for information and update
the information in a database.
These are the most common type of inter- active business systems.
 They are organized in such a way that user actions can’t interfere
with each other and the integrity of the database is maintained.

This class of system includes interactive banking systems, e-commerce systems,

information systems, and booking systems.

2. Language processing systems:

Language processing systems translate a natural or artificial
language into another representation of that language and, for
programming languages, may also execute the resulting code.
In software engineering, compilers translate an artificial program-
ming language into machine code.
Other language-processing systems may translate an XML data
description into commands to query a database or to an alternative
XML representation.
Natural language processing systems may translate one natural
language to another e.g., French to Norwegian.
Figure :- The architecture of a language processing system