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

Course of Software Engineering II a.a. 2001/2002

  • Upload
    kaida

  • View
    30

  • Download
    1

Embed Size (px)

DESCRIPTION

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 - PowerPoint PPT Presentation

Citation preview

Page 1: Course of Software Engineering II a.a. 2001/2002

Course ofSoftware Engineering II

a.a. 2001/2002

Talking about EiffelTalking about Eiffel

Massimo Ruffa

Page 2: Course of Software Engineering II a.a. 2001/2002

• Bertrand MeyerBertrand 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

Page 3: Course of Software Engineering II a.a. 2001/2002

• 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

Page 4: Course of Software Engineering II a.a. 2001/2002

• Bertrand Meyer• EiffelStudioEiffelStudio• 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

Page 5: Course of Software Engineering II a.a. 2001/2002

• 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 1/2

Page 6: Course of Software Engineering II a.a. 2001/2002

• 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

EiffelStudio 2/2

Page 7: Course of Software Engineering II a.a. 2001/2002

• Bertrand Meyer• EiffelStudio• EiffelEiffel• 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

Page 8: Course of Software Engineering II a.a. 2001/2002

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

Page 9: Course of Software Engineering II a.a. 2001/2002

• Bertrand Meyer• EiffelStudio• Eiffel• Software Process in EiffelSoftware Process in Eiffel

– Cluster and Cluster ModelCluster 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

Page 10: Course of Software Engineering II a.a. 2001/2002

• 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

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.

SOFTWARE PROCESS IN EIFFEL

Principles :• Cluster, basic organizational unit• seamlessness and reversibility• generalization for reusability• Constant availability ( current demo )

Page 11: Course of Software Engineering II a.a. 2001/2002

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 )

SW PROCESS in EIFFEL 2/11

BACKBACKBACKBACK

Page 12: Course of Software Engineering II a.a. 2001/2002

Time

Analisys

Design

Implementation

V & V *

* Validation & Verification

Generalization

define the architecture of the classes and their relations

finalize the classes, with all details added

identify the classes (data abstractions) of the cluster and their major features and constraints (yielding invariant clauses)

check that the cluster’s classes perform satisfactorily(through static examination, testing and other techniques)

prepare for reuse

INDIVIDUAL CLUSTER LIFECYCLE

SW PROCESS in EIFFEL 3/11

Page 13: Course of Software Engineering II a.a. 2001/2002

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 4/11

Page 14: Course of Software Engineering II a.a. 2001/2002

Project Time

Cluster 1Cluster 2

Cluster n

The Cluster Model :Sequential andConcurrent Engineering

Feasibility Study

Division into Cluster

Concurrent Engineering

SW PROCESS in EIFFEL 5/11

Page 15: Course of Software Engineering II a.a. 2001/2002

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

SW PROCESS in EIFFEL 6/11

Page 16: Course of Software Engineering II a.a. 2001/2002

Project Time

Cluster 1

Cluster 2

Cluster nMoreapplication-specific

Moregeneral

Client Dependecy

A D I

V &

V

G

A D I

V &

V

G

A D I

V &

V

G

SW PROCESS in EIFFEL 7/11

Page 17: Course of Software Engineering II a.a. 2001/2002

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

SW PROCESS in EIFFEL 8/11

Page 18: Course of Software Engineering II a.a. 2001/2002

• Bertrand Meyer• EiffelStudio• Eiffel• Software Process in EiffelSoftware Process in Eiffel

– Cluster and Cluster Model What is a cluster What is the Cluster Model Project Leader and Cluster Model

– Seamlessness and ReversibilitySeamlessness and Reversibility– Generalization

• Design by Contract– Contract Form– Assertion

Precondition Postcondition Invariant

• RUP vs EIFFEL• BON• Bibliography

Page 19: Course of Software Engineering II a.a. 2001/2002

• 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

SEAMLESSNESS and REVERSIBILITY

BACKBACKBACKBACK

SW PROCESS in EIFFEL 9/11

Page 20: Course of Software Engineering II a.a. 2001/2002

Time

Analisys

Design

Implementation

V & V *

* Validation & Verification

Generalization

SW PROCESS in EIFFEL 10/11

Page 21: Course of Software Engineering II a.a. 2001/2002

• Bertrand Meyer• EiffelStudio• Eiffel• Software Process in EiffelSoftware Process in Eiffel

– Cluster and Cluster Model What is a cluster What is the Cluster Model Project Leader and Cluster Model

– Seamlessness and Reversibility– GeneralizationGeneralization

• Design by Contract– Contract Form– Assertion

Precondition Postcondition Invariant

• RUP vs EIFFEL• BON• Bibliography

Page 22: Course of Software Engineering II a.a. 2001/2002

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

BACKBACKBACKBACK

SW PROCESS in EIFFEL 11/11

Page 23: Course of Software Engineering II a.a. 2001/2002

• 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 ContractDesign by Contract– Contract FormContract Form– Assertion

Precondition Postcondition Invariant

• RUP vs EIFFEL• BON• Bibliography

Page 24: Course of Software Engineering II a.a. 2001/2002

• 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

Page 25: Course of Software Engineering II a.a. 2001/2002

• 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

DESIGN by CONTRACT 2/6

Page 26: Course of Software Engineering II a.a. 2001/2002

• 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 ContractDesign by Contract– Contract Form– AssertionAssertion

Precondition Postcondition Invariant

• RUP vs EIFFEL• BON• Bibliography

Page 27: Course of Software Engineering II a.a. 2001/2002

• 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 3/6

Page 28: Course of Software Engineering II a.a. 2001/2002

• 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 4/6

Page 29: Course of Software Engineering II a.a. 2001/2002

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 5/6

Page 30: Course of Software Engineering II a.a. 2001/2002

• instruction is– prescriptive– describes the “how”– part of the implementation– imperative

• assertion is– descriptive– describes the “what”– an element of specification– is applicative

DESIGN by CONTRACT 6/6

Page 31: Course of Software Engineering II a.a. 2001/2002

• 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 EIFFELRUP vs EIFFEL• BON• Bibliography

Page 32: Course of Software Engineering II a.a. 2001/2002

Integration&

Current Demo

Analisys

Design

Implementation

V & VGeneralization

Design by Contract

RUP vs EIFFEL

RUP Acknowledgment

Page 33: Course of Software Engineering II a.a. 2001/2002

• 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• BONBON• Bibliography

Page 34: Course of Software Engineering II a.a. 2001/2002

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

Page 35: Course of Software Engineering II a.a. 2001/2002

• 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 2/4

Page 36: Course of Software Engineering II a.a. 2001/2002

Static Diagrams

BON 3/4

Page 37: Course of Software Engineering II a.a. 2001/2002

Dinamic Diagrams

BON 4/4

Page 38: Course of Software Engineering II a.a. 2001/2002

BibliographyBibliography

Web Link

BookBook

Web Link

Object Oriented Software Construction ( second edition)Published by Prentice Hall isbn 0-13-629155-4

: all about Eiffel method, Ise Eiffel, Bon Method/Notation

An Eiffel TutorialISE Technical Report TR-EI-66/TU

: information about Eiffel method and notation Invitation to EiffelISE Technical Report TR-EI-67/IV

: information about Ise EiffelEiffelStudio: A Guided TourISE Technical Report TR-EI-68/GT. (Replaces TR-EI-38/EB.)

: information about Ise Eiffel scopes and usageMeyer’ s Personal web pagewww.inf.ethz.ch/personal/meyer

Meyer : the man and his history

ISE web sitewww.eiffel.com : all information about Meyer, Ise Eiffel, Eiffel Method

Page 39: Course of Software Engineering II a.a. 2001/2002

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

Calcolo dei Predicati

BACKBACKBACKBACK

Page 40: Course of Software Engineering II a.a. 2001/2002

• 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

RUP and UML 1/7

Page 41: Course of Software Engineering II a.a. 2001/2002

• 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 2/7

Page 42: Course of Software Engineering II a.a. 2001/2002

• 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 3/7

Page 43: Course of Software Engineering II a.a. 2001/2002

• 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

Inception phase

RUP and UML 4/7

Page 44: Course of Software Engineering II a.a. 2001/2002

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

Elaboration phase

RUP and UML 5/7

Page 45: Course of Software Engineering II a.a. 2001/2002

• 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

Construction phase

RUP and UML 6/7

Page 46: Course of Software Engineering II a.a. 2001/2002

Transition phase

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

BACKBACKBACKBACK

RUP and UML 7/7

Page 47: Course of Software Engineering II a.a. 2001/2002

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

BACKBACKBACK

EIFFEL 1/3

Page 48: Course of Software Engineering II a.a. 2001/2002

• 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

BACKBACKBACK

EIFFEL 2/3

Page 49: Course of Software Engineering II a.a. 2001/2002

• 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

BACKBACKBACK

EIFFEL 3/3

Page 50: Course of Software Engineering II a.a. 2001/2002

Problem

Operation&

Maintenance

WorkingSystem

Code

DesignSpecification

RequirementsSpecification

Requirements Analisys

Design

Implementation

Testing

Val & Ver

Val & Ver

Val &

Ver

Val

Val : ValidationVer : Verification

Waterfall Modelwith iteration

BACKBACKBACKBACK

SW PROCESS in EIFFEL

Page 51: Course of Software Engineering II a.a. 2001/2002

BACKBACKBACK

• 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

{ } { }QAP

13} {x 5 x : x 9} {x >=+=>=

DESIGN by CONTRACT

Page 52: Course of Software Engineering II a.a. 2001/2002

• 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

BACKBACKBACKBACK

BON