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
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.
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.
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.
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.
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.
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).
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
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
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.
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.
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.
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).
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
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.
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.
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
4.3.1 Model-Driven Engineering (MDE)
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 (MDA)
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.
Model-Driven Architecture (MDA) means the entire software is built using models — not
just code.
Instead of writing programs first, we first create detailed UML models (like class, sequence,
and state diagrams).
These models describe what the system should do, and tools automatically generate the
program code from these models.
The MDA method recommends that three types of abstract system model should be
produced:
1. Computation Independent Model (CIM): that models the important domain
abstractions used in the system (focuses on understanding the problem
domain.)
2. Platform Independent Model (PIM): that models the operation of the system
without reference to its implementation (how the system works logically,
still without linking it to a specific platform (like Java, .NET, Python).
3. Platform Specific Models (PSM): Which are transformations of the
platform independent model with a separate. (PSM for each application
platform PSM adds the technical details needed to make the model work on a
specific platform.)
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.
MDA tools can automatically convert system models (PIM) into platform-specific models or
code (PSM), but they can’t do it fully.
They only give partial support, meaning some parts are generated automatically while others
still need manual coding or adjustment by developers.
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.
Executable UML (xUML) is a version of UML that can actually run or generate code.