Professional Documents
Culture Documents
Luca Vigan
Dipartimento di Informatica Universit di Verona
Introduction
1 / 36
Analysis of
" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " "
SW architectures / SW engineering
From specication to real bridge
Introduction
3 / 36
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
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
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
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
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
Introduction Ingegneria del SW, 02.03.11 8 / 36
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
Introduction
11 / 36
Introduction
11 / 36
Introduction
11 / 36
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
Introduction
11 / 36
How the programmer What the beta wrote it. testers received.
What the customer really needed. Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 11 / 36
How the programmer What the beta wrote it. testers received.
What the customer The disaster recovery really needed. plan. Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 11 / 36
Introduction
12 / 36
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
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.
Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 14 / 36
Introduction
15 / 36
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
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
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.
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.
Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 20 / 36
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.
Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 21 / 36
Thematic overview
Structuring the software development process.
Process models and support tools.
Method-oriented themes.
Problem analysis, modularization, OO-development, model building, etc.
Introduction
22 / 36
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.
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).
Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 24 / 36
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.
Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 25 / 36
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.
Introduction
28 / 36
Overview
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
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
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.
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
Can the board with two missing corner pieces be tiled with the piece shown? Solution:
Introduction
35 / 36
Can the board with two missing corner pieces be tiled with the piece shown? Solution: seek an invariant! Requires understanding important aspects of problem.
Luca Vigan (Universit di Verona) Introduction Ingegneria del SW, 02.03.11 35 / 36
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