Approche objet avec UML (Unified Modeling Language)Pr. Jean-Marc JzquelIRISA - Univ. Rennes ICampus de Beaulieu F-35042 Rennes Cedex Tel : +33 299 847 192 Fax : +33 299 842 532 e-mail : jezequel@irisa.fr http://www.irisa.fr/prive/jezequel

J.-M. Jzquel

1

1 - IntroductionLingnierie du logiciel aujourdhui

J.-M. Jzquel

2

1

Automotive industry: Volkswagen

J.-M. Jzquel

3

Google300 000 serveurs rpartis dans une vingtaine de datacenters.

Une phnomnale capacit de calcul qui permet Google d'assurer le fonctionnement d'un grand nombre de services Google Earth

rpondre plus d'1 milliard de requtes par jour, chacune interrogeant 8 milliards de pages Web en moins d'un cinquime de seconde

J.-M. Jzquel

4

2

Nokia1,1 milliard de tlphones portables en circulation 100 millions de plus par an

Des milliers de versions de logiciels Time-to-market ~ 3 mois Evolution permanente infrastructure GSM Nokia 50% des exigences ont chang aprs le gel du cahier des charges 60% de ceux-ci ont chang au moins 2 fois!

Cest le cas gnral plutt que lexception Cahier des charges fig = rve des annes 70 J.-M. Jzquel 5

Des logiciels complexes...Logiciels de grande taille des millions de lignes de code des quipes nombreuses dure de vie importante des lignes de produits plateformes technologiques complexes volution continue

Logiciels complexes Logiciels critiques ... J.-M. Jzquel 6

3

L'industrie logicielle aujourd'huistandardization organization

assemblers architects

middleware providers

site administrators

component developers J.-M. Jzquel

component testers

application testers

tool vendors end users7

L'industrie logicielle aujourd'huistandardization organization

assemblers De nombreux acteurs architects

middleware providers

des proccupations diffrentes des mtiers diffrents des comptences varies des outils varis diffrents lments logiciels Sparation des proccupations tool vendors application component testers testers site administrators

component developers J.-M. Jzquel

end users

8

4

Sparations des proccupationsPoint de vue des

promoteursPoint de vue des

Point de vue des

locataires

pompiersPoint de vue du

Point de vue des

plombiers

cadastre

Point de vue des

Point de vue des

lectricienssystmePoint de vue des

assureurs

paysagistesPoint de vue des

notaires

Point de vue des

architectes

J.-M. Jzquel

9

Sparations des proccupationsUtile mme pour des systmes "moins" complexes

Point de vue du

propritairePoint de vue du

Point de vue du

plombier cadastre

Point de vue de l'

lectriciensystme

Point de vue de l'

Point de vue du

architecte

maon

J.-M. Jzquel

10

5

ProblmatiqueComplexit croissante des logiciels Sparations des proccupations Sparations des mtiers Multiplicit des besoins Multiplicit des plateformes volution permanente

Logiciel = Code ? J.-M. Jzquel 11

Multiples modles d'un mme systmemodles modlespour les pompiers pour les promoteurs

modles

pour les plombiers

modlespour le cadastre

modlessystme

pour les lectriciens

modles

pour l'assureur cadastre

modles modles

pour les paysagistes

modles J.-M. Jzquel

pour les notaires

pour les architectes

12

6

Objectifs du coursCe cours montre comment partir de la notation UML il est possible de dfinir un certain nombre de modles plus ou moins abstraits plus ou moins labors mais dcrivant tous une facette complmentaire du systme raliser selon un point de vue ou un mtier diffrent.

Laccent est mis sur les rgles de cohrence intra et intermodles, ainsi que sur la diffrence qui peut tre fait entre modles conceptuels, de spcification et dimplmentation modles mtiers et modles techniques modles produits et modles de processus.

J.-M. Jzquel

13

Client

1..4 titulaires

0..*

Compte numro solde ... 1

1..*

Banque numro nom

1..*carte insre

1 signataire CarteBleue Code retraitMax

0..* Consortium 1

En attentecarte retire

En attente du codemauvais code code frapp

0..*

0..1 AcceptPar> 1..* Distributeur 0..*

En attente retrait carte

En vrificationcode bon

montant incorrect

En attente du montantmontant correct

billets retirs

En distributionRetirerDeLArgent

ConsulterSonCompte Client

Ajouter DesBillets

Transporteur DeBillets

FaireUnVirement

Assurer LaMaintenance

Technicien

DistributeurDeBillet

systme

paul

le distrib.

la carte de P.

la reserve

la banque

le compte de P.

la reserve6 : sortir 5 billet de 100 fr

retirer 500 fr lire n compte

1 : retirer 500 fr

3 : retirer 500 fr sur compte n

4 : dbiter(500)

retirer 500 fr sur le compte n

le distributeur pauldbiter 500 fr

la banque5 : confirmer

confirmer sortir 5 billets de 100 fr prendre la carte

2 : lire n de compte

la carte de P.

le compte de paul

J.-M. Jzquel

14

7

SynthseDes Modles plutt que du Code Un modle est la simplification/abstraction dun aspect de la ralit Nous construisons donc des modles afin de mieux comprendre les systmes que nous dveloppons Nous modlisons des systmes complexes parce que nous somme incapables de les comprendre dans leur totalit Le code ne permet pas de simplifier/abstraire la ralit J.-M. Jzquel 15

2 - Pourquoi UML ?

J.-M. Jzquel

16

8

Origines de lapproche objetModlisation => Simulation Simula -> Simula 67 objet, classe, hritage, liaison dynamique.

Mais aussi OS : Moniteurs ADT : classe abstraite IA : frame unit autonome de connaissance intelligence, gestion complexit = proprit mergente du systme

J.-M. Jzquel

17

Gnalogie de UMLUML(Rumbaugh, Booch, Jacobson) FUSION(HP-Labs) CLASSERELATION (P. Desfray) CRC (R. Wirf-Brooks)

Use-Case (I.Jacobson)OOA (P. Coad) JSD (M. Jackson) OOA - OODLE (Schlaer & Mellor)

OMT(J. Rumbaugh et al.)

OOA-OOD(G.Booch)

Data-Flow SADT/SA-SD (De Marco) J.-M. Jzquel

Diagrammes Etat-Transition (HAREL)

Entite-Relation Merise (Chen)18

9

HistoriqueDfinition en cours par une commission de rvision Soumission lOMG

UML 2.0 UML 1.x UML 1.21999-2002 Juin 1998 Novembre 1997 Septembre 1997 Janvier 1997 Juin 1996 Octobre 1995

Standardisation par lOMG Soumission lOMG Soumission lOMG Version bta OOPSLA96 OOPSLA95

UML 1.1 UML 1.0 UML 0.9 Mthode unifie 0.8 Booch93 OMT-2 OMT-1 OOSE

Autres mthodes J.-M. Jzquel

Booch91

Partenaires19

AujourdhuiUML est le langage de modlisation orient objet le plus connu et le plus utilis au monde UML sapplique plusieurs domaines OO, RT, Deployment, Requirement,

UML nest pas une mthode RUP

Peut dutilisateurs connaissent le standard, ils ont une vision outille dUML (Vision Utilisateur) 5% forte comprhension, 45% faible comprhension, 50% aucune comprhension

UML est fortement critiqu car pas assez formel Le march UML est important et saccrot MDA et MDD, UML2.1, IBM a rachet Rational !!!

J.-M. Jzquel

20

10

Un peu de Mthodologie...Une mthode de dveloppement de logiciels, cest : Une notation La syntaxe --- graphique dans le cas de UML

Un mta-modle La smantique --- paramtrable dans UML (strotypes)

Un processus Dtails dpendants du domaine dactivit : Informatique de gestion Systmes ractifs temps-rels Shrink-wrap software (PC)

J.-M. Jzquel

21

Processus de dveloppement avec UMLApproche itrative, incrmentale, dirige par les cas dutilisation Expression des besoins Analyse Elaboration d un modle idal

Conception passage du modle idal au monde rel

Ralisation et Validation

J.-M. Jzquel

22

11

3 UML pour lutilisateur

J.-M. Jzquel

23

Modlisation UMLModlisation selon 4 points de vue principaux : Aspects statiques du systme (le QUI?) Description des objets et de leurs relations Modularit, contrats, relations, gnricit, hritage Structuration en paquetages

Vision utilisateur du systme (le QUOI?) Cas dutilisation

Aspects dynamiques du systme (le QUAND?) Diagramme de squences (scnarios) Diagramme de collaborations (entre objets) Diagramme dtats-transitions (Harel) Diagramme dactivits

Vision implantation (le OU?) Diagramme de composants et de dploiement J.-M. Jzquel 24

12

Modlisation UMLModlisation selon 4 points de vue principaux : Aspects statiques du systme (le QUI?) Description des objets et de leurs relations Modularit, contrats, relations, gnricit, hritage Structuration en paquetages

Vision utilisateur du systme (le QUOI?) Cas dutilisation

Aspects dynamiques du systme (le QUAND?) Diagramme de squences (scnarios) Diagramme de collaborations (entre objets) Diagramme dtats-transitions (Harel) Diagramme dactivits

Vision implantation (le OU?) Diagramme de composants et de dploiement J.-M. Jzquel 25

Objet (Dfinition)Formellement : la fermeture transitive dune fonction Concrtement : encapsulation dun tat avec un ensemble doprations travaillant sur cet tat abstraction dune entit du monde rel existence temporelle : cration, volution, destruction

identit propre chaque objet peut tre vu comme une machine ayant une mmoire prive et une unit de traitement, et rendant un ensemble de services

J.-M. Jzquel

26

13

Classe Dfinition en temps que typeImplantation dun type de donn abstrait Description des proprits et des comportements communs un ensemble dobjets un objet est une instance dune classe (eq. variable vs. type)

Chaque classe a un nom, et un corps qui dfini : les attributs possds par ses instances les oprations dfinies sur ses instances, et permettant daccder, de manipuler, et de modifier leurs attributs

une classe peut elle mme tre un objet (Smalltalk) J.-M. Jzquel 27

Notations UML pour classes et objetsReprsentation dune classeReprsentation simplifie

Comptesolde: Somme plancher: Somme crditer (Somme) dbiter (Somme)

Compte

Nom de la classe

Reprsentation des objetsCL805699 : Compte

Compartiment des Attributs Compartiment des Oprations

Nom de lobjet

J.-M. Jzquel

28

14

Classe vs. ObjetsUne classe spcifie la structure et le comportement d'un ensemble d'objets de mme natureLa structure d'une classe est constante

Compte numro solde : rel dcouvertMax : entier consulterSolde() : entier crditer( somme : entier) dbiter( somme )

Diagramme de classes

M1 M0Des objets peuvent tre ajouts ou dtruits pendant l excution La valeur des attributs des objets peut changer J.-M. JzquelleCompteDeMarie:Compte numro = 2275 solde = 10000 dcouvertMax = -1000 leCompteDePaul : Compte numro = 6688 solde = 5000 dcouvertMax = -100

Diagramme d objets

:Compte numro = 1200 solde = 150 dcouvertMax = 10

29

Classe Dfinition en temps que moduleModularit = Gestion complexit des systmes Concept prsent depuis longtemps en informatique subroutines, unit de compilation (le fichier en C)

Notion de module intgre aux langages Modula-2 (module), Ada83 (package), puis lang. objets

Favorise : masquage dinformation (abstraction) encapsulation (facilite les modifications porte locale) dissociation interface/implantation=> composant rutilisable J.-M. Jzquel 31

15

VisibilitDiffrentes visibilits des membres d'une classe

public = + Interface protg = #

usager

hritier

priv = implmenteur

corps J.-M. Jzquel 32

Visibilit : ExempleReprsentation

Classe+a1 : T1 -a2 : T2 #m1 (p1,P2,p3) +m2 (p1,P2,p3)

J.-M. Jzquel

33

16

Principe de lapproche objetStructurer les systmes autour des objets Plutt quautour des fonctions

Lapproche par modlisation facilite Communication (et V&V) avec donneur dordre (Validation) entre les activits de dvp et de maintenance (Vrification)

Continuit entre les diffrentes phases du cycle de vie cf. Jackson et JSD

Obtenir des systmes modulaires et maintenables Notion de lignes de produits Assemblage de briques de base vs. dvp ad-hoc Produire des canevas d application vs. un programme J.-M. Jzquel 34

Approche OO : Modlisation et Composants

Canevas dapplications (frameworks) Composants changeables mme aprs dploiement Garanties ?

Fonctionnelles , synchronisation, performances, QdS J.-M. Jzquel 35

17

Facteurs de qualit externesValidit Aptitude raliser les tches dfinies par sa spcification Spcifications informelles => objectif difficile atteindre

Robustesse Aptitude fonctionner mme dans des conditions anormales Raction non catastrophique des situations non prvues par la spcification, forcment incomplte

Extensibilit Facilit dadaptation dun logiciel aux changements (correctifs ou volutifs) de spcification viter les logiciels chteau de cartes J.-M. Jzquel 36

Facteurs de qualit externesRutilisabilit Aptitude tre rutilis en partie pour de nouvelles applications Cesser de rinventer, re-coder, et surtout, re-tester

Compatibilit Aptitude des logiciels pouvoir tre combins entre eux Paradigme de lenvoi de messages

Efficacit Bonne utilisation des ressources du matriel: processeurs, mmoires, communications, etc. A ne pas confondre avec temps rel

J.-M. Jzquel

37

18

Facteurs de qualit externesPortabilit Facilite avec laquelle un produit logiciel peut-tre adapt diffrents environnements matriels et logiciels souvent imcompatible avec efficacit optimale...

Vrifiabilit Facilit de prparation des procdures de validation (tests), de recette et de certification

Ergonomie Facilit avec laquelle les utilisateurs dun composant peuvent apprendre lutiliser et en tirer le meilleur parti documentation jour (=> extraite du code)

J.-M. Jzquel

38

Les concepts de lapproche objetPour aller vers la ralisation des objectifs de qualit externe, il faut : modularit (cf ci-dessus) contrats (exprims en OCL) relations entre objets (abstraient implantation) gnricit (modules paramtrs) hritage (classification, rutilisation) et liaison dynamique J.-M. Jzquel 39

19

Problme de la validit des composantsIntra-composant validit dun composant isol hypothse : environnement correct problme : correction vis--vis dune spcification

Inter-composants validit dun assemblage de composants hypothse : chaque composant valide vs sa spcification problme : intgration de systmes

J.-M. Jzquel

40

De la difficult de la validation intracomposantAcqurir une valeur positive n Tant que n > 1 faire si n est pair alors n := n / 2 sinon n := 3n+1 Sonner alarme;

Prouver que lalarme est sonne pour tout n? Indcidabilit de certaines proprits problme de larrt de la machine de Turing...

Recours au test ici, si machine 32 bits, 2^31 = 10^10 cas de tests 5 lignes de code => 10 milliards de tests ! J.-M. Jzquel 41

20

Validit inter-composants : Peut-on (r)-utiliser un composant?

J.-M. Jzquel

42

Ariane 501 Vol de qualification Kourou, ELA3 -- 4 Juin 1996,12:34 UTH0 -> H0+37s : nominal Dans SRI 2: BH (Bias Horizontal) > 2^15 convert_double_to_int(BH) fails! exception SRI -> crash SRI2 & 1

OBC disoriented Angle attaque > 20, charges arodynamiques leves Sparation des boosters

J.-M. Jzquel

43

21

Ariane 501 : Vol de qualificationKourou, ELA3 -- 4 Juin 1996,12:34 UTH0 + 39s: auto-destruction (cot:500M)

J.-M. Jzquel

44

Pourquoi ? (cf. IEEE Comp. 01/97)

Pas une erreur de programmation Non-protection de la conversion = dcision de conception ~1980

Pas une erreur de conception Dcision justifie vs. trajectoire Ariane 4 et contraintes TR

Problme au niveau du test dintgration As always, could have theoretically been caught. But huge test space vs. limited resources Furthermore, SRI useless at this stage of the flight! J.-M. Jzquel 45

22

Pourquoi? (cf. IEEE Computer 01/97)

Rutilisation dans Ariane 5 dun composant de Ariane 4 ayant une contrainte cache ! Restriction du domaine de dfinition Prcondition : abs(BH) < 32768.0

Valide pour Ariane 4, mais plus pour Ariane 5

J.-M. Jzquel

46

Spcification = contrat entre un composant et ses clientsDans la vie relle, diffrents types de contrats Du Contrat social de Jean-Jacques Rousseau au cash & carry

De mme, plusieurs types de contrats dans un monde rparti

J.-M. Jzquel

47

23

Quatre niveaux de contrats logicielsElmentaire (syntaxique) le programme compile

Comportemental (fonctionnel) pr et post conditions

Cf. IEEE Computer July 1999

Synchronisations e.g. path expressions, etc. [McHale]

Qualit de service (quantitative) Ngociation dynamique possible

J.-M. Jzquel

48

Composant de confiance?

Spcification (e.g., avec UML)

Implantation(EJB,COM+,CCM)

V & V (e.g., tests)

Confiance = cohrence entre ces 3 aspects J.-M. Jzquel 49

24

Reprsentation des contrats en UMLTypage par signature des mthodes insuffisant besoin de pouvoir exprimer des restrictions valeurs d entres et de sorties

besoin de prciser la smantique ce que fait une mthode (le quoi) sans entrer dans le dtail comment : Indpendance vis--vis de limplantation

Inspire par la notion de Type Abstrait de Donnes: Spcification = Signature + Prconditions (conditions sous lesquelles une routine peut tre appele) Postconditions (proprits garanties par une routine) Invariants de classe (vrai lentre et la sortie des routines) J.-M. Jzquel 50

OCL : Object Constraint LanguageLangage de description de contraintes de UML des contraintes restreignant les domaines de valeurs peuvent tre ajoutes aux lments du modle UML

Contrainte = expression boolenne (sans effet de bord) portant sur oprations usuelles sur types de base (Boolean, Integer...) attributs dinstances et de classes oprations de query (fonctions sans effet de bord) associations du modle UML tats des StateCharts associs

J.-M. Jzquel

51

25

Reprsentation des contraintes OCLDirectement dans le modle notation entre { } accroche un lment de modle Compte{solde>=plancher}

solde: Somme plancher: Somme crditer (Somme) dbiter (Somme)

Dans un document spar, en prcisant le contexte

context Compte inv: solde >= plancher

Invariants = Proprits vraies pour l'ensemble des instances de la classe dans un tat stable, chaque instance doit vrifier les invariants de sa classe J.-M. Jzquel 52

Prcondition: ce qui doit tre respect par le clientSpcification des conditions ncessaires pour quun client soit autoris appeler une mthode exemple: montant > 0

Notation en UML {precondition OCL boolean expression} Abbreviation: {pre: OCL boolean expression}

J.-M. Jzquel

53

26

Postcondition: Ce qui doit tre assu par limplantationSpcification de ce qui sera vrai la compltion dun appel valide une mthode exemple: solde = solde @pre + montant

Notation en UML {postcondition OCL boolean expression} Abbreviation: {post: OCL boolean expression} Oprator pour accder la valeur d avant (idem old Eiffel): OCL expression @pre J.-M. Jzquel 54

Etre abstrait et prcis avec UMLCompte{solde>=plancher}

solde: Somme plancher: Somme crditer (montant : Somme){pre: montant > 0} {post: solde = solde @pre + montant}

dbiter (montant: Somme){pre: montant > 0 and montant

Distributeur

0 . . *

1 . . *

Un diagramme dobjets dcrit un tat possible un instant t, un cas particulier doit tre conforme au modle de classes

: Carte Bleue s i g n a t a i r e

paul : Client t i t u l a ti ir te us tl i a t i u r l t e a i s i t r u e l s a i r e s

c1 : Comp te

: B a n q u e

pierre : Client

c2 : Comp te

: Cons ortiu m

marie : Client s i g n a t a i r e

c3 : Comp te

: B a n q u e

: Carte Bleue EstA ccept Par > EstA ccept Par > : Carte Bleue

sophi e: Client

: Distri buteu r s i g n a t a i r e

: B a n q u e

c1 : Comp te

paul : Client t i t u l a it ri et su lt ai i t r u l

: Cons ortiu m

c2 : Comp te

pierre : Client

: B a n q u e

c3 : Comp te

e t s i t

a i r e s

: Carte Bleue EstA ccept Par > EstA ccept Par >

u l a i r e s

marie : Client s i g n a t a i r e

: Distri buteu r

sophi e: Client

Les diagrammes dobjets peuvent tre utiliss pour expliquer un diagramme de classe (donner un exemple) valider un diagramme de classe (le "tester")

J.-M. Jzquel

70

Cas particuliers de relations

Relations rflexivesencadre chef 1 sous-fifre 1..*

Personne

Une relation rflexive lie des objets de mme classe

J.-M. Jzquel

71

35

Composition et AgrgationCas particuliers de relations : Notion de tout et parties1 transporte

Voiture

passager Personne *

moyen_de_transport

1

1 roulement >4,6

Composition

Roue

Agrgation

structure > 1

Chassis

J.-M. Jzquel

72

Autre vues de la composition/agrgationDiffrentes formes suggrant linclusionVoiture roulement[4-6]: Roue structure: Chassis Voiture roulement 4-6 structure 1 Roue Chassis

J.-M. Jzquel

73

36

Relations n-airesRelations entre plus de 2 classes ( viter si possible)PROFESSEUR* Enseignant Destinataire 1..* Enseignement 1..* Enseigne MATIERE

CLASSE

PROFESSEUR

0..*

1..*

1..*

Enseignement1..* 1..* 1 Enseigne

MATIERE

Enseignant

Destinataire J.-M. Jzquel

CLASSE74

Associations attribuesL'attribut porte sur le lien

candidat preuve Etudiant Note

n..k objet_preuve Matire

J.-M. Jzquel

75

37

Classes associationPour associer des attributs et/ou des mthodes aux associations => classes associations

employs

socits 0..2

Personne

*

Socit

Emploisalaire augmenter()

Le nom de la classe correspond au nom de lassociation (problme: il faut choisir entre forme nominale et forme verbale) J.-M. Jzquel 76

Classes associationemploys socits

Personne

*

0..2

Socit

Emploi

M1 M0e1 salaire = 1500 xerox

salaire augmenter()

employ employ

e2 salaire = 700

jean e3 salaire = 1000 marieemploy

ujf

Le salaire est une information correspondant ni une personne, ni une socit, mais un emploi (un couple personne-socit).

J.-M. Jzquel

77

38

Classes association : traductionemploys socits 0..2

Personne

*

Socit

Emploi

employ

emplois 0..2

emplois *

Personne

1

Emploi

socit

1

Socit

Il ne peut y avoir qu'un Emploi entre une Personne et une Socit J.-M. Jzquel 78

Qualifieurs dassociationsUn qualifieur est un attribut spcial qui permet, dans le cas d'une relation 1-vers-plusieurs ou plusieurs-vers-plusieurs, de rduire la cardinalit. Il peut tre vu comme une cl qui permet de distinguer de faon unique un objet parmi plusieurs.

J.-M. Jzquel

79

39

Qualifieurs dassociations : Exemple

Rpertoire

0..*

0..1 FichierNom du fichier

Rpertoire

Nom du fichier

Fichier

Relation non qualifie

Relation qualifie Un rpertoire + un nom de fichier identifient de faon unique un fichier

J.-M. Jzquel

80

Cardinalit des Associations QualifiesCas classique: cardinalit 0..1 Banquenc

0..1

Compte

Cas plus rare: cardinalit * (pas de contrainte particulire exprime) Banquetitre

*

*

Employe

Cas plus rare: cardinalit 1 (gnralement c'est une erreur) Echiquiernl : NumLigne nc : NumCol

1

Case

181

0 comme cardinalit minimale, sauf si le domaine de l'attribut qualifieur est fini et toutes les valeurs ont une image. J.-M. Jzquel

40

Contraintes OCL navigant les relationsChaque association est un chemin de navigation Le contexte d une expression OCL est le point de dpart (la classe de dpart) Les noms de rles sont utiliss pour identifier quelle relation on veut naviguerPersonne 1 propritairepossession

proprit *

Voiture

Context Voiture inv: self.propritaire.age >= 18

J.-M. Jzquel

82

Navigation des relations 0..*Par navigation on n obtient plus un scalaire, mais une collection d objets OCL dfini 3 sous-types de collections Set : obtenu par navigation dune relation 0..* Context Personne inv: proprit retourne un Set[Voiture] chaque lment est prsent au plus une fois

Bag : si plus dun pas de navigation un lment peut tre prsent plus d une fois

Sequence : navigation dune relation {ordered} c est un Bag ordonn

Nombreuses oprations prdfinies sur les types collection. Syntaxe :Collection->opration J.-M. Jzquel 83

41

Oprations de base sur collectionsisEmpty vrai si la collection na pas dlments Context Personne inv: ageisEmpty

notEmpty size

vrai si la collection a au moins un lment nombre dlments dans la collection

count (elem) nombre doccurrences de elem dans la collection J.-M. Jzquel 84

Opration selectSyntaxes possibles collection->select(elem:T | expr) collection->select(elem | expr) collection->select(expr)

Slectionne le sous-ensemble de collection pour lequel la proprit expr est vraie e.g.context Personne inv: proprit->select(v: Voiture | v.kilometragenotEmpty

ou en raccourci :context Personne inv: proprit->select(kilometragenotEmpty J.-M. Jzquel86

42

Opration forAllSyntaxes possibles collection->forall(elem:T | expr) collection->forall(elem | expr) collection->forall(expr)

Vrai si expr est vrai pour chaque lment de collection e.g.context Personne inv: proprit->forall(v: Voiture | v.kilometrageforall(kilometrage graphe orient (graphe dhritage)Hritage simple AEROPLANE Hritage multipleAEROPLANE VEHICULE_DE_TRANSPORT

AVION J.-M. Jzquel

AVION93

Utilisation de lhritageMcanisme dextension de module ajout de fonctionnalits dans la sous-classe customisation et combinaison de composants logiciels rutilisation de code

Mcanisme de classification : sous-typage relation X est-une-sorte-de Y (est substituable ) organisation des systmes complexes (cf. Linnaeus) rutilisation dinterface

J.-M. Jzquel

94

46

Classes abstraitesCapturent des comportements communs Servent structurer un systme Ont des oprations dont limplantation est absente deferred en Eiffel pure virtual en C++ abstract en Java

Ne peuvent donc pas tre instancies Smantique des oprations abstraites spcifiable invariants, pre et post-conditions J.-M. Jzquel 95

Reprsentation de classes abstraitesClasses sans instances immdiatesForme {abstract}

Carre

Cercle

Une instance de Forme est obligatoirement une instance de la classe Carre ou de la classe Cercle

J.-M. Jzquel

96

47

Reprsentation des oprations abstraitesOpration sans corps dune classe abstraiteForme {abstract}calculer_surface () {abstract}

Carrecalculer_surface()

Cerclecalculer_surface()

J.-M. Jzquel

97

Interfaces et lollipop

interface

MOBILE

MOBILE

RaffinementAVION

AVION

J.-M. Jzquel

98

48

Hritage des relationsLes relations sont hrites par les sous classes :VEHICULE motorisation 1 MOTEUR

VOITURE REPERTOIRE

CAMION lien logique 1..* * FICHIER

DRIVER

FICHIER_TEXTE

FICHIER_BINAIRE

J.-M. Jzquel

99

Hritage des contratsLSP (Liskov Substituability Principle) Analogy with subcontracting a routine subcontracts its implementation to its redefined version

Preconditions can only be weakened in Eiffel: require else

Postconditions can only be strengthened in Eiffel: ensure then

J.-M. Jzquel

100

49

Polymorphisme et liaison dynamiquePolymorphisme : possibilit de changer de forme f : FORME; c: CERCLE; k: CARRE; f := c; f := k

Liaison dynamique : leffet de lappel dune opration dun objet dpend de sa forme effective lexcution f.imprimer; -- diffrent selon que f est CERCLE ou CARRE

Espace de nommage rduit et uniforme Mise en facteur des parties communes Possibilit de conteneurs htrognes J.-M. Jzquel 101

Polymorphisme : exempleT contient des FORMEs en fait des instances de sous-classes de FORME

Programmes de type : T[1]