©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 1
System models
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 2
Objectives
● To explain why the context of a systemshould be modelled as part of the REprocess
● To describe behavioural modelling, datamodelling and object modelling
● To introduce some of the notations used inthe Unified Modeling Language (UML)
● To show how CASE workbenches supportsystem modelling
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 3
Topics covered
● Context models
● Behavioural models
● Data models
● Object models
● CASE workbenches
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 4
System modelling
● System modelling helps the analyst to understandthe functionality of the system and models are usedto communicate with customers.
● Different models present the system from differentperspectives• External perspective showing the system’s context or
environment;
• Behavioural perspective showing the behaviour of thesystem;
• Structural perspective showing the system or dataarchitecture.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 5
Model types
● Data processing model showing how the data isprocessed at different stages.
● Composition model showing how entities arecomposed of other entities.
● Architectural model showing principal sub-systems.
● Classification model showing how entities havecommon characteristics.
● Stimulus/response model showing the system’sreaction to events.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 6
Context models
● Context models are used to illustrate theoperational context of a system - they showwhat lies outside the system boundaries.
● Social and organisational concerns mayaffect the decision on where to positionsystem boundaries.
● Architectural models show the system and itsrelationship with other systems.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 7
The context of an ATM system
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 8
Process models
● Process models show the overall processand the processes that are supported by thesystem.
● Data flow models may be used to show theprocesses and the flow of information fromone process to another.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 9
Equipment procurement process
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 10
Behavioural models
● Behavioural models are used to describe theoverall behaviour of a system.
● 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.
● These models show different perspectives soboth of them are required to describe thesystem’s behaviour.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 11
Data-processing models
● Data flow diagrams (DFDs) may be used tomodel the system’s data processing.
● These show the processing steps as dataflows through a system.
● DFDs are an intrinsic part of many analysismethods.
● Simple and intuitive notation that customerscan understand.
● Show end-to-end processing of data.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 12
Order processing DFD
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 13
Data flow diagrams
● DFDs model the system from a functionalperspective.
● Tracking and documenting how the dataassociated with a process is helpful todevelop an overall understanding of thesystem.
● Data flow diagrams may also be used inshowing the data exchange between asystem and other systems in its environment.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 14
Insulin pump DFD
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 15
State machine models
● These model the behaviour of the system inresponse to external and internal events.
● They show the system’s responses to stimuli so areoften used for modelling real-time systems.
● State machine models show system states as nodesand events as arcs between these nodes. When anevent occurs, the system moves from one state toanother.
● Statecharts are an integral part of the UML and areused to represent state machine models.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 16
Statecharts
● Allow the decomposition of a model into sub-models (see following slide).
● A brief description of the actions is includedfollowing the ‘do’ in each state.
● Can be complemented by tables describingthe states and the stimuli.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 17
Microwave oven model
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 18
Microwave oven state description
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is s et to the user’s input value. The display shows the cooking timeselected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on. Display shows ‘Notready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows ‘Ready to cook’.
Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. Oncompletion of cooking, the buzzer is sounded for 5 s econds. Oven light is on. Displayshows ‘Cooking complete’ while buzzer is sounding.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 19
Microwave oven stimuli
Stimulus Description
Half power The user has pressed the half power button
Full power The user has pressed the full power button
Timer The user has pressed one of the timer buttons
Number The user has pressed a numeric key
Door open The oven door switch is not closed
Door closed The oven door switch is closed
Start The user has pressed the start button
Cancel The user has pressed the cancel button
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 20
Microwave oven operation
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 21
Semantic data models
● Used to describe the logical structure of dataprocessed by the system.
● An entity-relation-attribute model sets out theentities in the system, the relationships betweenthese entities and the entity attributes
● Widely used in database design. Can readily beimplemented using relational databases.
● No specific notation provided in the UML but objectsand associations can be used.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 22
Library semantic model
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 23
Data dictionaries
● Data dictionaries are lists of all of the names used inthe system models. Descriptions of the entities,relationships and attributes are also included.
● Advantages• Support name management and avoid duplication;
• Store of organisational knowledge linking analysis, designand implementation;
● Many CASE workbenches support data dictionaries.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 24
Data dictionary entries
Name Description Type Date
ArticleDetails of the published article that may be ordered bypeople using LIBSYS. Entity 30.12.2002
authorsThe names of the authors of the article who may be duea share of the fee. Attribute 30.12.2002
BuyerThe person or organisation that orders a co py of thearticle. Entity 30.12.2002
fee-payable-to
A 1:1 relationship between Article and the CopyrightAgency who should be paid the copyright fee. Relation 29.12.2002
Address(Buyer)
The address of the buyer. This is used to any paperbilling information that is required. Attribute 31.12.2002
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 25
Object models
● Object models describe the system in terms ofobject classes and their associations.
● An object class is an abstraction over a set ofobjects with common attributes and the services(operations) provided by each object.
● Various object models may be produced• Inheritance models;
• Aggregation models;
• Interaction models.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 26
Object models
● Natural ways of reflecting the real-worldentities manipulated by the system
● More abstract entities are more difficult tomodel using this approach
● Object class identification is recognised as adifficult process requiring a deepunderstanding of the application domain
● Object classes reflecting domain entities arereusable across systems
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 27
Inheritance models
● Organise the domain object classes into a hierarchy.
● Classes at the top of the hierarchy reflect thecommon features of all classes.
● Object classes inherit their attributes and servicesfrom one or more super-classes. these may then bespecialised as necessary.
● Class hierarchy design can be a difficult process ifduplication in different branches is to be avoided.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 28
Object models and the UML
● The UML is a standard representation devised bythe developers of widely used object-orientedanalysis and design methods.
● It has become an effective standard for object-oriented modelling.
● Notation• Object classes are rectangles with the name at the top,
attributes in the middle section and operations in thebottom section;
• Relationships between object classes (known asassociations) 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 29
Library class hierarchy
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 30
User class hierarchy
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 31
Multiple inheritance
● Rather than inheriting the attributes and servicesfrom a single parent class, a system which supportsmultiple inheritance allows object classes to inheritfrom several super-classes.
● This can lead to semantic conflicts whereattributes/services with the same name in differentsuper-classes have different semantics.
● Multiple inheritance makes class hierarchyreorganisation more complex.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 32
Multiple inheritance
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 33
Object aggregation
● An aggregation model shows how classesthat are collections are composed of otherclasses.
● Aggregation models are similar to the part-ofrelationship in semantic data models.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 34
Object aggregation
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 35
Object behaviour modelling
● A behavioural model shows the interactionsbetween objects to produce some particularsystem behaviour that is specified as a use-case.
● Sequence diagrams (or collaborationdiagrams) in the UML are used to modelinteraction between objects.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 36
Issue of electronic items
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 37
Structured methods
● Structured methods incorporate systemmodelling as an inherent part of the method.
● Methods define a set of models, a processfor deriving these models and rules andguidelines that should apply to the models.
● CASE tools support system modelling aspart of a structured method.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 38
Method weaknesses
● They do not model non-functional systemrequirements.
● They do not usually include informationabout whether a method is appropriate for agiven problem.
● The may produce too much documentation.
● The system models are sometimes toodetailed and difficult for users to understand.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 39
CASE workbenches
● A coherent set of tools that is designed tosupport related software process activitiessuch as analysis, design or testing.
● Analysis and design workbenches supportsystem modelling during both requirementsengineering and system design.
● These workbenches may support a specificdesign method or may provide support for acreating several different types of systemmodel.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 40
An analysis and design workbench
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 41
Analysis workbench components
● Diagram editors
● Model analysis and checking tools
● Repository and associated query language
● Data dictionary
● Report definition and generation tools
● Forms definition tools
● Import/export translators
● Code generation tools
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 42
Key points
● A model is an abstract system view.Complementary types of model providedifferent system information.
● Context models show the position of asystem in its environment with other systemsand processes.
● Data flow models may be used to model thedata processing in a system.
● State machine models model the system’sbehaviour in response to internal or externalevents
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 43
Key points
● Semantic data models describe the logicalstructure of data which is imported to orexported by the systems.
● Object models describe logical systementities, their classification and aggregation.
● Sequence models show the interactionsbetween actors and the system objects thatthey use.
● Structured methods provide a framework fordeveloping system models.