Software system modeling



System models – Abstract descriptions of systems
whose requirements are being analysed
Formal methods – Techniques and notations for
the unambiguous specification of software
Objectives
•
•
•
•
To explain why the context of a system should be modelled as
part of the requirements engineering process
To describe behavioural modelling, data modelling and object
modelling
To introduce some of the notations used in the Unified
Modeling Language (UML)
To introduce formal methods and formal modeling approaches
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 1
The Unified Modeling Language



Devised by the developers of object-oriented analysis and design methods
Has become an effective standard for software modelling
Has nine different notations
Use
Case
Use
Case
Sequence
Diagrams
Diagrams
Diagrams
Scenario
Scenario
Collaboration
Diagrams
Diagrams
Diagrams
Scenario
Scenario
Statechart
Diagrams
Diagrams
Diagrams
©Ian Sommerville 2000
Use
Case
Use
UseCase
Case
Diagrams
Diagrams
Diagrams
State
State
Class
Diagrams
Diagrams
Diagrams
Models
Activity
Diagrams
Software Engineering, 6th edition.
State
State
Object
Diagrams
Diagrams
Diagrams
State
State
Component
Diagrams
Diagrams
Diagrams
Component
Component
Diagrams
Deployment
Diagrams
Diagrams
Slide 2
Software modeling and models



Software modeling helps the engineer to
understand the functionality of the system
Models are used for communication among
stakeholders
Different models present the system from
different perspectives
•
•
•
•
External perspective showing the system’s context or
environment
Process models showing the system development process as
well as activities supported by the system
Behavioural perspective showing the behaviour of the system
Structural perspective showing the system or data architecture
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 3
Context model
Security
system
Branch
accounting
system
Account
database
Auto-teller
system
Branch
counter
system
Usage
database
Maintenance
system
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 4
Process (activity) model
Delivery
note
Specify
equipment
requir ed
Equipment
spec.
Validate
specification
Equipment
spec.
Supplier
database
Checked
spec.
Supplier list
Find
suppliers
Accept
delivery of
equipment
Get cost
estimates
Spec. +
supplier +
estima te
Choose
supplier
Order
notification
Order
details +
Blank order
form
Place
equipment
order
Checked and
signed order form
Delivery
note
Check
delivered
items
Installation
instructions
Install
equipment
Installation
acceptance
Accept
delivered
equipment
Equipment
details
Equipment
database
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 5
Behavioral models – Data Processing
CASE toolset data flow diagram (DFD)
Input
design
Valid
design
Design
editor
Referenced
designs
Design
database
©Ian Sommerville 2000
Checked
design
Design
cross checker
and
Design
analysis
Design
analyser
Checked
design
Code skeleton
generator
Software Engineering, 6th edition.
User
report
Report
generator
Output
code
Design
database
Slide 6
Semantic data (a.k.a. ER) models
Design
1
name
description
C-date
M-date
is-a
has-nodes
1
has-links
1
n
n
1
Node
has-links
1
name
type
2
Link
n
1
links
1
name
type
1
has-labels
has-labels
Label
n
©Ian Sommerville 2000
name
text
icon
n
Software Engineering, 6th edition.
Slide 7
Data dictionary models
Name
has-labels
Label
Link
name
(label)
name
(node)
©Ian Sommerville 2000
Description
1:N relation between entities of type
Node or Link and entities of type
Label.
Holds structured or unstructured
information about nodes or links.
Labels are represented by an icon
(which can be a transparent box) and
associated text.
A 1:1 relation between design
entities represented as nodes. Links
are typed and may be named.
Eac h label has a name which
identifies the type of label. The na me
must be unique within the set of label
types used in a design.
Eac h node has a name which must be
unique within a design. The name
may be up to 64 characters long.
Software Engineering, 6th edition.
Type
Date
Relation
5.10.1998
Entity
8.12.1998
Relation
8.12.1998
Attribute
8.12.1998
Attribute
15.11.1998
Slide 8
Object models



Object models describe the system in terms of
object classes
An object class is an abstraction over a set of
objects 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 2000
Software Engineering, 6th edition.
Slide 9
Library item
Library class hierarchy
Catalogue number
Acquisition date
Cost
Type
Status
Number of copies
Acquire ()
Catalogue ()
Dispose ()
Issue ()
Return ()
Published item
Recorded item
Title
Medium
Title
Publisher
Book
Author
Edition
Publication date
ISBN
Magazine
Year
Issue
Film
Director
Date of release
Distributor
Computer
program
Version
Platform
Object aggregation
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 11
Object interaction
Ecat:
Catalog
:Library Item
Lib1:
NetServer
:Library User
Lookup
Display
Issue
Issue licence
Accept licence
Compress
Deliver
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 12
Objectives of formal methods


To be unambiguous, consistent, complete, and provable
Requirements specification
•
•

System/Software design
•
•
•

“are we building the system right?”
proving that a realization satisfies its specification
Validation
•
•

structural specifications of component relations
behavioral specification of components
demonstrating that next level of abstraction satisfies higher level
Verification
•
•

clarify customer’s requirements
reveal ambiguity, inconsistency, incompleteness
“are we building the right system?”
testing and debugging
Documentation
•
communication among stakeholders
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 13
Why use formal methods?

Formal methods have the potential to improve both
quality and productivity in software development
•
•
•
•



to enhance early error detection
to develop safe, reliable, secure software-intensive systems
to facilitate verifiability of implementation
to enable simulation, animation, proof, execution, transformation
Formal methods are on the verge of becoming best
practice and/or required practice for developing safetycritical and mission-critical software systems
To avoid legal liability repercussions
To ensure that systems meet regulations and standards
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 14
Why not?









Emerging technology with unclear payoff
Lack of experience and evidence of success
Lack of automated support
Existing tools are user unfriendly
Ignorance of advances
High learning curve
Perfection and mathematical sophistication required
Techniques not widely applicable
Techniques not scalable
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 15
Myths of formal methods

Formal methods can guarantee that software is perfect
•

Formal methods are all about program proving
•

the opposite is often the case
Formal methods are unacceptable to users
•

many methods involve no more than set theory and logic
Formal methods increase the cost of development
•

may be useful in any system (e.g., highly reusable modules)
Formal methods require highly trained mathematicians
•

they are about modeling, communicating, demonstrating
Formal methods are only useful for safety-critical systems
•

how do you make sure the spec you build is perfect?
users will find them very helpful if properly presented
Formal methods are not used on real, large-scale software
•
they are used daily in many branches of industry
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 16
Formal specification language types

Axiomatic specifications
•

State transition specifications
•

defines operations by collections of equivalence relations
Temporal logic specifications
•

defines operations in terms of a well-defined math model
Algebraic specifications
•

defines operations in terms of states and transitions
Abstract model specifications
•

defines operations by logical assertions
defines operations in terms of order of execution and timing
Concurrent specifications
•
defines operations in terms of simultaneously occuring events
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 17
Example problem – Clock


Initially, the time is midnight, the bell is off, and the
alarm is disabled
Whenever the current time is the same as the alarm
time and the alarm is enabled, the bell starts ringing
•




this is the only condition under which the bell begins to ring
The alarm time can be set at any time
Only when the alarm is enabled can it be disabled
If the alarm is disabled while the bell is ringing, the
bell stops ringing
Resetting the clock and enabling or disabling the
alarm are considered to be done instantaneously
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 18
Axiomatic specification – VDM


INIT()
ext wr time:N, bell:{quiet, ringing}, alarm:{disabled, enabled}
pre true
post (time’ = midnight) /\ (bell’ = quiet) /\ (alarm’ = disabled)
TICK()
ext wr time:N, bell:{quiet, ringing}
rd alarm_time:N, alarm:{disabled, enabled}
pre true
post (time’ = succ(time)) /\
(if (alarm_time’ = time’) /\ (alarm’ = enabled)
then (bell’ = ringing) else (bell’ = bell))
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 19
Abstract model specifications – Z
BellStatus : {quiet,ringing}
AlarmStatus : {disabled,enabled}
Clock
time, alarm_time : N
bell : BellStatus
alarm : AlarmStatus
InitClock
Clock
(time’ = midnight) /\ (bell’ = quiet) /\
(alarm’ = disabled)
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 20
Algebraic specifications – Obj

Functionality

Relations
init:  CLOCK
tick, enable, disable: CLOCK  CLOCK
setalarm: CLOCK x TIME  CLOCK
time, alarm_time: CLOCK  TIME
bell: CLOCK  {ringing, quiet}
alarm: CLOCK  {on, off}
time(init)  midnight
time(tick(C))  time(C) + 1
time(setalarm(C,T))  time(C)
alarm_time(init)  midnight
alarm_time(tick(C))  alarm_time(C)
alarm_time(setalarm(C,T))  T
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 21
State Machine specifications

In-class exercise…
©Ian Sommerville 2000
Software Engineering, 6th edition.
Slide 22