System models

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 1

 Objectives
l To explain why the context of a system
should be modelled as part of the RE
process
l To describe behavioural modelling, data
modelling and object modelling
l To introduce some of the notations used in
the Unified Modeling Language (UML)
l To show how CASE workbenches support
system modelling

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 2

 Topics covered
l Context models
l Behavioural models
l Data models
l Object models
l CASE workbenches

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 3

 System modelling
l System modelling helps the analyst to understand
the functionality of the system and models are used
to communicate with customers.
l Different models present the system from different
perspectives
• External perspective showing the system’s context or
environment;
• Behavioural perspective showing the behaviour of the
system;
• Structural perspective showing the system or data
architecture.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 4

 Model types
l Data processing model showing how the data is
processed at different stages.
l Composition model showing how entities are
composed of other entities.
l Architectural model showing principal sub-systems.
l Classification model showing how entities have
common characteristics.
l Stimulus/response model showing the system’s
reaction to events.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 5

 Context models
l Context models are used to illustrate the
operational context of a system - they show
what lies outside the system boundaries.
l Social and organisational concerns may
affect the decision on where to position
system boundaries.
l Architectural models show the system and its
relationship with other systems.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 6

 The context of an ATM system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 7

 Process models
l Process models show the overall process
and the processes that are supported by the
system.
l Data flow models may be used to show the
processes and the flow of information from
one process to another.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 8

 Equipment procurement process

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 9

 Behavioural models
l Behavioural models are used to describe the
overall behaviour of a system.
l Two types of behavioural model are:
• Data processing models that show how data is
processed as it moves through the system;
• State machine models that show the systems
response to events.
l These models show different perspectives so
both of them are required to describe the
system’s behaviour.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 10

 Data-processing models
l Data flow diagrams (DFDs) may be used to
model the system’s data processing.
l These show the processing steps as data
flows through a system.
l DFDs are an intrinsic part of many analysis
methods.
l Simple and intuitive notation that customers
can understand.
l Show end-to-end processing of data.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 11

 Order processing DFD

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 12

 Data flow diagrams
l DFDs model the system from a functional
perspective.
l Tracking and documenting how the data
associated with a process is helpful to
develop an overall understanding of the
system.
l Data flow diagrams may also be used in
showing the data exchange between a
system and other systems in its environment.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 13

 Insulin pump DFD

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 14

 State machine models
l These model the behaviour of the system in
response to external and internal events.
l They show the system’s responses to stimuli so are
often used for modelling real-time systems.
l State machine models show system states as nodes
and events as arcs between these nodes. When an
event occurs, the system moves from one state to
another.
l Statecharts are an integral part of the UML and are
used to represent state machine models.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 15

 Statecharts
l Allow the decomposition of a model into sub-
models (see following slide).
l A brief description of the actions is included
following the ‘do’ in each state.
l Can be complemented by tables describing
the states and the stimuli.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 16

 Microwave oven model

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 17

 Microwave oven state description

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 18

 Microwave oven stimuli

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 19

 Microwave oven operation

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 20

 Semantic data models
l Used to describe the logical structure of data
processed by the system.
l An entity-relation-attribute model sets out the
entities in the system, the relationships between
these entities and the entity attributes
l Widely used in database design. Can readily be
implemented using relational databases.
l No specific notation provided in the UML but objects
and associations can be used.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 21

 Library semantic model

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 22

 Data dictionaries
l Data dictionaries are lists of all of the names used in
the system models. Descriptions of the entities,
relationships and attributes are also included.
l Advantages
• Support name management and avoid duplication;
• Store of organisational knowledge linking analysis, design
and implementation;
l Many CASE workbenches support data dictionaries.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 23

 Data dictionary entries

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 24

 Object models
l Object models describe the system in terms of
object classes and their associations.
l An object class is an abstraction over a set of
objects with common attributes and the services
(operations) provided by each object.
l Various object models may be produced
• Inheritance models;
• Aggregation models;
• Interaction models.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 25

 Object models
l Natural ways of reflecting the real-world
entities manipulated by the system
l More abstract entities are more difficult to
model using this approach
l Object class identification is recognised as a
difficult process requiring a deep
understanding of the application domain
l Object classes reflecting domain entities are
reusable across systems

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 26

 Inheritance models
l Organise the domain object classes into a hierarchy.
l Classes at the top of the hierarchy reflect the
common features of all classes.
l Object classes inherit their attributes and services
from one or more super-classes. these may then be
specialised as necessary.
l Class hierarchy design can be a difficult process if
duplication in different branches is to be avoided.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 27

 Object models and the UML
l The UML is a standard representation devised by
the developers of widely used object-oriented
analysis and design methods.
l It has become an effective standard for object-
oriented modelling.
l Notation
• Object classes are rectangles with the name at the top,
attributes in the middle section and operations in the
bottom section;
• Relationships between object classes (known as
associations) are shown as lines linking objects;
• Inheritance is referred to as generalisation and is shown
‘upwards’ rather than ‘downwards’ in a hierarchy.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 28

 Library class hierarchy

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 29

 User class hierarchy

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 30

 Multiple inheritance
l Rather than inheriting the attributes and services
from a single parent class, a system which supports
multiple inheritance allows object classes to inherit
from several super-classes.
l This can lead to semantic conflicts where
attributes/services with the same name in different
super-classes have different semantics.
l Multiple inheritance makes class hierarchy
reorganisation more complex.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 31

 Multiple inheritance

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 32

 Object aggregation
l An aggregation model shows how classes
that are collections are composed of other
classes.
l Aggregation models are similar to the part-of
relationship in semantic data models.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 33

 Object aggregation

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 34

 Object behaviour modelling
l A behavioural model shows the interactions
between objects to produce some particular
system behaviour that is specified as a use-
case.
l Sequence diagrams (or collaboration
diagrams) in the UML are used to model
interaction between objects.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 35

 Issue of electronic items

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 36

 Structured methods
l Structured methods incorporate system
modelling as an inherent part of the method.
l Methods define a set of models, a process
for deriving these models and rules and
guidelines that should apply to the models.
l CASE tools support system modelling as
part of a structured method.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 37

 Method weaknesses
l They do not model non-functional system
requirements.
l They do not usually include information
about whether a method is appropriate for a
given problem.
l The may produce too much documentation.
l The system models are sometimes too
detailed and difficult for users to understand.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 38

 CASE workbenches
l A coherent set of tools that is designed to
support related software process activities
such as analysis, design or testing.
l Analysis and design workbenches support
system modelling during both requirements
engineering and system design.
l These workbenches may support a specific
design method or may provide support for a
creating several different types of system
model.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 39

An analysis and design workbench

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 40

 Analysis workbench components
l Diagram editors
l Model analysis and checking tools
l Repository and associated query language
l Data dictionary
l Report definition and generation tools
l Forms definition tools
l Import/export translators
l Code generation tools

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 41

 Key points
l A model is an abstract system view.
Complementary types of model provide
different system information.
l Context models show the position of a
system in its environment with other systems
and processes.
l Data flow models may be used to model the
data processing in a system.
l State machine models model the system’s
behaviour in response to internal or external
events
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 42
 Key points
l Semantic data models describe the logical
structure of data which is imported to or
exported by the systems.
l Object models describe logical system
entities, their classification and aggregation.
l Sequence models show the interactions
between actors and the system objects that
they use.
l Structured methods provide a framework for
developing system models.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 43