Software Engineering Unit 2: System Modeling

System Modelling
 System modelling is the process of developing abstract models of a system, with each
model presenting a different view or perspective of that system.

 System modeling is like creating a blueprint or a map of a system. (Imagine you're

building a house; you need different drawings to show how the house looks from the
outside, how the rooms are arranged inside, and how the plumbing works. Similarly,
in software engineering, we create different models to represent various aspects of a
system, helping us understand and communicate how it works.)

 System modelling 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 Modelling Language (UML).

 System modelling helps the analyst to understand the functionality of the system and
models are used to communicate with customers.

 You may develop different models to represent the system from different
perspectives. For example:
1. An external perspective, where the context or environment of the system is
modelled
2. A behavioral perspective, where the behaviour of the system is modelled
3. A structural perspective, where the architecture of the system or the
structure of the data processed by the system is modelled.

Examples of the Types of System Models that you might create during the analysis process
are:
1. Activity diagrams: which show the activities involved in a process or in data
processing.
2. Use case diagrams: which show the interactions between a system and its
environment.
3. Sequence diagrams: which show interactions between actors and the system and
between system components.
4. Class diagrams: which show the object classes in the system and the associations
between these classes.
5. State diagrams: which show how the system reacts to internal and external events.

1|Page
Software Engineering Unit 2: System Modeling

1. Context Models
 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.
 Once some decisions on the boundaries of the system have been made, part of the
analysis activity is the definition of that context and the dependencies that a system
has on its environment. Normally, producing a simple architectural models the first
step in this activity.
 A context model is a simple diagram that shows how a system interacts with other
systems and the environment around it. It helps visualize which systems are
connected and share data, without getting into too much detail about how they
connect.
 Example: Mental Health Care - Patient Management System (MHC-PMS)
 Let’s take an example of a Patient information system for mental health care (called
MHC-PMS). The system handles information about patients and their treatments. In
its environment, there are several other systems it interacts with:

2|Page
Software Engineering Unit 2: System Modeling

1. Appointments System: Manages patient appointments.

2. Patient Record System: Stores general patient information, such as names and
addresses.
3. Management Reporting System: Provides reports to management about the clinic’s
operations.
4. Hospital Bed Allocation System: Tracks available beds in the hospital.
5. Statistics System: Gathers data for research purposes.
6. Prescription System: Generates prescriptions for patient medications.
What the Context Model Does Not Show:
 It doesn’t explain whether the systems send data to or receive data from each other.
It only shows that they are connected.
 Other detailed information about human processes (like how doctors or nurses use
the system) is not part of the context model, but can be shown in other models (like
business process models).
Why Use Context Models?
 Simplicity: They give a quick overview of the system and its environment, without
complex details.
 Clarity: They help everyone involved (developers, users, and stakeholders)
understand which systems are interacting with each other.
 Foundation for Other Models: Context models are usually combined with other
models that show more details, such as how people and systems interact with the
software.

3|Page
Software Engineering Unit 2: System Modeling

2. Interaction models
 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.
 There are Two approaches to interaction modeling:
1. Use case modelling, 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.

2.1. Use case modelling

Use case modeling was originally developed by Jacobson et al. (1993) in the 1990s
and was incorporated into the first release of the UML.
A Use case is a specific scenario that describes an interaction between an actor (user)
and the system to achieve a goal.
Each use case represents a discrete task that involves external interaction with a
system. In a basic form, a use case is shown as an ellipse, and the actors (users or
systems) involved are represented as stick figures.

Example Use Case: An example from the MHC-PMS is the task of uploading data to a
general patient record system, which holds summary data about patients.
Notice that there are two actors in this use case: the operator who is transferring the
data and the patient record system.
The stick figure notation was originally developed to cover human interaction but it is
also now used to represent other external systems and hardware.
Use case diagrams use lines without arrows to show interactions because arrows
indicate the direction of message flow, which isn't applicable in use cases where
messages go both ways.

4|Page
Software Engineering Unit 2: System Modeling

The informal arrows in the example indicate that the medical receptionist starts the
transaction, and data flows to the patient record system.
Use case diagrams provide a simple overview, but more detail is needed to
understand the interaction fully.

5|Page
Software Engineering Unit 2: System Modeling

2.2. Sequence diagrams

Sequence diagrams in the UML are primarily used to model the interactions between
the actors and the objects in a system and the interactions between the objects
themselves.
As the name implies, a sequence diagram shows the sequence of interactions that
take place during a particular use case or use case instance.

Sequence diagram for View patient information

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 (i.e.,
the time that object instance is involved in the computation).
The annotations on the arrows indicate the calls to the objects, their parameters, and
the return values. A box named alt is used with the conditions indicated in square
brackets.
You can read above Figure as follows:
1. The medical receptionist triggers the ViewInfo method in an instance P of the
PatientInfo object class, supplying the patient’s identifier, PID. P is a user
interface object, which is displayed as a form showing patient information.

6|Page
Software Engineering Unit 2: System Modeling

2. The instance P calls the database to return the information required,

supplying the receptionist’s identifier to allow security checking (at this stage,
we do not care where this UID comes from).
3. The database checks with an authorization system that the user is authorized
for this action.
4. If authorized, the patient information is returned and a form on the user’s
screen is filled in. If authorization fails, then an error message is returned.

3. 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.

3.1. Class diagrams

 Class diagrams are used when developing an object-oriented system model to show
the classes in a system and the associations between these classes.

 In this case, the Patient class defines a template for patients, and the Patient Record
class defines a template for patient records.

 An association is a link between the Patient class and the Patient Record class,
showing that there is a relationship between them. For example, a Patient is
associated with their Patient Record, meaning the patient has a record in the system.
 This relationship suggests that both classes may need to interact or know about each
other. For instance, the Patient class may access information from the Patient Record
class to manage and view the patient's medical history.
 In this example, the Patient class and the Patient Record class have a 1:1
relationship, meaning: that there is a 1:1 relationship between objects of these
classes.
 That is, each patient has exactly one record and each record maintains information
about exactly one patient.

7|Page
Software Engineering Unit 2: System Modeling

 This type of class diagram to show that objects of class Patient are also involved in
relationships with a number of other classes.
 Class diagrams look similar to semantic data models used in database design, which
show:

 Entities (like tables in a database).

 Attributes (data fields of an entity, like name, age, etc.).

 Relationships between entities (how they are connected).

8|Page
Software Engineering Unit 2: System Modeling

 In the UML, you show attributes and operations by extending the simple rectangle
that represents a class. This is illustrated in Figure 5.10 where:
1. The name of the object class is in the top section.
2. The class attributes are in the middle section. This must include the attribute
names and, optionally, their types.
3. The operations (called methods in Java and other OO programming languages)
associated with the object class are in the lower section of the rectangle.

3.2. Generalization
 Generalization helps us organize and simplify complex information.
 Generalization is an everyday technique that we use to manage complexity. Rather
than learn the detailed characteristics of every entity that we experience, we place
these entities in more general classes (animals, cars, houses, etc.) and learn the
characteristics of these classes.
 This allows us to infer that different members of these classes have some common
characteristics (e.g., squirrels and rats are rodents). We can make general statements
that apply to all class members (e.g., all rodents have teeth for gnawing).
 In simple, It’s a way to group related classes together based on common traits.

 In Figure 5.11. The generalization is shown as an arrowhead pointing up to the more

general class.

 This shows that general practitioners and hospital doctors can be generalized as
doctors and that there are three types of Hospital Doctor— those that have just
graduated from medical school and have to be supervised (Trainee Doctor)

 In a generalization, the attributes and operations associated with higher-level and

lower –level

9|Page
Software Engineering Unit 2: System Modeling

1. Higher-Level Classes: These classes (super classes) define common attributes

and operations.
2. Lower-Level Classes: These are subclasses that inherit attributes and
operations from their super classes.

 These lower-level classes then add more specific attributes and operations. For
example, all doctors have a name and phone number; all hospital doctors have a staff
number and a department but general practitioners don’t have these attributes as
they work independently

 in Figure 5.12, which shows part of the generalization hierarchy that I have extended
with class attributes. The operations associated with the class Doctor are intended to
register and de-register that doctor with the MHC-PMS

10 | P a g e
Software Engineering Unit 2: System Modeling

3.3 Aggregation
Objects in the real world are often composed of different parts. For example, a study
pack for a course may be composed of a book, PowerPoint slides, quizzes, and
recommendations for further reading.
In UML (Unified Modeling Language), aggregation shows how objects relate to each
other. One object (the "whole") contains other objects (the "parts"). To represent
this, we draw a line between the objects, and a diamond shape near the object that
represents the whole.
To show this, we use a diamond shape next to the class that represents the whole.
This is shown in Figure 5.13, which shows that a patient record is a composition of
Patient and an indefinite number of Consultations.

Imagine a patient record in a hospital. It is made up of a patient’s details and several

consultations. The patient record is the whole, and the consultations are the parts.
Each part can exist separately (the consultations are recorded individually), but
together they form a complete patient record. This is what aggregation represents.

11 | P a g e
Software Engineering Unit 2: System Modeling

4. Behavioral models
Behavioral models are ways to understand how a system works while it’s running.
They help us see what happens when the system reacts to things happening around
it.
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.

4.1 Data-driven modeling

Data-driven models show the sequence of actions involved in processing input data
and generating an associated output.
They are particularly useful during the analysis of requirements as they can be used
to show end-to-end processing in a system. That is, 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-driven models were amongst the first graphical software models.
In the 1970s, structured methods such as DeMarco’s Structured Analysis (DeMarco,
1978) introduced data-flow diagrams (DFDs) as a way of illustrating the processing
steps in a system
Data-flow models are useful because tracking and documenting how the data
associated with a particular process moves through the system helps analysts and
designers understand what is going on.
Data-flow diagrams are simple and intuitive and it is usually possible to explain them
to potential system users who can then participate in validating the model.
The UML does not support data-flow diagrams as they were originally proposed and
used for modeling data processing.
The reason for this is that DFDs focus on system functions and do not recognize
system objects.
For example, Figure 5.14 shows the chain of processing involved in the insulin pump
software. In this diagram, you can see the processing steps (represented as activities)
and the data flowing between these steps (represented as objects).

12 | P a g e
Software Engineering Unit 2: System Modeling

An alternative way of showing the sequence of processing in a system is to use UML

sequence diagrams.

You have seen how these can be used to model interaction but, if you draw these so
that messages are only sent from left to right, then they show the sequential data
processing in the system.
Figure 5.15 illustrates this, using a sequence model of the processing of an order and
sending it to a supplier. Sequence models highlight objects in a system, whereas
data-flow diagrams highlight the functions.

Figure 5.15 Order processing

13 | P a g e
Software Engineering Unit 2: System Modeling

4.2 Event-driven modeling

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.
For example, a system controlling a valve may move from a state ‘Valve open’ to a
state ‘Valve closed’ when an operator command (the stimulus) is received.
Event-based modeling was introduced in real-time design methods such as those
proposed by Ward and Mellor (1985) and Harel (1987, 1988).
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.
Example of control software for a very simple microwave oven to illustrate event-
driven modeling. Real microwave ovens are actually much more complex than this
system but the simplified system is easier to understand. This simple microwave has
a switch to select full or half power, a numeric keypad to input the cooking time, a
start/stop button, and an alphanumeric display.
Assumed that the sequence of actions in using the microwave is:
1. Select the power level (either half power or full power).
2. Input the cooking time using a numeric keypad.
3. Press Start and the food is cooked for the given time.

14 | P a g e
Software Engineering Unit 2: System Modeling

For safety reasons, the oven should not operate when the door is open and, on
completion of cooking, a buzzer is sounded. The oven has a very simple
alphanumeric display that is used to display various alerts and warning messages
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.
Figure 5.17, which shows a tabular description of each state and how the stimuli that
force state transitions are generated

15 | P a g e
Software Engineering Unit 2: System Modeling

4.3.1 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.
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.
MDA focuses on the design and implementation stages of software development
whereas MDE is concerned with all aspects of the software engineering process.

The main arguments for and against MDE are:

For MDE: It enables high-level design without implementation details, reducing
errors and speeding up development. Models can be reused across platforms, with
new platform support added easily.
Against MDE: Models may not always represent the best implementation choices,
and for long-lived systems, issues like requirements, security, and integration often
outweigh the benefits of platform independence.

4.3.2 Model-driven architecture

Model-driven architecture is a model-focused approach to software design and
implementation that uses a sub-set of UML models to describe a system.
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.
2. A platform independent model (PIM) that models the operation of the system
without reference to its implementation
3. Platform specific models (PSM) which are transformations of the platform
independent model with a separate PSM for each application platform.

16 | P a g e
Software Engineering Unit 2: System Modeling

Transformations between these models may be defined and applied automatically by

software tools.
Figure 5.19, 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

If a software system is intended to run on different platforms (e.g., J2EE and .NET),
then it is only necessary to maintain the PIM. The PSMs for each platform are
automatically generated. This is illustrated in Figure 5.20.
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.

17 | P a g e
Software Engineering Unit 2: System Modeling

4.3.3 Executable UML

Model-driven engineering (MDE) aims for fully automated transformations of models
into code, relying on well-defined graphical models.
UML was designed as a language for supporting and documenting software design,
not as a programming language.
Executable UML or xUML is a subset of UML designed for this purpose, focusing on
three main model types:
1. Domain Models: These use UML class diagrams to highlight the main
concerns of the system, including objects, attributes, and associations.
2. Class Models: Here, classes are defined along with their attributes and
operations, providing a structured view of the system.
3. State Models: Each class has an associated state diagram that describes its
lifecycle.
The dynamic behavior of the system may be specified declaratively using the object
constraint language (OCL) or may be expressed using UML’s action language. The
action language is like a very high-level programming language where you can refer
to objects and their attributes.

18 | P a g e
Software Engineering Unit 2: System Modeling

Assignment Questions

2 Marks Questions
1. Define System Modeling
2. List out the types of system models
3. Define Sequence and Use case model
4. Write full form of DFD, CIM, PIM, PSM, UML
5. Define Structural model
6. Define Class diagram

5 Marks Questions
1. Explain Context Model
2. Explain Class diagrams
3. Explain Generalization and Aggregation
4. Explain Model Driven Engineering
5. Explain Executable UML
6. Explain Interaction model and its types

10 Marks Questions
1. Explain in detail about Model driven Architecture
2. Explain Data driven modelling
3. Explain Event driven modelling

19 | P a g e