Luca Viganò: Dipartimento Di Informatica Università Di Verona

Introduction
Luca Vigan
Dipartimento di Informatica Universit di Verona
Ingegneria del SW, 02.03.11
Luca Vigan (Universit di Verona)
Introduction
1 / 36
About myself: Research (and teaching)

Deduction systems and combination of logics OFMC Protocol Analysis Tool (and other works)
Theoretical research Formal Methods: Techniques and tools based on mathematics and logic that support the specication, construction and analysis of hardware and software systems. and its application to practical problems in the small, e.g. security protocols, in the large, e.g. distributed security architectures.
Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 2 / 36
Analysis of
" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " "
distributed security architectures
SW architectures / SW engineering
From specication to real bridge
Introduction
3 / 36
Selected denitions from Merriam-Webster Online

Specication:
1
A detailed precise presentation of something or of a plan or proposal for something. A statement of legal particulars (as of charges or of contract terms). A written description of an invention for which a patent is sought. The art or science of building; specically: the art or practice of designing and building structures and especially habitable ones. The manner in which the components of a computer or computer system are organized and integrated. The application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people. The design and manufacture of complex products [software engineering]. Calculated manipulation or direction (as of behavior) [social engineering].
Introduction Ingegneria del SW, 02.03.11 4 / 36
Architecture:
1
Engineering:
1
Today an overview
Why bother with software engineering? What is software engineering? Structuring and abstraction in modeling.
Introduction
5 / 36
Why bother with software engineering?

There are too many system failures! Some humorous: Restaurant orders on-line, computer crash overcooks steaks.1
1 2 3
ACM SIGSOFT, Software Engineering Notes 12(2), 1987 ACM SIGSOFT, Software Engineering Notes 13(3), 1988 ACM SIGSOFT, Software Engineering Notes 11(5), 1986 Introduction Ingegneria del SW, 02.03.11 6 / 36

There are too many system failures! Some humorous: Restaurant orders on-line, computer crash overcooks steaks.1 A Budd Company assembly robot has apparently committed suicide. The robot was programmed to apply a complex bead of uid adhesive, but the robot ignored the glue, picked up a stful of highly-active solvent, and shot itself in its electronics-packed chest.2
1 2 3
ACM SIGSOFT, Software Engineering Notes 12(2), 1987 ACM SIGSOFT, Software Engineering Notes 13(3), 1988 ACM SIGSOFT, Software Engineering Notes 11(5), 1986 Introduction Ingegneria del SW, 02.03.11 6 / 36

There are too many system failures! Some humorous: Restaurant orders on-line, computer crash overcooks steaks.1 A Budd Company assembly robot has apparently committed suicide. The robot was programmed to apply a complex bead of uid adhesive, but the robot ignored the glue, picked up a stful of highly-active solvent, and shot itself in its electronics-packed chest.2 One of the rst things the Air Force test pilots tried on an early F-16 was to tell the computer to raise the landing while still standing on the runway. Guess what happened? Scratch one F-16.3
1 2 3 ACM SIGSOFT, Software Engineering Notes 12(2), 1987 ACM SIGSOFT, Software Engineering Notes 13(3), 1988 ACM SIGSOFT, Software Engineering Notes 11(5), 1986 Introduction Ingegneria del SW, 02.03.11 6 / 36
Why bother with software engineering? (cont.)

Others are frustrating and expensive:
A Norwegian Bank was embarrassed ... after a cash-point computer applied its own form of fuzzy logic and handed out thousands of pounds no one had asked for. A long queue formed at the Oslo cash-point after news spread that customers were receiving 10 times what they requested.4
4 5 6
ACM SIGSOFT, Software Engineering Notes 15(3), 1990 INSIDE RISKS, Communications of the ACM 40, 12, Dec 1997 RISKS, 1998. Introduction Ingegneria del SW, 02.03.11 7 / 36

A Norwegian Bank was embarrassed ... after a cash-point computer applied its own form of fuzzy logic and handed out thousands of pounds no one had asked for. A long queue formed at the Oslo cash-point after news spread that customers were receiving 10 times what they requested.4 In early 1997, after many years, $4 billion spent, extensive criticism from the General Accounting Ofce [...] the IRS abandoned its tax systems modernization effort. The FBI abandoned development of a $500-million new ngerprint-on-demand computer system. The State of California spent $1 billion on a nonfunctional welfare database system. The Assembly Information Technology Committee was considering scrapping Californias Automated Child Support System, which had already overrun its $100 million budget by more than 200%.5
4 5 6
ACM SIGSOFT, Software Engineering Notes 15(3), 1990 INSIDE RISKS, Communications of the ACM 40, 12, Dec 1997 RISKS, 1998. Introduction Ingegneria del SW, 02.03.11 7 / 36

A Norwegian Bank was embarrassed ... after a cash-point computer applied its own form of fuzzy logic and handed out thousands of pounds no one had asked for. A long queue formed at the Oslo cash-point after news spread that customers were receiving 10 times what they requested.4 In early 1997, after many years, $4 billion spent, extensive criticism from the General Accounting Ofce [...] the IRS abandoned its tax systems modernization effort. The FBI abandoned development of a $500-million new ngerprint-on-demand computer system. The State of California spent $1 billion on a nonfunctional welfare database system. The Assembly Information Technology Committee was considering scrapping Californias Automated Child Support System, which had already overrun its $100 million budget by more than 200%.5 Costs of the year 2000 problem estimated to be over $600 billion worldwide.6
4 5 6 ACM SIGSOFT, Software Engineering Notes 15(3), 1990 INSIDE RISKS, Communications of the ACM 40, 12, Dec 1997 RISKS, 1998. Introduction Ingegneria del SW, 02.03.11 7 / 36
Others are absolutely not acceptable! The automatic propulsion control in our Boeing 737 had the occasional habit during take-off at exactly 60 knots of cutting out. It was someone in our workshops who looked at our listings found the cause. The programmer had spelled out what the propulsion control should do under 60 knots and what it should do over 60 knots. But he had forgotten to say how it should react at exactly 60 knots. So if at exactly 60 knots the computer asked for the appropriate instruction it found nothing, got confused, and turned itself off.7
Hasch, 1983

Others are absolutely not acceptable! [With regard to the Lufthansa A320 accident in Warsaw] the spoilers, brakes and reverse thrust were disabled for up to 9 seconds after landing in a storm on a waterlogged runway, and the airplane ran off the end of the runway and into a conveniently placed earth bank, with resulting injuries and loss of life. On 10 Nov, Frankfurter Allgemeine Zeitung reported that Lufthansa had concluded there was a problem with the logic, and was requiring their pilots to land in a different conguration and a different manner in such weather and runway conditions, to fool the logic. This decision was supported by the Luftfahrtbundesamt.8
RISKS-FORUM Digest, Weds 1 December 1993 Volume 15 : Issue 30.

The problem is enormous!
Software development statistics: The typical software project requires 1-2 years and at least 500,000 lines of code. Only between 70-80% of all projects are successfully completed. Over the entire development cycle, each person produces on average less than 10 lines of code per day. During development on average 50-60 errors are found per 1,000 lines of source code. Typically this drops to around 4 after system release.
Introduction
10 / 36
How projects really work (www.projectcartoon.com)
How the customer explained it.
Introduction
11 / 36
How the project leader understood it.
Introduction
11 / 36
How the analyst designed it.
Introduction
11 / 36
How the programmer wrote it.
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
Introduction
11 / 36
How the business consultant described it.
Introduction
11 / 36
How the project was documented.
Introduction
11 / 36
What operations installed.
Introduction
11 / 36
How the customer was billed.
Introduction
11 / 36
How it was supported.
Introduction
11 / 36
What marketing advertized.
Introduction
11 / 36
When it was delivered.
Introduction
11 / 36
What the customer really needed. Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 11 / 36
What the customer The disaster recovery really needed. plan. Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 11 / 36
How did we end up in this wretched state?
Introduction
12 / 36
Historical context: 1960s 1970s
Batch software (punch-cards!) with highly restricted memory. Simple complexity. Low-level, machine-oriented programming languages: Cobol, Fortran, Algol. Development problems spurred interest in semantics and verication questions. The term software crisis was coined in 1965. Initiated research in structured data types leading to ALGOL-W (-68), C, Pascal, Ada.
Introduction
13 / 36
Historical context: 1970s 1980s

Technology supports increasingly large projects. Engineering in the large leads to new kinds of problems. Challenge: programming in teams.
Development must be split decomposition in analysis, specication, coding. Unstructured programming methods dont scale: global data, non-modular construction, lack of well-dene interfaces.
Gradual recognition that software development is difcult! Evolution of concepts like software engineering, structured programming, stepwise renement, modularization, abstract datatypes. Ideas embodied in languages like Pascal, Modula-2, ML, C++, Java.
Current situation new complexities

Large scale, distributed, heterogeneous systems, e.g., Internet-centric computing. Cheap microsystems = massive distribution.
Typical car has 100s of microprocessors. Computerized control systems are increasingly used in security critical applications, e.g., controlling trains, planes, and nuclear reactors.
Introduction
15 / 36
Role of software engineering
Is there a silver bullet ?
NO!
Software engineering is less clear cut than, say, theoretical computer science. But there are techniques, methods, and tools, that can reduce the complexity of constructing systems. There are also techniques for building specic kinds of systems with high degrees of reliability. Distribution systems, embedded systems, real-time systems, etc. all have specialized development/validation techniques.
Introduction
16 / 36
Role of a software engineering course
Is it possible to present and practice the full spectrum of approaches to software engineering in one class? No!
The industrial setting is completely different from a university. Insufcient time for development in the large. Different problems demand different techniques.
We survey central concepts and experiment with selected approaches. Specialized techniques presented in depth in advanced courses.
Introduction
17 / 36
Overview
What is software engineering? Structuring and abstraction in modeling.
Introduction
18 / 36
What is SW engineering?
No consensus. Includes:
Development process and business aspects, e.g., planning, cost and resource estimation, documentation, check-points, etc. Informal heuristics or rules of thumb. Semi-formal methods.
Our denition:
Software Engineering
Software engineering is the practical application of scientic methods to the specication, design, and implementation of programs and systems. Our focus: semi-formal methods.
Luca Vigan (Universit di Verona) Introduction
F O U N D A T I O N S
T O O L S
A P P L I C A T I O N S
19 / 36
(Semi-)Formal Methods
A language is formal when
it has formal language (syntax), whose meaning (semantics) is described in a mathematically precise way.
A development method is formal when

it is based on a formal language and there are semantically consistent transformation/proof rules.
Semi-formal methods are widely used, for example UML. Often just syntax with a mere hint of semantics. Formal methods offer numerous advantages: ++ Typically more concise. ++ Precise and unambiguous. ++ Precise transformation rules = machine support possible. ++ Uniform framework for specication, development, and testing. However they are more difcult for novices.
Formal or Informal?
Answer depends on task and available resources. My sympathies lie with the following author:
This book is a discourse explaining how the task of programming (in the small as well as in the large) can be accomplished by returning to mathematics. By this, I rst mean that the precise mathematical denition of what a program does must be present at the origin of its construction. If such a denition is lacking, or if it is too complicated, we might wonder whether our future program will mean anything at all. [...] At this point, I have no objection with people feeling more comfortable with the word English replacing the word mathematics. I just wonder whether such people are not assigning themselves a more difcult task. (Jean-Raymond Abrial, The B-Book )
We will examine both approaches. Also consider the integration of semi-formal with formal methods.
Thematic overview
Structuring the software development process.
Process models and support tools.
Modeling, specication, renement, implementation, testing, and verication.

(Semi-)formal methods and their integration in development.
Foundations cover many aspects of theoretical computer science.

Syntax and semantics from specication and programming languages. Specication, verication, logic.
Method-oriented themes.
Problem analysis, modularization, OO-development, model building, etc.
Introduction
22 / 36
Organizzazione del corso: 6 CFU
4 CFU di teoria: 32 ore.

Mercoled 15:30 18:00 Venerd 09:30 10:15
2 CFU di esercitazioni/laboratorio: 28 ore.

Venerd 10:30 13:00 (inizio in data da destinarsi)
Theory without application is useless!
Introduction
23 / 36
Modalit di esame
Modalit di esame: 83% teoria e 17% laboratorio. 3 prove che possono anche essere effettuate (e superate) separatamente: i risultati conseguiti valgono no alla ne del corrente Anno Accademico.
Teoria: scritto.
facolt del docente sostituire la prova scritta con una prova orale, in particolare nel caso in cui non sia possibile evitare che gli studenti accedano ad appunti, libri, fotocopie. La prova scritta deve, infatti, essere svolta senza lausilio di appunti o altro.
Laboratorio: 2-3 esercitazioni.

Lavoro in gruppi da 3-4 studenti (dello stesso CdL). Eventuale nuova sessione di esercitazioni di laboratorio in primavera/estate (con gruppi anche pi piccoli).
Lo scritto include una breve verica delle conoscenze acquisite praticamente nel Laboratorio.
La verica ha votazione S/NO, dove un eventuale NO blocca il voto conseguito nello scritto (e nel laboratorio).
Programma
Introduzione allingegneria del software. Il software: prodotto e processo. Caratteristiche di qualit. Ciclo di vita del software. Fasi ed attivit del processo produttivo. Modelli del ciclo di vita dei sistemi software. Pianicazione del processo produttivo. Studio di fattibilit. Determinazione di obiettivi e vincoli. Gestione dei rischi. Controllo dei processi di produzione. Gestione delle congurazioni. Versionamento. Amministrazione di progetto.
Programma
Progettazione del software. Cattura ed analisi dei requisiti. Prototipazione rapida di modelli. Specica e codica. Verica di correttezza. Scalabilit. Progettazione basata su componenti. Norme di codica e documentazione. Il linguaggio standard UML 2 per la modellazione del software. Notazione e principali tipi di diagrammi. Linguaggi formali di specica del software. Implementazione di codice su larga scala (in the large).
Introduction
26 / 36
Programma
Validazione e collaudo del software. Metodi e strategie di validazione. Metodi e strategie di collaudo (di unit, di integrazione, funzionale, di sistema). Metodi e strategie di collaudo di software ad oggetti. Metriche di collaudo. Valutazione. Metriche del software. Modelli di costo. Misurazione e allocazione delle risorse nei progetti software. Progettazione di qualit. Standard ISO 9001, 9000-3, 9126.
Introduction
27 / 36
Literature
I will often follow the books:
Ian Sommerville. Software Engineering (8th ed.), disponibile anche in italiano (8. ed.). Pearson Education (2007). http://www.comp.
lancs.ac.uk/computing/resources/IanS/SE8/index.html
Martin Fowler. UML distilled (3rd ed.), disponibile anche in italiano (3. ed.). Pearson Education (2003). http://martinfowler.com/ Other interesting books are
Fundamentals of Software Engineering by Ghezzi, Jazayeri and Mandrioli, UML in a nutshell by Sinan Si Alhir.
See webpages for resources: slides available (often after) class.

profs.sci.univr.it/~vigano/teaching/IngSW1011 (login: ingsw; password: sweng).
Introduction
28 / 36
Overview
Why bother with software engineering? What is software engineering?
Structuring and abstraction in modeling.
Introduction
29 / 36
Modeling
Goal of development is to solve problems in the real world. Structuring and abstraction are critical: the real world is complex! Models are built in the early development phases. Goal: specify the requirements clearly and precisely while avoiding a premature commitment to algorithms or data-structures. Later one builds models of a possible implementation architecture. Model sketches components, interfaces, communication, etc. Modeling style depends on notion of component, e.g., function, procedure, class, module, . . .
Introduction
30 / 36
Structuring and abstraction in modeling
Important for overcoming the complexity of program development in the large: Structuring serves to organize/decompose the problem/solution. Abstraction aims to eliminate insignicant details. Classical approaches to structuring and simplication include: Functional decomposition: decomposition in independent tasks. Parameterization and generic development: reusability. Model simplication: to improve understanding of tasks and possible solutions. Information-hiding: interfaces and property-oriented descriptions.
Introduction
31 / 36
Structuring (Cont.)
In all cases, interfaces must be clearly described. Interface: imagined or actual boarder between two functional entities with xed rules for the transfer of data. Syntactic properties: the available rules, the types of their arguments, etc. Semantic properties: a description of the entities behavior; goal is to support the proper use of the entity. Interfaces also provide the basis for communicating and explaining (sub)systems between the specier, implementer, and user. Correctly describing interfaces and ensuring their correct use is a central aspect of software engineering.
Introduction
32 / 36
Simplicity in modeling as a key to problem solving

In an American quiz-show, the candidate can win a car if he correctly guess behind which of the three doors A, B , and C , the car is hidden. To make things more interesting, the show proceeds as follows: First the candidate selects one of the three doors. Then the quiz-master opens one of the two remaining doors, choosing so as to not reveal the car. Afterwards, the candidate has the possibility of switching the door he initial selected for the remaining door.
After the initial selection, the car is behind one of the two doors. How should the candidate proceed? Strategies
1 2
He selects a door and does not change his selection. He selects a door and later changes his selection, i.e., choosing the remaining door.
A probabilistic analysis is nontrivial. Solution is simple using an appropriate model!

Solution
Claim: Strategy 2 can be seen as allowing the candidate to choose two doors, and win when the auto is behind one of them. Explanation: Suppose he wishes to select A and B . Then he rst chooses C . After the quiz-master opens one of A or B the candidate switches from C to the remaining door. Hence, he wins the car if it is behind A or B .
Introduction
34 / 36
Modeling example #2: Mutilated checkerboard

! " ! "! #$ # $ # $# & % & % &% '( ' ( ' (' " ; ; # ; $ - - - & ) ) ! "! # # # % % % ' ' ' ' "!" $ $ & & ( ( ( + , + ,+ * ) <<< ... +, ** ! ! # # # # % % % ' ' ' ' "! " " $ $ $ & & & ( ( ( ; < ; 1 - . - .- 4 + , + 5 ) * ) *) <; 2 ,+ 6 / 0/ < 1 2 1 21 . 3 4 3 + 5 6 5 65 * 0/0 43 , ;= < ;= 1 ;= 2 -? . -? .-? 4 + + + + ) )7 *)7 < . , , , * / 0/ < 1 1 1 3 3 3 5 5 5 5 0/0 2 2 4 4 6 6 6 9 : 9 :9 8 7 * >>> @@@ 9: 88 / 0/ > 1 2 1 21 @ 3 4 3 9 5 6 5 65 8 0/0 43 : = > = 1 ? @ ? @? 4 9 : 9 5 7 8 7 87 >= 2 :9 6 = > = >= @ ? @ ? @? 9: 9 : 9 :9 8 7 8 7 87 >
Can the board with two missing corner pieces be tiled with the piece shown? Solution:
Introduction
35 / 36
Modeling example #2: Mutilated checkerboard

! " ! "! #$ # $ # $# & % & % &% '( ' ( ' (' " ; ; # ; $ - - - & ) ) ! "! # # # % % % ' ' ' ' "!" $ $ & & ( ( ( + , + ,+ * ) <<< ... +, ** ! ! # # # # % % % ' ' ' ' "! " " $ $ $ & & & ( ( ( ; < ; 1 - . - .- 4 + , + 5 ) * ) *) <; 2 ,+ 6 / 0/ < 1 2 1 21 . 3 4 3 + 5 6 5 65 * 0/0 43 , ;= < ;= 1 ;= 2 -? . -? .-? 4 + + + + ) )7 *)7 < . , , , * / 0/ < 1 1 1 3 3 3 5 5 5 5 0/0 2 2 4 4 6 6 6 9 : 9 :9 8 7 * >>> @@@ 9: 88 / 0/ > 1 2 1 21 @ 3 4 3 9 5 6 5 65 8 0/0 43 : = > = 1 ? @ ? @? 4 9 : 9 5 7 8 7 87 >= 2 :9 6 = > = >= @ ? @ ? @? 9: 9 : 9 :9 8 7 8 7 87 >
Can the board with two missing corner pieces be tiled with the piece shown? Solution: seek an invariant! Requires understanding important aspects of problem.
Conclusion
Software engineering concerns development in the large and related problems. Techniques for problem structuring and abstraction play an important role. Formality can be helpful, in particular in
Creating meaningful, unambiguous models of systems. Rigorously analyzing and transforming these models.
We will focus on a software development process based on building models, analyzing models, and transforming models into robust, correct, and evolvable systems.
Introduction
36 / 36

Luca Viganò: Dipartimento Di Informatica Università Di Verona

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Luca Viganò: Dipartimento Di Informatica Università Di Verona

Uploaded by

Copyright:

Available Formats

Introduction

Ingegneria del SW, 02.03.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 02.03.11

About myself: Research (and teaching)

distributed security architectures

Luca Vigan (Universit di Verona)

Ingegneria del SW, 02.03.11

Selected denitions from Merriam-Webster Online

Luca Vigan (Universit di Verona)

Luca Vigan (Universit di Verona)

Ingegneria del SW, 02.03.11

Why bother with software engineering?

Luca Vigan (Universit di Verona)

Why bother with software engineering?

Luca Vigan (Universit di Verona)

Why bother with software engineering?

Luca Vigan (Universit di Verona)

Why bother with software engineering? (cont.)

Luca Vigan (Universit di Verona)

Why bother with software engineering? (cont.)

Luca Vigan (Universit di Verona)

Why bother with software engineering? (cont.)

Luca Vigan (Universit di Verona)

Why bother with software engineering? (cont.)

Luca Vigan (Universit di Verona)

Why bother with software engineering? (cont.)

RISKS-FORUM Digest, Weds 1 December 1993 Volume 15 : Issue 30.

Luca Vigan (Universit di Verona)

The problem is enormous!

Luca Vigan (Universit di Verona)

Ingegneria del SW, 02.03.11

How projects really work (www.projectcartoon.com)

How the customer explained it.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 02.03.11

How projects really work (www.projectcartoon.com)

How the customer explained it.

How the project leader understood it.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 02.03.11

How projects really work (www.projectcartoon.com)

How the customer explained it.

How the project leader understood it.

How the analyst designed it.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 02.03.11

How projects really work (www.projectcartoon.com)

How the customer explained it.

How the project leader understood it.

How the analyst designed it.

How the programmer wrote it.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 02.03.11

How projects really work (www.projectcartoon.com)

How the customer explained it.

How the project leader understood it.

How the analyst designed it.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 02.03.11

How projects really work (www.projectcartoon.com)

How the customer explained it.

How the project leader understood it.