Talking about Eiffel
Course of
Software Engineering II
a.a. 2001/2002
Massimo Ruffa
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
Bertrand Meyer
• hold the chair of Software Engineering at ETH, the Swiss Federal
Institute of Technology in Zürich
• adjunct professor at Monash University, Melbourne, Australia
(school of Computer Science and Software Engineering, CSSE)
since 1998
• Chairman of the TOOLS Conference Series ( Technology of
Object-Oriented Languages and Systems )
• CTO at Interactive Software Engineering (ISE)
• ISE co-founder in 1985 ( is best-known for introducing the Eiffel
method, language, and ISE Eiffel software development
environment )
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
EiffelStudio 1/2
• EiffelStudio is the central tool of ISE Eiffel, letting you
−
−
−
−
−
−
−
−
Design
Develop
Debug
Document
Measure
Maintain
Revise
Expand systems
using the full power of object technology and Design by Contract
• is available for the major industry platforms
• it is at its best when used as a combination technology to reuse
software components written in various languages
•
100000 licenses all over the world
EiffelStudio 2/2
• Some ISE Eiffel Projects
– EuroDisney S.C.A. Marne-la-Vallee (France)
 Simulation of park's attractions
– National Defense Research Establishment
 Database query language evaluator; analysis and simulation system for
hostile submarine activity
– Telesoft Rome (Italy)
 Telecommunications applications, networking
– Lucent Technologies Middletown, New Jersey (USA)
 Telecommunications
– Hewlett-Packard, printer division Marina del Rey (California)
 Embedded systems
– CALFP Bank (Credit Agricole Lazard Financial Products Bank) London,
New York, Paris, Singapore, Tokyo
 Futures trading, pricing, bank operations
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
EIFFEL
• covers the whole spectrum of software development
–
–
–
–
–
Analysis and specification
Design and architecture
Implementation
Maintenance
Documentation
• method and language for the efficient description and development
of quality systems
–
–
–
–
–
Reliability
Reusability
Extendibility
Portability
Maintainability
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
SOFTWARE PROCESS IN EIFFEL
• supports the entire lifecycle
• radically different from the traditional Waterfall model and from its
more recent variants such as the spiral model or rapid prototyping
Principles :
•
•
•
•
Cluster, basic organizational unit
seamlessness and reversibility
generalization for reusability
Constant availability ( current demo )
in the author’s mind these are that fit best with the language and the rest of the
method, even if some highly competent and successful Eiffel developers may
disagree with some of them and use a different process model.
SW PROCESS in EIFFEL 2/11
CLUSTER
• group of related classes or, recursively, of related clusters
• natural unit for single-developer mastery:
– each cluster should be managed by one person
– and one person should be able to understand all of it
• Each of the individual cluster lifecycles is based on a continuous
progression of activities, from the more abstract to the more
implementation-oriented in a process of accretion, where each step
enriche the results of the previous one
• The principle is here to treat the software as a single product which
will be repeatedly refined, extended and improved
• Eiffel language supports this view by providing high-level notations
that can be used throughout the lifecycle ( BON )
BACK
SW PROCESS in EIFFEL 3/11
INDIVIDUAL CLUSTER LIFECYCLE
identify the classes (data
abstractions) of the cluster
and their major features and
constraints (yielding invariant
clauses)
Analisys
define the architecture of the
classes and their relations
Design
finalize the classes, with
all details added
Implementation
check that the cluster’s classes
perform satisfactorily
(through static examination,
testing and other techniques)
V&V*
prepare for reuse
Generalization
Time
* Validation & Verification
SW PROCESS in EIFFEL 4/11
CLUSTER MODEL
• assumes that the system is divided into a number of subsystems or
clusters
• keeps from the Waterfall a sequential approach to the development of
each cluster ( without the gaps ), but promotes concurrent
engineering for the overall process using
– information hiding
– Design by Contract
– clearly defined interfaces of clusters
SW PROCESS in EIFFEL 5/11
Feasibility Study
Division into Cluster
The Cluster Model :
Sequential and
Concurrent Engineering
Cluster 1
Cluster 2
Cluster n
Concurrent Engineering
Project Time
SW PROCESS in EIFFEL 6/11
PROJECT CLUSTER AS A SET of ABSTRACTION LAYERS
• information hiding properties of the object-oriented method make
possible concurrent engineering
– thanks to data abstraction it is possible for a cluster to proceed even if
the clusters on which it depends are not yet finished, it suffices that the
analisys phase of the needed classes be complete
• clusters may depend on each other
• rotating the preceding figure we emphasize the software layers
corresponding to the various clusters
• design and implementation of each cluster depend only on the
analisys of clusters below it, not on their own design and
implementation
A
D
I
V&V
SW PROCESS in EIFFEL 7/11
G
Cluster n
More
application-specific
A
I
D
V&V
More
general
G
Cluster 2
A
D
I
Project Time
V&V
Client Dependecy
G
Cluster 1
SW PROCESS in EIFFEL 8/11
PROJECT LEADER and CLUSTER MODEL
• has the responsibility for finding clusters
• is in charge of deciding when to start
– a new cluster
– a new task
• can advances or delay various clusters and steps through
dynamic reallocation of resources
• by the task of Integration can
– avoid divergence between the current states of the various clusters’
development
– ensures that at every stage after start-up there will be a current demo
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
SW PROCESS in EIFFEL 9/11
SEAMLESSNESS and REVERSIBILITY
• defines a single framework for analysis, design, implementation and
maintenance instead of erecting barriers between successive
lifecycle steps
• Reversibility: wisdom sometimes blooms late in the season
BACK
SW PROCESS in EIFFEL 10/11
Analisys
Design
Implementation
V&V*
Generalization
Time
* Validation & Verification
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
SW PROCESS in EIFFEL 11/11
GENERALIZATION
• has no equivalent in traditional approaches
• Its goal is to polish the classes so as to turn them into potentially
reusable software components
• may involve the following activities
–
–
–
–
–
Abstracting
Factoring
Adding assertions ( postconditions and invariant clauses )
Adding rescue clauses to handle exceptions
Adding documentation
BACK
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
DESIGN by CONTRACT
• A system is made of a number of cooperating components. Design
by Contract states that their cooperation should be based on precise
specifications — contracts — describing each party’s expectations
and guarantees
• Contract Form is the fundamental tool for using supplier classes in
the Eiffel method. It enables client authors to reuse software without
having to read their source code, this is a crucial elements
requirement in large-scale industrial developments
DESIGN by CONTRACT 2/6
• Eiffel directly implements this idea, which
– enhance software reliability
– provide a sound basis for software





specification
documentation ( Assertions - Reusable Components )
testing, debugging and quality assurance
exception handling
inheritance
• The underlying theory, the centerpiece of the Eiffel method, views
software construction as based on contracts between clients (callers)
and suppliers (routines), relying on mutual obligations and benefits
made explicit by the assertions
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
DESIGN by CONTRACT 3/6
• are logical properties of object states
• method and notation support writing the assertions to express the terms
of the contracts
• syntactically, the assertions of our notation will simply be boolean
expressions, with a few extensions ( old in postcondition )
• assertions generally cover correctness
• mathematically, the closest notion is that of predicate, although the
assertion language that we shall use has only part of the power of full
first-order predicate calculus
• can express many higher-level properties through function
calls,although the functions involved must be simple and of
unimpeachable correctness
DESIGN by CONTRACT 4/6
• assertions include preconditions, postconditions, class invariants
and also appear in “check” instructions
• precondition
– binds the callers
– expresses the constraints under which a routine will function properly,
appears in the official documentation
• postcondition
– binds the class/routine
– expresses properties of the state resulting from a routine’s execution
• invariant
– a need for expressing global properties of the instances of a class,
which must be preserved by all routines
– capturing the deeper semantic properties and integrity constraints
characterizing a class
DESIGN by CONTRACT 5/6
CORRECTNESS
• with preconditions, postconditions and invariants, we can now define
precisely what it means for a class to be correct
• this provides a basis against which to assess correctness: the class
is correct if and only if its implementation, as given by the routine
bodies, is consistent with the preconditions, postconditions and
invariant
• a class, like any other software element, is correct or incorrect not
by itself but with respect to a specification. By introducing
preconditions, postconditions and invariants we have given
ourselves a way to include some of the specification in the class text
itself
DESIGN by CONTRACT 6/6
• instruction is
–
–
–
–
prescriptive
describes the “how”
part of the implementation
imperative
• assertion is
–
–
–
–
descriptive
describes the “what”
an element of specification
is applicative
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
RUP vs EIFFEL
Design by Contract
Analisys
Design
Implementatio
n
V&V
Generalization
Integration
&
Current Demo
RUP Acknowledgment
•
•
•
•
Bertrand Meyer
EiffelStudio
Eiffel
Software Process in Eiffel
– Cluster and Cluster Model
 What is a cluster
 What is the Cluster Model
 Project Leader and Cluster Model
– Seamlessness and Reversibility
– Generalization
• Design by Contract
– Contract Form
– Assertion
 Precondition
 Postcondition
 Invariant
• RUP vs EIFFEL
• BON
• Bibliography
Business Object Notation
• The original designer of BON was Jean-Marc Nerson of SOL (Paris)
• design was completed with the collaboration of Kim Waldén of Enea
Data (Stockholm)
• is a method and graphical notation for high-level object-oriented
analysis and design
• static part of the model focuses
– Classes, interfaces, their interrelationships, and their
– clusters ( denoting a group of logically related classes )
• dynamic part describes
– objects
– object interactions
– scenarios for message sequencing
BON 2/4
•
formalisms include
– textual notation
• not have to be directly compilable
• use extensions in the area of assertions
– delta a
– forall
– exists
– member_of
– tabular form :
• tabular class chart ( convenient to summarize the properties of a class compactly )
– graphical diagrams
BON 3/4
Static Diagrams
BON 4/4
Dinamic Diagrams
Bibliography
Object Oriented Software Construction ( second edition)
Published by Prentice Hall isbn 0-13-629155-4
: all about Eiffel method, Ise Eiffel, Bon Method/Notation
ISE web site
www.eiffel.com : all information about Meyer, Ise Eiffel, Eiffel Method
An Eiffel Tutorial
ISE Technical Report TR-EI-66/TU
: information about Eiffel method and notation
Invitation to Eiffel
ISE Technical Report TR-EI-67/IV
: information about Ise Eiffel
EiffelStudio: A Guided Tour
ISE Technical Report TR-EI-68/GT. (Replaces TR-EI-38/EB.)
: information about Ise Eiffel scopes and usage
Meyer’ s Personal web page
www.inf.ethz.ch/personal/meyer
Meyer : the man and his history
Book
Web Link
Calcolo dei Predicati
• Diversi alfabeti
− Simboli di costanti
− Simboli di variabile
− Simboli di funzione
− Simboli di predicato
• Una frml f appartenente al CdP è
−
−
−
−
−
−
t1 = t2 (t1, t2 sono termini)
p(t1,…,tn) (p è predicato ; t1, t2 sono termini)
frml1ANDfrml2 (OR,=>,sse,)
NOT frml1
per ogni x . frml
esiste x . Frml
• Un termine è
− Costante
− Variabile
− F(t1,…,tn) (F funzione, t1,..,tn termine)
BACK
RUP and UML 1/7
RUP and UML
• is a Software Engineering Process
• is a configurable process
• It provides
– disciplined approach to assigning tasks and responsibilities within a
development organization
• Its goal :
– is to ensure the production of high-quality software that meets the needs
of its end-users, within a predictable schedule and budget
• is a guide for how to effectively use the Unified Modeling
Language
• UML is a industry-standard language that allows us to clearly
communicate requirements, architectures and designs
RUP and UML 2/7
•
horizontal axis represents time and shows the dynamic aspect of the
process as it is enacted, and it is expressed in terms of
–
–
–
–
•
Cycles
Phases
Iterations
Milestones
vertical axis represents the static aspect of the process: how it is
described in terms of activities, artifacts, workers and workflows
RUP and UML 3/7
•
•
•
The software lifecycle is broken into cycles
Each cycle working on a new generation of the product
RUP divides one development cycle in four consecutive phases
–
–
–
–
•
•
Inception phase
Elaboration phase
Construction phase
Transition phase
Each phase can be broken down into iterations
An iteration is a complete development loop resulting in a release (internal or
external) of an executable product, a subset of the final product under
development, which grows incrementally from iteration to iteration to become
the final system
RUP and UML 4/7
Inception phase
• You establish the business case for the system
–
–
–
–
success criteria
risk assessment
estimate of the resources needed
phase plan showing dates of major milestones
• delimit the project scope
– identify all external entities (with which the system will interact actors)
– define the nature of this interaction at a high-level
• dentifying all use cases
RUP and UML 5/7
Elaboration phase
•
•
•
•
analyze the problem domain
establish a sound architectural foundation
develop the project plan
and eliminate the highest risk elements of the project
RUP and UML 6/7
Construction phase
• remaining components and application features are developed and
integrated into the product, and all features are thoroughly tested
• Is a manufacturing process where emphasis is placed on
– managing resources
– controlling operations to optimize
• Costs
• Schedules
• Quality
• Is a transition from the development of intellectual property during
inception and elaboration, to the development of deployable
products during construction and transition
RUP and UML 7/7
Transition phase
• delivering the software product to the user community
– prepare new releases
– correct some problems
– finish the features that were postponed
BACK
EIFFEL 1/3
Analisys and Specification
• Analisys
– understand the problems that the eventual software system should
solve
– prompt relevant questions and provide a basis for answering questions
about specific properties of the problem and system
– decide what the system should do and should not do
– ascertain that the system will satisfy the needs of its users
– provide a basis for the development of the system
• Specification
– elaborate all analisys results using Design by Contract
– every system component can be accompanied by a precise
specification of its abstract properties
BACK
EIFFEL 2/3
• Analisys and Specification
– where Eiffel can be used as a purely descriptive tool to analyze and
document the structure and properties of complex systems (even nonsoftware systems)
• Design and Architecture
– where Eiffel can be used to build solid, flexible system structures
• Implementation
– where Eiffel provides practical software solutions with an efficiency
comparable to solutions based on such traditional approaches as C and
Fortran
• Maintenance
– where Eiffel helps thanks to the architectural flexibility of the resulting
systems
• Documentation
– where Eiffel permits automatic generation of documentation, textual and
graphical, from the software itself, as a partial substitute for separately
developed and maintained software documentation
BACK
EIFFEL 3/3
• Reliability
– producing bug-free systems, which perform as expected
• Reusability
– making it possible to develop systems from prepackaged, high-quality
components, and to transform software elements into such reusable
components for future reuse
• Extendibility
– developing software that is truly soft — easy to adapt to the inevitable
and frequent changes of requirements and other constraints
• Portability
– freeing developers from machine and operating system peculiarities, and
enabling them to produce software that will run on many different
platforms
• Maintainability
– yielding software that is clear, readable, well structured, and easy to
continue enhancing and adapting
BACK
SW PROCESS in EIFFEL
Problem
Requirements Analisys
Val
Requirements
Specification
Waterfall Model
with iteration
Design
Val & Ver
Design
Specification
Implementation
Val & Ver
Code
Testing
Working
System
Operation
&
Maintenance
Val
&
Ver
Val : Validation
Ver : Verification
BACK
DESIGN by CONTRACT
•
Meaning of a correctness formula P A Q 
“Any execution of A, starting in a state where P holds, will terminate in a
state where Q holds.”
– Es : {x  9} x : x  5 {x  13}
•
meaning of such a correctness formula is: whenever A is executed in a
state satisfying P, the execution will terminate in a state satisfying Q
•
not empty (put (s, x))
•
remove (put (s, x)) = s
BACK
BON
• three key concepts of the BON method
– seamlessness : use of a continuous process throughout the
software lifecycle
– seversibility : support for both forward and backward engineering
– contracting : precise definition, for each software element, of the
associated semantic properties
• is based on concepts similar to those of Eiffel but can be used
independently of Eiffel, for example by people using another O-O
language for implementation
BACK