INF-UIT 2001 / Introduction / Slide 1 Ketil Stølen Øystein Haugen INF-UIT 2001 by Ø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-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
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
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
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.
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
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
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
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
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
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
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.
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
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.
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
