Transcript Chair of Software Engineering

1
Object-Oriented Software Construction
Bertrand Meyer
Chair of Software Engineering
OOSC - Summer Semester 2004
Contact
2
 Chair of Software Engineering:
 http://se.inf.ethz.ch
 Course assistant:
 Joseph N. Ruskiewicz
 http://se.inf.ethz.ch/people/ruskiewicz
Chair of Software Engineering
OOSC - Summer Semester 2004
3
Lecture 1:
Introduction, Quality issues, Lifecycle
Chair of Software Engineering
OOSC - Summer Semester 2004
Agenda for today
 Introduction
 Quality issues
 Lifecycle
Chair of Software Engineering
OOSC - Summer Semester 2004
4
Agenda for today
 Introduction
 Quality issues
 Lifecycle
Chair of Software Engineering
OOSC - Summer Semester 2004
5
Introduction







6
Course objectives
Topics
Technologies
Guest lectures
Textbook
Grading
Practical setup
Chair of Software Engineering
OOSC - Summer Semester 2004
Course objectives
 Provide you with solid knowledge of:
 Object technology principles and methods
 The practice of object-oriented analysis, design
and implementation
 Some open issues
 Some recent developments
 Two specific technologies
Chair of Software Engineering
OOSC - Summer Semester 2004
7
Topics












8
Quality issues
Lifecycle
Abstract Data Types
Object model choices
Inheritance techniques
Design patterns
Concurrent object-oriented computation
Language mechanisms
Persistence and O-O database
Project management
Genericity, typing issues, covariance
…
Chair of Software Engineering
OOSC - Summer Semester 2004
Technologies
9
 Eiffel
 .NET
Chair of Software Engineering
OOSC - Summer Semester 2004
Textbook
10
 Bertrand Meyer: Object-Oriented Software
Construction, 2nd edition. Prentice Hall, 1997.
 Available from Ruth Bürkli, RZ-F8
 Price: CHF 81.00
 Recommended:
 Erich Gamma et al.: Design Patterns. AddisonWesley, 1995.
Chair of Software Engineering
OOSC - Summer Semester 2004
Grading
11
 Exam (2h): 40%
 28 June 2004
 Project: 60%
 Development of an “Object-Oriented
Requirements Annotator”
 Deadline: 30 June 2004
Chair of Software Engineering
OOSC - Summer Semester 2004
Practical setup
 Course page:
 http://se.inf.ethz.ch/teaching/ss2004/0250/
 Slides:
 http://se.inf.ethz.ch/teaching/ss2004/0250/index.html#slides
Chair of Software Engineering
OOSC - Summer Semester 2004
12
Practical setup (cont’d)
 Please send an email:
 To: [email protected]
 Subject: OOSC course participant
 Content:
 Your name
 Preferred email address
 Status
 Diplom student (semester), Ph.D. student, other.
 Taking the course for credit or not.
 Attach a picture (JPEG, GIF, PNG) if you wish
Chair of Software Engineering
OOSC - Summer Semester 2004
13
Practical setup (cont’d)
 If any questions / problems, contact:




Joseph N. Ruskiewicz
http://se.inf.ethz.ch/people/ruskiewicz
Office: RZ-J22
Phone: 01 632 67 61
Chair of Software Engineering
OOSC - Summer Semester 2004
14
Before getting started…
 Please fill in the questionnaire:
 Anonymous!
 You have 10 minutes
Chair of Software Engineering
OOSC - Summer Semester 2004
15
Some words of warning
 Steps in reacting to O-O (from the preface to
Object-Oriented Software Construction):
 “(1) It’s trivial;
 (2) It’s wrong;
 (3) That’s how I did it all along anyway.”
 Beware of the “mOOzak” phenomenon.
Chair of Software Engineering
OOSC - Summer Semester 2004
16
Some words of warning (cont’d)
benefit_from_course is
-- Make students succeed.
require
some_humility
do
all_exercises
ensure
OO_mastery_for_fun_and_profit
end
Chair of Software Engineering
OOSC - Summer Semester 2004
17
Terminology
18
 I will be strict about terminology:
 Endless confusions in the literature and in discussions.
 Basic concepts have precise definitions — no justification
whatsoever for such confusions.
 Object technology is (in part) about bringing rational,
scientific principles to software. No excuse for sloppy
terminology.
 Alternative conventions will be mentioned when
necessary.
 CHF 5 fine for saying “object” when meaning
“class” (after lecture 4)
Chair of Software Engineering
OOSC - Summer Semester 2004
Agenda for today
 Introduction
 Quality issues
 Lifecycle
Chair of Software Engineering
OOSC - Summer Semester 2004
19
The goal: Software quality









REUSABILITY
EXTENDIBILITY
RELIABILITY
 Correctness
 Robustness
 Integrity
PORTABILITY
EFFICIENCY
…
20
SPECIFICATION
Correctness
Robustness
Integrity
Correctness:
 The ability of a software system to perform according to
specification, in cases defined by the specification.
Robustness:
 The ability of a software system to react in a reasonable manner
to cases not covered by the specification.
Integrity:
 The ability of a software system to react in a reasonable manner
to cases of unauthorized access and modification.
Chair of Software Engineering
OOSC - Summer Semester 2004
The challenge of software quality
21
 Reliability [correctness + robustness]:
 It should be easier to build software that
functions properly, and easier to guarantee what
it does.
 Modularity [reusability + extendibility]:
 We should build less software!
 Software should be easier to modify.
Chair of Software Engineering
OOSC - Summer Semester 2004
Agenda for today
 Introduction
 Quality issues
 Lifecycle
Chair of Software Engineering
OOSC - Summer Semester 2004
22
The waterfall model of the lifecycle
FEASIBILITY STUDY
REQUIREMENTS
ANALYSIS
SPECIFICATION
GLOBAL DESIGN
DETAILED DESIGN
IMPLEMENTATION
VALIDATION &
VERIFICATION
DISTRIBUTION
PROJECT PROGRESS
Chair of Software Engineering
OOSC - Summer Semester 2004
23
Arguments for the waterfall
(After B.W. Boehm: Software engineering
economics)
 The activities are necessary.
 (But: merging of middle activities.)
 The order is the right one.
Chair of Software Engineering
OOSC - Summer Semester 2004
24
The waterfall model of the lifecycle
FEASIBILITY STUDY
REQUIREMENTS
ANALYSIS
DESIGN AND
IMPLEMENTATION
SPECIFICATION
GLOBAL DESIGN
DETAILED DESIGN
IMPLEMENTATION
VALIDATION &
VERIFICATION
DISTRIBUTION
PROJECT TIME
Chair of Software Engineering
OOSC - Summer Semester 2004
25
Problems with the waterfall
 Late appearance of actual code.
 Lack of support for requirements change — and
more generally for extendibility and reusability.
 Lack of support for the maintenance activity (70%
of software costs?).
 Division of labor hampering Total Quality
Management.
 Impedance mismatches.
 Highly synchronous model.
Chair of Software Engineering
OOSC - Summer Semester 2004
26
Quality control?
Analysts
Designers
Implementers
Testers
Customers
Chair of Software Engineering
OOSC - Summer Semester 2004
27
Impedance mismatches
As Management requested it.
As Programming developed it.
As the Project Leader defined it.
As Operations installed it.
28
As Systems designed it.
What the user wanted.
(Pre-1970 cartoon; origin unknown)
Chair of Software Engineering
OOSC - Summer Semester 2004
The escherfall (Spiral)
29
M.C Escher:
Waterval
Chair of Software Engineering
OOSC - Summer Semester 2004
Tasks
30
Analysts
Designers
Implementers
Testers
Chair of Software Engineering
OOSC - Summer Semester 2004
Seamless development (1)
Specification
TRANSACTION, PLANE,
CUSTOMER, ENGINE...
Example classes
Chair of Software Engineering
OOSC - Summer Semester 2004
31
Seamless development (2)
Specification
Design
TRANSACTION, PLANE,
CUSTOMER, ENGINE...
STATE, USER_COMMAND...
Example classes
Chair of Software Engineering
OOSC - Summer Semester 2004
32
Seamless development (3)
Specification
Design
Implementation
TRANSACTION, PLANE,
CUSTOMER, ENGINE...
STATE, USER_COMMAND...
HASH_TABLE,
LINKED_LIST...
Example classes
Chair of Software Engineering
OOSC - Summer Semester 2004
33
Seamless development (4)
Specification
Design
TRANSACTION, PLANE,
CUSTOMER, ENGINE...
STATE, USER_COMMAND...
Implementation
HASH_TABLE,
LINKED_LIST...
V&V
TEST_DRIVER, ...
Example classes
Chair of Software Engineering
OOSC - Summer Semester 2004
34
Seamless development (5)
Specification
Design
TRANSACTION, PLANE,
CUSTOMER, ENGINE...
STATE, USER_COMMAND...
Implementation
HASH_TABLE,
LINKED_LIST...
V&V
TEST_DRIVER, ...
Generalization
AIRCRAFT, ...
Example classes
Chair of Software Engineering
OOSC - Summer Semester 2004
35
Analysis classes
36
deferred class VAT
inherit
TANK
feature
in_valve, out_valve: VALVE
fill is
require
deferred
ensure
end
Precondition
-- Fill the vat.
in_valve.open
out_valve.closed
in_valve.closed
out_valve.closed
is_full
-- i.e. specified only.
-- not implemented.
Postcondition
empty, is_full, is_empty, gauge, maximum, ... [Other features] ...
invariant
Class invariant
is_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum)
end
Chair of Software Engineering
OOSC - Summer Semester 2004
At the source of object technology
Kristen Nygaard (Oslo, 1967)
To program is to understand
Chair of Software Engineering
OOSC - Summer Semester 2004
37
Reversibility
38
S
S
D
I
V
G
Chair of Software Engineering
OOSC - Summer Semester 2004
Seamless development
 Use consistent notation from analysis to design,
implementation and maintenance.
 Advantages:
 Smooth process. Avoids gaps (improves
productivity, reliability).
 Direct mapping from problem to solution, i.e.
from software system to external model.
 Better responsiveness to customer requests.
 Consistency, ease of communication.
 Better interaction between users, managers and
developers.
Chair of Software Engineering
OOSC - Summer Semester 2004
39
Single model principle
 Use a single base for everything: analysis, design,
implementation, documentation...
 Use tools to extract the appropriate views.
Chair of Software Engineering
OOSC - Summer Semester 2004
40
Generalization
 Prepare for reuse
 For example:
 Remove built-in limits
 Remove dependencies on specifics of project
 Improve documentation, contracts...
 Extract commonalities and revamp inheritance
hierarchy
 Few companies have the guts to provide the
budget for this
Chair of Software Engineering
OOSC - Summer Semester 2004
41
The cluster model
S
42
Cluster 1
Cluster 2
D
I
V
G
S
D
I
V
G
Chair of Software Engineering
Cluster n
S
S
D
D
I
I
V
V
G
G
OOSC - Summer Semester 2004
The cluster model: extreme variants (1)
Feasibility
study
Division into
clusters
Cluster 1
Cluster 2
Cluster 4
Cluster 3
Cluster 5
Specification
Specification
Specification
Specification
Specification
Specification
Specification
Specification
Specification
Specification
Design
Design
Design
Design
Design
Implementation
Implementation
Implementation
Implementation
Implementation
V&V
V&V
V&V
V&V
V&V
Generalization
Generalization
Generalization
Generalization
Generalization
“Clusterfall”
Chair of Software Engineering
OOSC - Summer Semester 2004
43
The cluster model: extreme variants (2)
Feasibility
study
Division into
clusters
Cluster 1
Cluster 2
Cluster n
The Trickle model
Chair of Software Engineering
OOSC - Summer Semester 2004
44
Quality goals: the Osmond curves
Other qualities
DESIRABLE
Debugging
COMMON
Functionality
Envisaged
Early releases
Chair of Software Engineering
OOSC - Summer Semester 2004
45
Cluster development
 Bottom-up development: from the most general
clusters (providing utility functions) to the most
application-specific ones.
 Flexible scheduling of clusters – depending on
resources, team experience, customer and
management demands. Waterfall is one extreme;
“trickle” is the other.
 Sub-lifecycle sequencing: specification, design and
implementation, validation, generalization.
 Relations between clusters: each cluster may be a
client of lower-level ones.
Chair of Software Engineering
OOSC - Summer Semester 2004
46
Reading assignment
 For Monday 5 April 2004: OOSC2 chapters
 Chapter 1: Software quality
 Chapter 28: The software construction process
Chair of Software Engineering
OOSC - Summer Semester 2004
47
48
End of lecture 1
Chair of Software Engineering
OOSC - Summer Semester 2004