INF-UIT 2001
by Øystein Haugen and Ketil Stølen
Version 010831
INF-UIT 2001 / Introduction / Slide 1
Øystein Haugen
Ketil Stølen
Øystein Haugen in a nutshell
l80-81: UiO, Research assistant for Kristen Nygård
– 81 : IN 105 together with Bjørn Kirkerud
l81-84: Norwegian Computing Center, Simula-machine
l84-88: SimTech, typographical applications
l88-90: ABB Technology, SDL, prototype SDL tool, ATC
l89-97: SISU project, methodology, V&V, ITU
– 93: Engineering Real Time Systems
– 96: Integrated Methodology -> TIMe
l96-00: Rapporteur ITU for MSC
l97: Practitioners’verification of SDL systems (dr. scient.)
l97- : Ericsson, NorARC
l98- : Ifi, UiO as Part time Associate Professor
– IN-TIME (98) IN-RTIMe (99) IN-RTIMe (2000)
l99- : Participates in OMG wrt. UML 2.0
INF-UIT 2001 / Introduction / Slide 2
Øystein Haugen
Ketil Stølen
Ketil Stølen in a nutshell
lSenior scientist at SINTEF Telecom and Informatics
lProfessor II at IFI
lBackground from University of Manchester (4 years); Technical
University Munich (5 years); Institute for Energy Technology (3
years); Norwegian Defence Research Establishment (1 year)
lPhD in formal methods
lPlayed a leading role in the development of the Focus method - a
formal method providing the basic foundation for the refinement
part of INF-UIT
lHas recently published a book “Specification and Development of
Interactive Systems” on the Focus method
lIs currently technical manager for the CORAS project targeting
model-based risk analysis of security critical systems; CORAS has
a financial frame of more than 40 million NOK
INF-UIT 2001 / Introduction / Slide 3
Øystein Haugen
Ketil Stølen
Books and Curriculum
lWe will produce and refer to written material to support the
lectures
lThe slides of the lectures will be made available on the web in
Acrobat format
lThe lectures are part of the curriculum
lAncestors
– Haugen: IN-RTIMe: http://www.ifi.uio.no/intime/
– Stølen: IN-SUV: http://www.ifi.uio.no/insuv/
INF-UIT 2001 / Introduction / Slide 4
Øystein Haugen
Ketil Stølen
Goal: Uangripelige IT-Systemer
lKurset INF-UIT tar sikte på å lære studentene
– hvordan man lager programvare som er uangripelig i den betydning at
lden er lett å analysere mhp. pålitelighet
lden er lett å vedlikeholde.
lDen overordna målsetningen er å forklare
– hvordan praktisk programvareutvikling kan ha nytte av teorier om
ltilstandsmaskiner
lforfining
lformell argumentasjon
lmodularitet.
INF-UIT 2001 / Introduction / Slide 5
Øystein Haugen
Ketil Stølen
Goal: Uassailable IT-Systems
lThe course INF-UIT aims at teaching the students
– how software is made unassailable meaning that
lthe software is easily analyzed with respect to reliability and
dependability
lthe software is easily maintained
lThe overall goal is to explain
– how practical software development can benefit from theories about
lstate machines
lrefinement
lformal reasoning
lmodularity
INF-UIT 2001 / Introduction / Slide 6
Øystein Haugen
Ketil Stølen
Practical details
lhttp://www.ifi.uio.no/infuit/
lWhen?
– Friday 9.15 - 12.00
lWhere?
– Seminar Room 3B
lExam
– Credits: 3
– Form: Oral
– Grades: 1.0 - 6.0
lObligatory Exercises
– There will be one obligatory exercise that preferably should be done in
groups
– The students may be asked to explain details in their solution
– The obligatory exercise will have two or three drops
INF-UIT 2001 / Introduction / Slide 7
Øystein Haugen
Ketil Stølen
Unassailable IT-Systems
lUnassailable?
lIT?
lSystems?
INF-UIT 2001 / Introduction / Slide 8
Øystein Haugen
Ketil Stølen
Unassailable
lNot assailable : not liable to doubt, attack, or question
lWhere is this important?
– for all software?
lto some extent, but possibly less than one would like to think
– for some critical software
ltelecom
lsurveillance (of patients, of production processes)
lwithin computers themselves
lThis course is not concerned with attacks that come from hackers
towards data bases with sensitive content
– we are concerned with helping software to perform desirably even in
unexpected situations
INF-UIT 2001 / Introduction / Slide 9
Øystein Haugen
Ketil Stølen
IT?
lInformation Technology
– using computers
– with emphasis on practical systems
– with emphasis on behavior
lEngineering
–
–
–
–
Well acknowledged and asserted techniques
Creativity only when and where needed
Replication of earlier efforts
Pragmatics as well as theory
INF-UIT 2001 / Introduction / Slide 10
Øystein Haugen
Ketil Stølen
Systems?
l distributed
l concurrent
l real-time
– In synchrony with real life
– often small amounts of time for
each service e.g. Automatic Train
Control
– the actual durations may or may
not be significant
l reactive
l heterogeneous
l complex
INF-UIT 2001 / Introduction / Slide 11
Øystein Haugen
Ketil Stølen
Lecture plan - INF-UIT 2001
INF-UIT 2001 / Introduction / Slide 12
Øystein Haugen
Ketil Stølen
Focus on Languages
Hoare-logic
Hoare
CSP
Milner
CCS
FORTRAN
Jones
VDM
SIMULA
Xerox PARC
SmallTalk
SDL-88
LOTOS (ISO)
OODB
MSC (ITU)
INF-UIT 2001 / Introduction / Slide 13
Corba
OMT
(Rumbaugh)
Booch
UML (Rational / OMG)
Øystein Haugen
Sun
JAVA
Ketil Stølen
What language(s) to use?
lRequirements
–
–
–
–
–
used in practice for real engineering
expressive
visual
precise
trendy
lAlternatives
–
–
–
–
–
java (Sun)
SDL (ITU)
MSC (ITU)
UML 1.x (OMG)
UML 2.0 (?)
INF-UIT 2001 / Introduction / Slide 14
Øystein Haugen
SQL
Bell Labs
C++
Apple
MacIntosh
OOA(Yourdon)
Objectory
(Jacobsson)
ER-model
C
Microsoft
Windows
Broy/Stølen
Focus
SDL-92 (ITU)
COBOL
Algol Pascal
Ketil Stølen
Why choosing UML 2.0?
lPro
–
–
–
–
–
UML is definitely trendy wrt. modeling languages
UML is standardized by open standardization organization (OMG)
UML 2.0 will have most features of MSC and SDL
UML 2.0 will hopefully be more precise and executable than UML 1.x
UML 2.0 will be supported by multiple tools, and can be expressed
through any drawing tool like Powerpoint, Visio, Framemaker
– UML 2.0 is near future, UML 1.x is history soon
lCon
– UML 2.0 is not defined yet
– UML 2.0 is not supported by any dedicated tool, yet
INF-UIT 2001 / Introduction / Slide 15
Øystein Haugen
Ketil Stølen
UML Diagrams
lUML diagrams:
Use:
– Use case diagram
– Static structure diagrams:
lClass / object diagram
– Behavior diagrams:
lSequence diagram
lCollaboration diagram
lState diagram
lActivity diagram
– Implementation diagrams:
lComponent diagram
lDeployment diagram
INF-UIT 2001 / Introduction / Slide 16
Identifying main system functions
Domain and application modeling
Interactions between objects
(Ditto), static communication
Class behaviour (state oriented)
Ditto (action oriented)
For software structure
For hardware/software structure
Øystein Haugen
Ketil Stølen
Class Diagram
class
AtomicFragment
Gate
name : Str...
0...
actualgates
attribute
0..1
aggregation
+theConnection
0..n
InteractionUse
ident : String
generalization
ActionOccurrence
Connector
0..1
+theConnection
1
1
+start
+theMessage
1
Event
Message
+sendEvent
+sendMessage
(from State Machines) +stop
(from Messages)
)+recei veMessage
+receiveEvent
1
1
1.. n+events {order...
+theCoveredPart
0.. n
+theEventOwner
1
Lifeline
PartDecomposition
0..n
0..n
multiplicity
association
+action
role
0..n
0...
1
+initiatingAction
Action
(from C om m on Behavior)
)
+the Decompos edPart +represents
1
Part
Øystein Haugen
INF-UIT 2001 / Introduction / Slide 17
navigability
Interaction
Ketil Stølen
Sequence Diagram (UML 1.x corr. MSC-92)
User
ACSystem
Object
environment
Lifeline
1: code
2: CardOut
Message
3: OK
4: Unl ock
INF-UIT 2001 / Introduction / Slide 18
Øystein Haugen
Method
Ketil Stølen
Sequence Diagram (MSC-2000 in UML clothes)
diagram frame
decomposition
sd UserAccess
ACSystem ref
AC_UserAccess
User
ref
interaction use
EstablishAccess("IllegalPIN")
CardOut
opt
[PINok]
interaction group
“inline expression”
ref
Mesg("Please Enter")
OpenDoor
Øystein Haugen
INF-UIT 2001 / Introduction / Slide 19
Ketil Stølen
Collaboration diagram (UML 1.x)
Message
Object
User
1: Code
ACS yst em
2: CardOut
3: OK
Sequence info
4: Unlock
Environment
INF-UIT 2001 / Introduction / Slide 20
Øystein Haugen
Ketil Stølen
Collaborations in UML 2.0 clothes
collaboration definition
collaboration W
ref
interactions
Q
internal structure
x
y
*
*
interaction
sd Q
state machine
x
noGame
Timeout2
Timout1 /
notify player,
start Timer2
y
Timeout2
SignOn /
start Timer1
m1()
Scissors |
Paper |
Stone
playing
signing
Timeout1 /
notify player,
start Timer2
m2()
CancelPlay
Play /
sign player on for
a new game
StartPlay /
Inform player
to move, start Timer1
signedOn
Øystein Haugen
INF-UIT 2001 / Introduction / Slide 21
Ketil Stølen
State Machines (UML 1.x)
Start
State
noGame
trigging event
Timeout2
Timout1 /
notify player,
start Timer2
Timeout 2
SignOn /
start Timer1
Scissors |
Paper |
Stone
playing
signing
Timeout 1 /
notify player,
start Timer2
CancelPlay
Play /
sign pla yer on for
a ne w g ame
INF-UIT 2001 / Introduction / Slide 22
Transition
StartPlay /
Inform player
to move, start Timer1
signedOn
Øystein Haugen
Ketil Stølen
transition action
How important are languages?
lNot very important
– “Syntactic sugar”
lVery important
– “Understanding through describing”
INF-UIT 2001 / Introduction / Slide 23
Øystein Haugen
Ketil Stølen
Methodology
lA good language helps a lot
– but is hardly sufficient
– you need to know how to use the language also
lA good method is hard to find
–
–
–
–
–
easy to understand
easy to believe in
easy to follow
easy to modify
easy to get positive effects
–
–
–
–
easy to cheat?
easy to overlook?
easy to misuse?
hard to evaluate?
INF-UIT 2001 / Introduction / Slide 24
Øystein Haugen
Ketil Stølen
TIMe - the method from SISU (1/3)
lTIMe is a result of the SISU Projects
– Improved productivity and quality of systems development for
Norwegian companies within the real-time domain.
lSISU I (87-92):
– Engineering Real Time Systems (book)
lSISU II (93-96):
–
–
–
–
–
Methods and languages for making systems
Verification and Validation
Configuration Control
Process Quality
Integrated Methodology - Electronic Textbook
INF-UIT 2001 / Introduction / Slide 25
Øystein Haugen
Ketil Stølen
TIMe from SISU (2/3)
lParticipants:
– Alcatel, Ericsson, Siemens, Tandberg Data, Garex, Norsonic, Norapp,
Seem Audio, Stentofon, TrioVing,
– Telox, CAP Gemini, K.G. Knutsen,
– SINTEF, NR (Norwegian Computing Center), IFE
lUse on many real products like:
–
–
–
–
–
PCMCIA GSM Adapter; Ericsson
13 GB data streamer; Tandberg Storage
Weapon terminal; Siemens for Swedish defence
Multi Role Radio; Alcatel and NFT-Ericsson
Alphacom (Intercom); Stentofon
INF-UIT 2001 / Introduction / Slide 26
Øystein Haugen
Ketil Stølen
TIMe from SISU (3/3)
lGoals
– Modeling at higher level of abstraction
– Computer-aided analysis
– Some support for program generation
lCompanies reported (from SISU project evaluation report):
–
–
–
–
–
–
–
Fewer errors
Reduction in development effort
Better control over the development process
Less person dependent, more flexible staffing
Cooperation smoother
Methodology introduction: a serious business
Investment needed
INF-UIT 2001 / Introduction / Slide 27
Øystein Haugen
Ketil Stølen
Verification and Validation
lBarry Boehm, 1981:
– Verification: To establish the truth of correspondence between a
software product and its specification (from the Latin veritas, “truth”).
Are we building the product right?
– Validation: To establish the fitness or worth of a software product for its
operational mission (from the Latin valere, “to be worth”).
Are we building the right product?
lQuality
– process quality = meeting the specification
– system quality = playing the role required by the environment.
lQuality assurance
– Constructive methods that aim to generate the right results in the first place
– Corrective methods that aim to detect errors and make corrections.
INF-UIT 2001 / Introduction / Slide 28
Øystein Haugen
Ketil Stølen
Development model
Requirements
Functional
requirements
Refinement
Non-functional
requirements
verify
Developer
Risk Analysis
Design
Functional
design
needs
validate
Implementation
design
Developer
verify
validate
Implementation
hardware
validate
software
Owner
User
Øystein Haugen
INF-UIT 2001 / Introduction / Slide 29
Ketil Stølen
Distillery
abstraction
level
precision
distill
details
prove refinement
details
precision
time
INF-UIT 2001 / Introduction / Slide 30
Øystein Haugen
Ketil Stølen
Refinement
lRefine = to free (as metal, sugar, or oil) from impurities or
unwanted material
– here: to make more exact, to reduce the set of legal solutions
– in particular: to reduce the set of legal histories
lThe role of histories
– Histories model system runs
– Specifications are modelled by sets of histories
lThe need for a precise semantics
– Syntax, Semantics, Pragmatics
lThe assumption/guarantee paradigm
– The assumption describes the properties of the environment in which
the specified component is supposed to run
– The guarantee characterises the constraints that the specified
component is required to fulfill whenever the specified component is
executed in an environment that satisfies the assumption
INF-UIT 2001 / Introduction / Slide 31
Øystein Haugen
Ketil Stølen
Three main notions of refinement
lProperty refinement
– requirements engineering: requirements are added to the specification
in the order they are captured and formalized
– incremental development: requirements are designed and implemented
in a step-wise incremental manner
lInterface refinement
– type implementation: introducing more implementation-dependent data
types
– change of granularity: replacing one step of interaction by several, or
the other way around
lConditional refinement
– imposing boundedness: replacing unbounded resources by
implementable bounded resources
– change of protocol: replacing abstract communication protocols by
more implementation-oriented communication protocols
INF-UIT 2001 / Introduction / Slide 32
Øystein Haugen
Ketil Stølen
Model-based risk analysis
lRisk analysis is a systematic use of available information to
– determine how often specified events may occur
– the magnitude of their consequences
lModel-based risk analysis is the tight integration of state-of-the art
modelling methodology in the risk analysis process
lModel-based risk analysis is motivated by
– Precision improves the quality of risk analysis results
– Graphical UML-like diagrams are well-suited as a medium for
communication between stakeholders involved in a risk analysis; the
danger of throwing away time and resources on misconceptions is
reduced
– The need to formalize the assumptions on which the analysis depends;
this reduces maintenance costs by increasing the possibilities for reuse
– Provides a basis for tight integration of risk analysis in the system
development process; this may considerably reduce development costs
since undesirable solutions are weeded out at an early stage
INF-UIT 2001 / Introduction / Slide 33
Øystein Haugen
Ketil Stølen
Three risk analysis methods
lHazard and operability analysis
– A systematic study of how deviations from the design specification in a
system can arise, and whether these deviations can result in threats.
The analysis is performed using a set of guidewords and attributes.
Interactions can be used to specify attributes.
lFault tree analysis
– A fault tree analysis is a means to identify the cause of threats. A fault
tree is a logical diagram, which shows the relation between system
failure, i.e., a specific undesirable event in the system, and failures in
the components of the system.
lMarkov analysis
– Markov analysis assesses the time-dependent dynamic behaviour of
systems. It is well-suited to identify the frequency of threats (i.e., the
probability of a certain undesirable event). Markov analysis is based on
finite state machine descriptions.
INF-UIT 2001 / Introduction / Slide 34
Øystein Haugen
Ketil Stølen
Dialectic Software Development
lSoftware Development is a process of learning
– once you have totally understood the system you are building, it is done
lLearning is best achieved through conflict, not harmony
– discussions reveal problematic points
– silence hides critical errors
lBy applying different perspectives to the system to be designed
– inconsistencies may appear
– and they must be harmonized
lInconsistencies are not always errors!
–
–
–
–
difference of opinion
difference of understanding
misunderstanding each other
a result of partial knowledge
lReliable systems are those that have already met challenges
INF-UIT 2001 / Introduction / Slide 35
Øystein Haugen
Ketil Stølen