INF-UIT 2001 by Øystein Haugen and Ketil Stølenfolk.uio.no/infuit/infuit-intro-010831.pdf · by...
Transcript of INF-UIT 2001 by Øystein Haugen and Ketil Stølenfolk.uio.no/infuit/infuit-intro-010831.pdf · by...
INF-UIT 2001 / Introduction / Slide 1 Ketil StølenØystein Haugen
INF-UIT 2001by Øystein Haugen and Ketil Stølen
Version 010831
INF-UIT 2001 / Introduction / Slide 2 Ketil StølenØystein Haugen
Ø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-machinel84-88: SimTech, typographical applicationsl88-90: ABB Technology, SDL, prototype SDL tool, ATCl89-97: SISU project, methodology, V&V, ITU
– 93: Engineering Real Time Systems– 96: Integrated Methodology -> TIMe
l96-00: Rapporteur ITU for MSCl97: Practitioners’ verification of SDL systems (dr. scient.)l97- : Ericsson, NorARCl98- : 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 3 Ketil StølenØystein Haugen
Ketil Stølen in a nutshell
lSenior scientist at SINTEF Telecom and InformaticslProfessor II at IFIlBackground from University of Manchester (4 years); Technical
University Munich (5 years); Institute for Energy Technology (3years); Norwegian Defence Research Establishment (1 year)lPhD in formal methodslPlayed a leading role in the development of the Focus method - a
formal method providing the basic foundation for the refinementpart of INF-UITlHas recently published a book “Specification and Development of
Interactive Systems” on the Focus methodlIs currently technical manager for the CORAS project targeting
model-based risk analysis of security critical systems; CORAS hasa financial frame of more than 40 million NOK
INF-UIT 2001 / Introduction / Slide 4 Ketil StølenØystein Haugen
Books and Curriculum
lWe will produce and refer to written material to support thelectures
lThe slides of the lectures will be made available on the web inAcrobat 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 5 Ketil StølenØystein Haugen
Goal: Uangripelige IT-Systemer
lKurset INF-UIT tar sikte på å lære studentene– hvordan man lager programvare som er uangripelig i den betydning atlden er lett å analysere mhp. pålitelighetlden er lett å vedlikeholde.
lDen overordna målsetningen er å forklare– hvordan praktisk programvareutvikling kan ha nytte av teorier omltilstandsmaskinerlforfininglformell argumentasjonlmodularitet.
INF-UIT 2001 / Introduction / Slide 6 Ketil StølenØystein Haugen
Goal: Uassailable IT-Systems
lThe course INF-UIT aims at teaching the students– how software is made unassailable meaning thatlthe software is easily analyzed with respect to reliability and
dependabilitylthe software is easily maintained
lThe overall goal is to explain– how practical software development can benefit from theories aboutlstate machineslrefinementlformal reasoninglmodularity
INF-UIT 2001 / Introduction / Slide 7 Ketil StølenØystein Haugen
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 8 Ketil StølenØystein Haugen
Unassailable IT-Systems
lUnassailable?lIT?lSystems?
INF-UIT 2001 / Introduction / Slide 9 Ketil StølenØystein Haugen
Unassailable
lNot assailable : not liable to doubt, attack, or questionlWhere is this important?
– for all software?lto some extent, but possibly less than one would like to think
– for some critical softwareltelecomlsurveillance (of patients, of production processes)lwithin computers themselves
lThis course is not concerned with attacks that come from hackerstowards data bases with sensitive content
– we are concerned with helping software to perform desirably even inunexpected situations
INF-UIT 2001 / Introduction / Slide 10 Ketil StølenØystein Haugen
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 11 Ketil StølenØystein Haugen
Systems?
l distributedl concurrentl real-time
– In synchrony with real life– often small amounts of time for
each service e.g. Automatic TrainControl
– the actual durations may or maynot be significant
l reactivel heterogeneousl complex
INF-UIT 2001 / Introduction / Slide 12 Ketil StølenØystein Haugen
Lecture plan - INF-UIT 2001
INF-UIT 2001 / Introduction / Slide 13 Ketil StølenØystein Haugen
FORTRANAlgol Pascal
CSIMULA
Xerox PARCSmallTalk
AppleMacIntosh
OOA(Yourdon)
Objectory(Jacobsson) Booch
OMT (Rumbaugh)
UML (Rational / OMG)MSC (ITU)
SDL-88
MicrosoftWindows
Hoare-logic
CSPHoare Jones
VDMMilnerCCS
LOTOS (ISO)
COBOL
SQL
ER-model
SDL-92 (ITU)
Bell LabsC++
Sun
OODB
JAVA
Focus on Languages
Broy/StølenFocus
Corba
INF-UIT 2001 / Introduction / Slide 14 Ketil StølenØystein Haugen
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 15 Ketil StølenØystein Haugen
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 16 Ketil StølenØystein Haugen
Use:Identifying main system functions
Domain and application modeling
Interactions between objects(Ditto), static communicationClass behaviour (state oriented)Ditto (action oriented)
For software structureFor hardware/software structure
UML Diagrams
lUML diagrams:– Use case diagram– Static structure diagrams:lClass / object diagram
– Behavior diagrams:lSequence diagramlCollaboration diagramlState diagramlActivity diagram
– Implementation diagrams:lComponent diagramlDeployment diagram
INF-UIT 2001 / Introduction / Slide 17 Ketil StølenØystein Haugen
Class Diagram
PartDecomposition
Part Interaction
Action(from C om m on Behavior))
InteractionUseident : String
Gatename : Str...
ActionOccurrence
AtomicFragment
Lifeline
Event(from State Machines)
0...0...
+theDecompos edPart +represents1
+action
1
0...0...actualgates
0..n
1
0..n
0..10..1
0..n0..n
1
0..n
0..n
+theCoveredPart0..n
0..n
+theEventOwner1
+start11
+stop11
11
+events1.. n {order...
1
1.. n
Message(from Messages))
+initiatingAction
1
+sendMessage +sendEvent1
1+recei veMessage +receiveEvent
1
Connector0..n
+theConnection0..n
0..1+theConnection
0..1
+theMessage
class
attribute
role
multiplicitygeneralization
aggregation
navigability
association
INF-UIT 2001 / Introduction / Slide 18 Ketil StølenØystein Haugen
User ACSystem environment
1: code
3: OK
2: CardOut
4: Unl ock
Sequence Diagram (UML 1.x corr. MSC-92)
Lifeline
Object
Message
Method
INF-UIT 2001 / Introduction / Slide 19 Ketil StølenØystein Haugen
Sequence Diagram (MSC-2000 in UML clothes)
sd UserAccess
User ACSystem refAC_UserAccess
EstablishAccess("IllegalPIN")ref
CardOut
opt[PINok] Mesg("Please Enter")
OpenDoorref
diagram frame
interaction use
interaction group“inline expression”
decomposition
INF-UIT 2001 / Introduction / Slide 20 Ketil StølenØystein Haugen
Collaboration diagram (UML 1.x)
User
ACSyst em
Environment
1: Code
2: CardOut3: OK
4: Unlock
Object
Message
Sequence info
INF-UIT 2001 / Introduction / Slide 21 Ketil StølenØystein Haugen
Collaborations in UML 2.0 clothes
collaboration W
Qref
x y* *
collaboration definition
interactions
internal structure
interactionsd Q
x y
m1()
m2()
state machine
noGame
signing
signedOn
playing
Timout1 / notify player, start Timer2
Timeout1 / notify player, start Timer2
StartPlay / Inform player
to move, start Timer1
CancelPlay
SignOn / start Timer1
Timeout2
Scissors | Paper |
Stone
Timeout2
Play / sign player on for
a new game
INF-UIT 2001 / Introduction / Slide 22 Ketil StølenØystein Haugen
State Machines (UML 1.x)
noGame
signing
signedOn
playing
Timout1 / notify player, start Timer2
Timeout 1 / notify player, start Timer2
StartPlay / Inform player
to move, start Timer1
CancelPlay
SignOn / start Timer1
Timeout 2
Scissors | Paper |
Stone
Timeout2
Play / sign pla yer on for
a new game
StateTransition
trigging event
transition action
Start
INF-UIT 2001 / Introduction / Slide 23 Ketil StølenØystein Haugen
How important are languages?
lNot very important– “Syntactic sugar”
lVery important– “Understanding through describing”
INF-UIT 2001 / Introduction / Slide 24 Ketil StølenØystein Haugen
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 25 Ketil StølenØystein Haugen
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 26 Ketil StølenØystein Haugen
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 27 Ketil StølenØystein Haugen
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 28 Ketil StølenØystein Haugen
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 itsoperational 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 29 Ketil StølenØystein Haugen
Development model
Owner User
Non-functional requirements
Functional requirements
Requirements
Developer
Developer
validate
validate
validate
verify
Functional design
Implementation design
Design
hardware
software
Implementation
verify
needs
Refinement
Risk Analysis
INF-UIT 2001 / Introduction / Slide 30 Ketil StølenØystein Haugen
Distillery
abstractionlevel
time
precision
details details
precision
distill prove refinement
INF-UIT 2001 / Introduction / Slide 31 Ketil StølenØystein Haugen
Refinement
lRefine = to free (as metal, sugar, or oil) from impurities orunwanted 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 isexecuted in an environment that satisfies the assumption
INF-UIT 2001 / Introduction / Slide 32 Ketil StølenØystein Haugen
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 33 Ketil StølenØystein Haugen
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 artmodelling methodology in the risk analysis processlModel-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; thedanger of throwing away time and resources on misconceptions isreduced
– 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 systemdevelopment process; this may considerably reduce development costssince undesirable solutions are weeded out at an early stage
INF-UIT 2001 / Introduction / Slide 34 Ketil StølenØystein Haugen
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 systemfailure, i.e., a specific undesirable event in the system, and failures inthe 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., theprobability of a certain undesirable event). Markov analysis is based onfinite state machine descriptions.
INF-UIT 2001 / Introduction / Slide 35 Ketil StølenØystein Haugen
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