Diapositiva 1

1
Talking about Eiffel
Course of Software Engineering II a.a. 2001/2002
Massimo Ruffa
2

• 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

3
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 )

4

• 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

5
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

6
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

7

• 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

8
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

9

• 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

10
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 authors 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.
11
CLUSTER
SW PROCESS in EIFFEL 2/11

• 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 )

12
INDIVIDUAL CLUSTER LIFECYCLE
SW PROCESS in EIFFEL 3/11
identify the classes (data abstractions) of the
cluster and their major features and constraints
(yielding invariant clauses)
define the architecture of the classes and their
relations
finalize the classes, with all details added
check that the clusters classes perform
satisfactorily (through static examination,
testing and other techniques)
prepare for reuse
13
CLUSTER MODEL
SW PROCESS in EIFFEL 4/11

• 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

14
SW PROCESS in EIFFEL 5/11
Feasibility Study
The Cluster Model Sequential and Concurrent
Engineering
Division into Cluster
15
PROJECT CLUSTER AS A SET of ABSTRACTION LAYERS
SW PROCESS in EIFFEL 6/11

• 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

16
SW PROCESS in EIFFEL 7/11
Cluster n
Cluster 2
Cluster 1
17
PROJECT LEADER and CLUSTER MODEL
SW PROCESS in EIFFEL 8/11

• 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

18

• 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

19
SEAMLESSNESS and REVERSIBILITY
SW PROCESS in EIFFEL 9/11

• 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

20
SW PROCESS in EIFFEL 10/11
21

• 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

22
GENERALIZATION
SW PROCESS in EIFFEL 11/11

• 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

23

• 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

24
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
  partys 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

25
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

26

• 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

27
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

28
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 routines 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

29
CORRECTNESS
DESIGN by CONTRACT 5/6

• 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

30
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

31

• 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

32
RUP vs EIFFEL
Design by Contract
Integration Current Demo
RUP Acknowledgment
33

• 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

34
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

35
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

36
BON 3/4
Static Diagrams
37
BON 4/4
Dinamic Diagrams
38

• 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/persona
l/meyer Meyer the man and his history
Book
Book
Web Link
Web Link
39
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,gt,sse,)
• NOT frml1
• per ogni x . frml
• esiste x . Frml
• Un termine è
• Costante
• Variabile
• F(t1,,tn) (F funzione, t1,..,tn termine)

40
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

41
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

42
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

43
Inception phase
RUP and UML 4/7

• 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

44
Elaboration phase
RUP and UML 5/7

• analyze the problem domain
• establish a sound architectural foundation
• develop the project plan
• and eliminate the highest risk elements of the
  project

45
Construction phase
RUP and UML 6/7

• 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

46
Transition phase
RUP and UML 7/7

• delivering the software product to the user
  community
• prepare new releases
• correct some problems
• finish the features that were postponed

47
Analisys and Specification
EIFFEL 1/3

• 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

48
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 non-software
  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

49
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

50
SW PROCESS in EIFFEL
Requirements Analisys
Waterfall Model with iteration
Problem
Val
Requirements Specification
Design
Val Ver
Implementation
Design Specification
Val Ver
Code
Testing
Working System
Operation Maintenance
Val Ver
Val Validation
Ver Verification
51
DESIGN by CONTRACT

• Meaning of a correctness formula Any
  execution of A, starting in a state where P
  holds, will terminate in a state where Q holds.
• Es
• 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

52
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