Formalismes et méthodes Objet 1 Méthodologie objet Survol du formalisme UML T. Libourel [email protected] Avec la complicité de M Huchard

Formalismes et méthodes Objet

1

Méthodologie objet

Survol du formalisme UML

T. Libourel

[email protected]

Avec la complicité de M Huchard


2

Plan

• De l ’analyse à la réalisationaspects LPOaspects SI / BD

• Introduction - Généralités sur les méthodes objet

• Concepts objet et formalisme UML


3

Plan

• Introduction - Généralités sur les méthodes objet


4

Introduction

• Évolution des paradigmes de programmation

• Évolution des besoins

• Évolution des technologies


5

Introduction

• Taille et complexité des systèmes importantes et croissantes

– les besoins et les fonctionnalités augmentent

– la technologie évolue rapidement

– les architectures se diversifient

• Problèmes des spécifications– parfois imprécises, incomplètes, ou incohérentes

– assurer l’interface avec le métier (domaine d’application)


6

• Évolution des applications– évolution des besoins des utilisateurs

– réorientation de l'application

– évolution de l'environnement technique (matériel et logiciel)

• Problèmes liés à la gestion des équipes– taille croissante des équipes

– spécialisation technique

– spécialisation métier

Introduction


7

Introduction

Pourquoi des méthodes ?

• Une nécessité

Entreprise

Outils Informatiques


8

Introduction


• Démarche reproductible pour obtenir des résultats fiables

• Construire des modèles à partir d'éléments (concepts)

• Possibilité de représenter à partir de formalismes

• Mise en œuvre


9

Une méthode d’analyse et de conception

– propose une démarche qui distingue les étapes du développement dans le cycle de vie du logiciel (modularité, réduction de la complexité, réutilisabilité éventuelle, abstraction)

– s’appuie sur un formalisme de représentation qui facilite la communication, l’organisation et la vérification

– produit des documents (modèles) qui facilitent les retours sur conception et l’évolution des applications

Introduction



10

Historique

• Méthodes cartésiennes

Jackson, SADT, Yourdon

• Méthodes systémiques

Merise, Axial, Information Engineering

• Méthodes objet

OOD, HOOD, OMT, OOSE, OOA/OOD, etc.


11

Concepts généraux

• Conceptualiser

obtenir un énoncé du problème (utilisateurs)

• Analyser

spécifier le problème

• Implémenter

réaliser la solution informatique

• Concevoir

une solution informatique


12

Concepts généraux

Étapes Résultats

Planification Schéma directeur

Analyse des besoins Modèle des besoins

Spécification formelle ou analyse Modèle conceptuel

Spécification technique ou conception Modèle logique

Implémentation Modèle physique

Intégration et Tests Rapport de cohérence logique

Validation du système Rapport de conformité

Maintenance et évolution Documentation et trace


13

Concepts généraux

• Cycles de développement

- en cascade

- en V

- en spirale

- tridimensionnel


14

Analyse

Conception

Implémentation

Tests

Maintenance

Modèle de cycle en cascade


15

• Organisation séquentielle des phases du cycle de vie

• Une phase est structurée en un ensemble d'activités pouvant s'exécuter en parallèle par plusieurs personnes

• Le passage d'une phase à la suivante ne se fait que lorsque les sorties de la première ont été fournies



16


• Pour :– Organisation simple et directe

• Contre :– Retours sur les phases précédentes difficiles (rupture entre

les phases)– Visualisation et validation tardive


17

Implémentation

Expressiondes besoins

Validationdes besoins

Validationfonctionnelle

Spécificationfonctionnelle

Conceptiondu système

Tests dusystème

Tests descomposants

Conceptiondes composants

Modèle de cycle en V


18


• Approche descendante dans les phases précédents l’implémentation : on décompose le système au fur et à mesure qu’on le construit

• Approche ascendante dans les phases suivantes : on recompose le système en testant les parties

• Hiérarchie de tests : les différents tests provoquent un retour d’information directement sur la phase permettant de corriger les erreurs.


19


• Pour :– Décomposition du système en sous-système

– Hiérarchie de tests et retours facilités

– Vérification ascendante

• Contre :– Validation en fin de cycle (erreurs d’analyse coûteuses)


20

Conception

Analyse

Spécifications Besoins

Validation

Tests

Implémentation

Modèle de cycle en spirale


21


• Modèle itératif– On passe par toutes les phases du cycle de vie plusieurs fois

• Modèle incrémental– On améliore à chaque passage

• Un passage peut aussi bien permettre d’évaluer un nombre réduit de fonctionnalités ou l’organisation générale du système de façon non détaillée


22


• Pour :– Réalisation de plusieurs prototypes (versions) avant la

réalisation du système réel (définitif)

– Validation progressive et précoce

– Souplesse dans le choix des prototypes

• Contre :– Mise en œuvre parfois coûteuse

– Possibilité de divergence, nombre de prototypes difficile à déterminer


23

• Simplicité

• Facilité pour coder et réutiliser

• Modèle plus proche de la réalité

– description plus précise des combinaisons

(données, opérations)

– décomposition basée sur “classification naturelle”

– facile à comprendre et à maintenir

• Stabilité

– de petites évolutions peuvent être prises en compte sans changements massifs

Pourquoi l’approche objet ?Pourquoi l’approche objet ?


24

• Omniprésence technique de l’Objetdans les langages de programmation, les bases de données, les interfaces graphiques, ... et les méthodes d’analyse et de conception.

• Universalité de l’Objetla notion d’objet, plus proche du monde réel,

est compréhensible par tous et facilite la communication entre tous les intervenants d’un projet.

Pourquoi l’approche objet ?Pourquoi l’approche objet ?


25

Au début des années 90, une cinquantaine de méthodes objet, liées uniquement par un consensus autour d’idées communes (objets, classes, sous-systèmes, ...)

Recherche d’un langage commun unique utilisable par toute méthode objet

– dans toutes les phases du cycle de vie,

– compatible avec les techniques de réalisation actuelles.


26

UML (Unified Modeling Language)

OOD (Booch) OMT (Rumbaugh)OOSE (Jacobson)

OOPSLA

OMG

UML

Autres


27

Autres méthodes Booch’91 OMT-1 OOSE Partenaires

Booch’93 OMT-2

OOPSLA’95 Unified Method 0.8Com

men

tair

es d

u pu

blic

UML 0.9 & 0.91Juin 96 puis OOPSLA’96

UML 1.0Soumission à l’OMG - Janvier 97

UML 1.1

UML 1.2

UML 1.3

Standardisation à l’OMG - Novembre 97

Version intermédiaire non publiée

Version béta - fin 99


28

Plan

• Concepts objet et formalisme UML


29

VueCas d’utilisation

Vue structurelle

Vue Architecture

(déploiement)

Vue dynamique

Points de vue sur le système

Concepts généraux

Vue Implémentation

<------- Logique Physique ------>


30

Modèle déploiement

Modèle Dynamique

Modèle structurel

Quatre points de vueTypes d'objets et leurs relations

Stimuli des objets et leurs réponses

Modèle implémentation

Concepts généraux


31

Un modèle est une représentation abstraite d ’une réalité, il fournit une image simplifiée du monde réel.

Il permet :

- de comprendre et visualiser (en réduisant la complexité)

- de communiquer (à partir d ’un « langage » commun à travers un nombre restreint de concepts)

- de valider (contrôle de la cohérence, simuler, tester …)

Concepts généraux


32

Diagrammes (représentations graphiques de modèle)

de classesd ’instances

d'états

Diagrammes de déploiement

de composants

Diagrammes Diagrammes de collaboration

de séquences

Diagrammes Cas d ’utilisation

Concepts généraux


33

Analyse Conception Implémentation

Démarche uniforme sur le cycle de vie

Même notation

Concepts généraux


34

Formalisme UML - Concepts objet

• Modèle d’utilisation

• Modèle structurel

• Modèle dynamique

• Modèle d’implémentation


35

Modèle d’utilisation

Les « USE CASE »

• Modèles descriptifs du point de vue des utilisateurs

• Scénarios fonctionnels

• Focus la manière d’utiliser le système


36


On part de l ’analyse des besoins ….

Deux concepts

Acteur

toute entité extérieure au système et interagissant avec celui-ci.

acteurs humains, acteurs « machine » (système extérieur communiquant avec le système étudié)

Use case

toute manière d’utiliser le système

suite d ’événements vue du point de vue de l ’utilisateur


37


Deux concepts

Acteur

Use case

Acteur (rôle 1)

Acteur (rôle 2)

« communicate »

« communicate »


38


Acteur (rôle 1)

Acteur (rôle 2)

Les cas d ’utilisation peuvent être liés par des relations

- d’utilisation « include » (on utilise une partie commune)

- de raffinement « extends » (on traite des exceptions)

« include »« extends »

- de généralisation/spécialisation« generalizes »


39


Délimiter le système

- ce qui est extérieur et qui communique avec le système

- ce qui est interne au système

Définir les fonctionnalités du système du point de vue des utilisateurs

Donner une description cohérente de toutes les vues que l ’on peut avoir du système


40

Modèle structurel

En UML, le modèle structurel ou statique est décrit à l'aide de deux sortes de diagrammes

– Diagrammes de classes

(description de tout ou d'une partie du système d'une manière abstraite, en termes de classes, de structure et d'associations).

– Diagrammes d'objets

(description d'exemples de configuration de tout ou partie du système, en termes d'objets, de valeurs et de liens).


41

Modèle structurel

Objets du monde réel

Objets informatiques

État Internecaché

Comportementvisible

Les objets


42

Modèle structurel

Comportement influe sur l'étatEtat réflète les comportements passés

Objet

Etat ---> évolue au cours du temps

Comportement ---> actions et réactions

Identité ----> essence


43

Sophie

Alain

Système

BD

Luc

: Professeur

: Discipline

Deux objetsou instances

Modèle structurel


44

Modèle structurel

Première abstraction

Une classe peut être vue

- la description en intention d'un groupe d'objets

ayant même structure (même ensemble d'attributs),

ayant même comportement (mêmes opérations),

ayant une sémantique commune.

- la « génitrice » des objets ou instances

- le « conteneur » (extension) de toutes ses instances


45

Classe

Attributs (propriétés)

Voiture

type : stringmarque : stringcouleur : string

Titine :Voiture

type =205Peugeotrouge

Modèle structurel

Instance

Valeurs d'attributs (État)

« Est-instance-de »


46

Opérations et méthodes

Voiture

type : stringmarque : stringcouleur : string

repeindre(c: Couleur)déplacer (d : longueur)

Méthodes

Implémentations

Modèle structurel

nom de la classe

attributs

opérations


47

Modèle structurel

• Un objet est instance d'une (seule) classe :– il se conforme à la description que celle-ci fournit,– il admet une valeur pour chaque attribut déclaré à son attention dans

la classe,– il est possible de lui appliquer toute opération définie à son attention

dans la classe.

• Tout objet admet une identité qui le distingue

pleinement des autres objets :– il peut être nommé et être référencé par un nom (mais son identité ne

se limite pas à ça).


48

Association / Lien (analogie Classe / Instance)

Pays Ville

nom nom

a-pour-capitale

Association

: Paysnom=France

:Villenom = Paris

a-pour-capitale

Lien

Modèle structurel


49

Modèle structurel

Association en général binaire (degré = 2) mais ..

Adhérent Exemplaireemprunte

DispositifDeLecture

lire

nom d'association

association binaire association ternaire


50

Multiplicité et rôles d'une association

Société Personne

nomadresse

nomdate de nais.n°SSadresse

emploie

travaille-pour

employeur employé

chef

travailleur

encadreModèle structurel

* 1..*

1..*

0..1


51

Modèle structurel

exactement 1Classe

1

0..1

Classe0..*

Classe1..*

Classe2..4

Classe2,4

au plus 1

aucun, 1 ou plusieurs (défaut)

au moins 1

de 2 à 4

2 ou 4

Multiplicité

Classe


52

Conseils pour la modélisation d'association

- verbes candidats possibles

- ne pas "dériver vers la conception" (pointeurs ou attributs référentiels)

Modèle structurel


53

Entreprise Personne

nomadresse

nomdate de nais.adresse

quantité

Possède-des-actions

capital actionnaire

Modèle structurel

Classe association

Ligne de portefeuille

* 1..*


54

Classe association

Utilisateur Station de travail

nom nom

Autorisation

Autorisé sur

prioritédroits

Répertoire

répertoire de rattachement

Modèle structurel

1..*1..*

1..*


55

Classe association

Modèle structurel

• Une classe d'association permet de modéliser une association par une classe.

• Les liens d'une telle association sont alors des objets instances de cette classe.

• À ce titre, ils admettent une valeur pour tout attribut déclaré dans la classe d'association ; et on peut leur appliquer toute opération définie dans celle-ci.

• En tant que classe, une classe d'association peut à son tour être associée à d'autres classes (voire à elle-même par une association réflexive).


56

Association qualifiée

Banque Personne

num_client

est_client

Modèle structurel

Dossier_C

1..*1..*

Banque Personnenum_client

est_client

1..* 0..1


57

Modèle structurel

D ’autres « abstractions »

- associations particulières (composition / agrégation)

- spécialisation / généralisation


58

Association particulière Tout /partie

Barre titre Fond Barre AscenseurFrontière

IndicateurTitre Bouton Ferm Flèche

Fenêtre

0..2

2

Modèle structurel

Composition


59

Agrégation

Sémantique Collection/Élément

Arbre

Département

Forêt

1

1..n

Région

Pays

1

1..n

1

1..n

Modèle structurel


60

Composition / Agrégation

Modèle structurel

Contraintes

- Exclusivité/Partage

- Dépendance/Indépendance

Propagation/Diffusion


61

Modèle structurel

Généralisation / Spécialisation

Mécanismes d’inférences intellectuelles de caractéristiques

Soit on affine (spécialisation)

Soit on abstrait (généralisation)

Sémantique

Point de vue ensembliste

Point de vue logique


62

Personne

nom adresse

Étudiant

num_carte adresse

Enseignant

grade adresse enseigner

{disjoint}

Modèle structurel



63


Pompe Échangeur Réservoir

Pompe Cent. Pompe Imm. Réservoir Press.

Équipement

...

Type d'équipement

...

Type de pompe

...

Type de réservoir

Modèle structurel


64

Généralisation / Spécialisation multiple

Modèle structurel

Véhicule terrestre Véhicule aquatique

Auto Véhicule amphibie Bateau

Véhicule


65

Composition/Agrégation ou généralisation ?

Agrégation

- lien entre instances

- un arbre d'agrégation est composé d'objets qui sont parties d'un objet composite

Généralisation

- lien entre classes

Modèle structurel


66


Modèle structurel

• Une sous-classe “hérite” de sa super-classe la description des instances :

– les déclarations d'attributs,

– les définitions d'opérations,

– les associations définies sur la super-classe,

– les contraintes (on en parle plus tard).

• Une sous-classe peut redéfinir de façon plus spécialisée une partie ou la totalité de la description « héritée », mais il n'y a pas d'exception à l'héritage.


67

Classes abstraites

Modèle structurel

• Une classe abstraite est une classe non instanciable, c'est à dire qu'elle n'admet pas d'instances directes.

• Une classe abstraite est une description d'objets destinée à être « héritée » par des classes plus spécialisées.

• Pour être utile, une classe abstraite doit admettre des classes descendantes concrètes.

• La factorisation optimale des propriétés communes à plusieurs classes par généralisation nécessite le plus souvent l'utilisation de classes abstraites.


68

Opérations abstraites

Modèle structurel

• Une opération abstraite est une opération n'admettant pas d'implémentation : au niveau de la classe dans laquelle est déclarée, on ne peut pas dire comment la réaliser.

• Les opérations abstraites sont particulièrement utiles pour mettre en œuvre le polymorphisme.

• Toute classe concrète sous-classe d'une classe abstraite doit “concrétiser” toutes les opérations abstraites de cette dernière.


69

Classes abstraites

Modèle structurel

FormeGéométrique

dessiner()déplacer(delta : Vecteur)

centre : Point

régulier : Boolean

PolygonegrandDiam : VecteurpetitDiam : Vecteur

dessiner()

opération abstraite

classe abstraite

classe abstraite (dessiner() est héritée et non concrétisée)

opération concrétisée

classe concrète

Polygone utile que si spécialisée

Ellipse


70

Interfaces

Modèle structurel

• Une interface est une collection d'opérations utilisée pour spécifier un service offert par une classe.

• Une interface être vue comme une classe sans attributs et dont toutes les opérations sont abstraites.

• Une interface est destinée à être “réalisée” par une classe (celle-ci en hérite toutes les descriptions et concrétise les opérations abstraites).

• Une interface peut en spécialiser une autre, et intervenir dans des associations avec d'autres interfaces et d'autres classes.


71

Interfaces

Modèle structurel

MenuPopUp

BlocDeChoixsetDefault(o : Option)getChoice() : Option Option

choix

1..*

setDefault(o : String)getChoice() : String

setDefault(o : Bouton)getChoice() : Bouton Bouton

choix

1..*

String

choix1..*opérations

concrétisées

«interface» interface

opérations abstraites

réalisation

MenuBouton


72

Interfaces

Modèle structurel

Deux notations pour l'utilisation d'une interface

MenuPopUpsetDefault(o : Option)getChoice() : Option

«interface»

BlocDeChoix

MenuPopUp

ApplicationFenêtrée

«uses»

ApplicationFenêtrée«uses»

BlocDeChoix

interfaceinterfaceclasse utilisatriceclasse utilisatrice

utilisationutilisation

réalise


73

Les contraintes

Modèle structurel

• Les contraintes sont des prédicats, pouvant porter sur plusieurs éléments du modèle statique, qui doivent être vérifiés à tout instant.

• Les contraintes permettent de rendre compte de détails à un niveau de granularité très fin dans un diagramme de classe. Elles peuvent exprimer des conditions ou des restrictions.

• En UML, les contraintes sont exprimées sous forme textuelle, entre accolades et de préférence en OCL (Object Constraint Language).

• Les contraintes sont héritées.


74

Les contraintes

Modèle structurel

Exemples de contraintes sur associations

Chemin

Arête

*

1..*

Personne Comité

préside *1

membreDe

**{subset}

{ordered} contrainte sur extrémité

d'association

contrainte entre 2 associations


75

Les contraintes

Modèle structurel

Exemple de contraintes à différents niveaux

contrainte sur classe

Personnechef

subordonné

diriger

actif : Real {value 0}passif : Real

Société

{ actif = passif }

{ Personne.employeur = Personne.chef.employeur }

employeur

* 1..* 0..10..1

contrainte sur attributcontrainte sur

2 associations


76

Quelques compléments de notation

Modèle structurel

• Une relation de dépendance peut être exprimée entre deux éléments de notation. Elle est le plus souvent stéréotypée. Il y a plusieurs stéréotypes de dépendance : «uses», «instance of», …

«instance of»

relation de dépendance

stéréotype

• Un stéréotype est un label qui permet d'apporter une précision supplémentaire à un élément de notation (classe, relation, …)


77

Heuristiques d’élaboration du modèle structurel

• Bien comprendre le problème • Faire simple • Bien choisir les noms • Bien expliciter les associations • Ne pas trop “généraliser” • Relire • Documenter

De nombreuses révisions sont nécessaires !

Modèle structurel


78

Modèle dynamique

Décrit les interactions entre objets et les changements au cours du temps

- Aspects temporels, comportementaux : Contrôle

- Stimuli des objets et leurs réponses


79

Événement et État

État d'un objet

valeurs de ses attributs et de ses liens au cours du temps un objet peut changer d'état

Événement

stimuli d'un objet vers un autre objet

Modèle dynamique


80

Modèle dynamique

• diagrammes de séquences

• diagrammes états-transitions

• diagrammes de collaboration

• diagrammes d'activités (non traités)


81

l’appelant soulève le combinéla tonalité est déclenchéel’appelant compose le numéro 6la tonalité s’arrêtel’appelant tape le chiffre 7l’appelant tape le chiffre 1l’appelant tape le chiffre 4l’appelant tape le chiffre 8l’appelant tape le chiffre 6l’appelant tape le chiffre 6l’appelant tape le chiffre 2le téléphone appelé commence à sonnerla tonalité de sonnerie commence dans le téléphone appelantl’appelé décrochele téléphone de l’appelé cesse de sonnerla tonalité de sonnerie cesse dans le téléphone appelantles téléphones sont connectésl’appelé raccrocheles téléphones sont déconnectésl’appelant raccroche

Scénarios

Exemple

Modèle dynamique


82

Diagrammes de séquences

Appelant : Personne :Ligne Téléphonique Appelé : Personne

l’appelant soulève le combiné

la tonalité est déclenchée

la tonalité s’arrête

l’appelant compose le numéro 6

l’appelant compose les numérosle téléphone appelé commence à sonnerl’appelant entend la sonnerie

l’appelé décroche

le téléphone de l’appelé cesse de sonnerla sonnerie cesse

connexion établieconnexion établie

connexion interrompue connexion interrompuel’appelé raccroche

l’appelant raccroche

Modèle dynamique


83

constructeursdestructeurs

sélecteursmodificateursitérateurs

Types Synchronisation

simple

synchrone

dérobant

minuté

asynchrone

Les messages

Modèle dynamique


84

Modèle dynamique

La ligne de vie :C1

« create »

Création par le message « create »

Activation de l ’objet qui exécute une opération op

Destruction par un autre objet

« destroy »

op


85

Diagrammes de collaboration

Vue globale des événements entre classes

Appelant: Personne

:Lignetéléphonique

Appelé:Personne

Modèle dynamique

1, 3, ..

2, 4

5, ...

6,..


86

Diagrammes d'États

Représentation graphique état et événement

• Graphe

Nœud ÉtatArc Transition nommées par événement

• Une séquence d'événements = chemin dans le graphe

Modèle dynamique


87

Événement

• pas de durée

• concurrence d'événements

• classes d'événements - sans attributs

- avec attributs départ vol (compagnie, num_vol, ville) a pour instances AirFrance vol 124 de Paris Alitalia vol 352 de Rome

Modèle dynamique


88

État

• abstraction des valeurs d'attributs et de liens d'un objet

• un état a une durée (intervalle de temps entre deux événements)

• spécifie la réponse à un événement

• état et événement sont duaux

un événement sépare deux états un état sépare deux événements

Modèle dynamique


89

Diagrammes d'États

Libre

Tonalité

En numérotation

En connexion

décroche

numérote

recherche réussie

Sonnerie

Connectée

Déconnectée

numéro existant

réponse appelé

raccrocheraccroché

Exempleincomplet

Modèle dynamiqueEtat initial


90

Diagrammes d'États

Transitions gardées

en création Ouvert Fermé

demande créationfermeture accomplie

En retrait En dépôt

Débiteur

fermeture

retrait (s) dépôt(s)

Créditeur[Solde >0] [Solde >0]

[Solde ≤0] [Solde ≤0]

Modèle dynamique


91

État 1faire : Activité 1

Événement 1 [Cond1] / Action1 (attrib) État 2

...

Opération Activité / Action

Modèle dynamique


92

Action opération instantanée, non interruptible,souvent utilisée pour faire des mises à jour de valeurs,attachée à une transition.

Envoyer un événement est une action

Activitéopération qui prend du temps, interruptible par un événement,perpétuelle ou finie,nécessairement attachée à un état.

Opération elle peut être attachée à une transition ou à un état. elle est exécutée en réponse à l'événement ou à l'état.

Modèle dynamique


93

Généralisation permet une meilleure structuration des diagrammes

d'étatsUn objet dans un état du diagramme général doitêtre dans un des états du diagramme imbriqué (relation ou entre les états)

E1

E2

E5

E4E3

E6

Modèle dynamique


94

Agrégation une classe "agrégat" aura un état défini par l'agrégation des états de ses composants.

Agrégation concurrente (relation et)

Modèle dynamique

Ecomp1 Ecomp2


95

Heuristiques d’élaboration du modèle dynamique • Utiliser les scénarios pour commencer à construire les diagrammes d'état

• Ne construire un diagramme d'état que pour les classes au comportement temporel significatif

• Contrôler la cohérence

• Utiliser des diagrammes structurés

Modèle dynamique


96

Modèle d ’implémentation

Les packages

Un package ou sous-système est un regroupement logique de classes, associations, contraintes ..

Un sous-système est généralement défini par les services qu ’il rend

Les liens entre sous-systèmes sont des liens de dépendance

Les « packages » servent à structurer une application Ils sont utilisés dans certains LPO (Java) ce qui assure une bonne « traçabilité » de l ’analyse à l ’implémentation


97

Modèle d ’implémentation

Les packages

Classes avec fort couplage « sémantique »

Liens de dépendance


98

Plan

• De l ’analyse à la réalisationdu modèle objet ….. à la programmation objet du modèle objet …… aux BD


99

Du modèle objet ... à la programmationDu modèle objet ... à la programmation

Classes

Attributs, Opérations ------> Champs, Méthodes

Accesseurs L/E

Constructeurs, Destructeurs


100

Du modèle objet ... à la programmationDu modèle objet ... à la programmationClasses

- adresse : String = 'adresse inconnue'- numeroINSEE[6] : Integer

# changeAdresse(nouvelleAdresse : String)+ cotisationAJour() : Boolean

Adhérent

note (peut contenir un complément de description,

un commentaire, …)

type d'attribut

valeur initiale

type de paramètretype du résultat

de l'opération

privé

protégé

public

adhérent de labibliothèquevaleurs multiples


101

Du modèle objet ... à la programmationDu modèle objet ... à la programmationClasses

Classes ------> classes abstraites vs classes concrètes

C++ méthodes virtuelles pures

Java Interfaces

Héritage par réalisation


102


Proposer un service et réagir aux messages

Opérations

Données

MessagesEncapsulation

Objet


103


Encapsulation

Consensuel

privé ... implémentationpublic ... spécification

En pratique

à chaque langage ses particularismes

Smalltalk. attributs privés, méthodes publiques, ...Java. package, protected ...C++. friends, protected, protection sur le lien d’héritage, ...

Quelle philosophie adopter ?


104


Associations

PERSONNE ADRESSE

nom....

N°RueCPVille

1 1a

Class PERSONNE{Private : string nom;ADRESSE adr;....}

rien de spécial dans ADRESSE

Attrribut complexe


105


Associations

PERSONNE COMPTE

nom....

N°Type

1 0..npossède

Class PERSONNE{Private :

string nom;list <COMPTE> comptes;....}

Class COMPTE{Private :

PERSONNE possesseur;....}

Conteneur

Référence


106


Associations

PERSONNE BIBLIOTHEQUE

nom....

nom0..nadhère->

Class PERSONNE {Private : string nom;....}Class BIBLIOTHEQUE {Private : ....}

Class ADHESION{Private :

PERSONNE adhérent;BIBLIOTHEQUE biblio;DATE dateadhésion;....}

Réification

0..n

date adhésiontype adhésion (mensuelle, annuelle)


107


Héritage

• adéquation des deux relations

• représentation et traitement des conflits

• spécialisation des attributs

• représentation de la surcharge et du masquage

• utilisation de l’héritage à des fins d’implémentation ?

Implémentation de la relation de spécialisation par l’héritage,quelques problèmes ....


108


Héritage : adéquation des deux relations

Spécialisation multiple

Flot

good()eof() ...

FlotEcriture

écrire(blocOctets)...

Flot-Lecture

lire(nbOctets)...

FlotLectureEcriture


109

Cas de Java : héritage simple pour l’implémentation, multiple pour les interfaces ... côté classes, ...les méthodes de FlotLecture et FlotEcriture doivent être réécrites dans FlotLectureEcriture


Héritage : adéquation des deux relationsinterface Flot

interface FlotEcritureinterface FlotLecture

interface FlotLectureEcritureclasse Flot

classe FlotLecture

classe FlotLectureEcriture

classe FlotEcriture

extendsimplements


110


Spécialisation/Généralisation .... multiples

Conflit portant sur le nom des propriétés

Il y a clairement deux propriétés

Objet

couleur (rouge, vert ...)

Elément de jeu

Pion DéCarte à jouer

couleur (coeur, trèfle, ...)


111


Spécialisation/Généralisation .... multiples

Conflit portant sur les valeurs d’une propriété

Le mulet n’a qu’une propriété couleur, mais quelle sera sa valeur ?

Objet

couleur (rouge, vert ...)

Jument Ane

Mulet


112


Héritage : représentation et traitement d’un conflit de nom

Smalltalk JavaC++

Désignation expliciteObjet::CouleurCarteAJouer::Couleur

Donner deux nomsdifférents

pas d’accès possibleà couleur d’objetautre qu’avec “super”(dans les méthodes)

mieux vaut donnerdeux noms différents


113


Héritage : spécialisation des attributs

Animal

nourriture (végétale, animale, minérale)

Herbivore

nourriture (végétale)

Relation

ensemblesImpliqués > 1

RelationBinaire

ensemblesImpliqués = 2

Aucune représentation, ni en C++, ni en Smalltalk, ni en Java

Seule issue : vérification des contraintes dans les méthodes ...


114


Héritage : surcharge et masquage

Masquage, (redéfinition)coexistence de méthodes de même nom dans des classes comparables

Fenêtre

FenêtreAvecBord FenêtreAvecTitre

affiche

affiche affiche

Figure

affiche

Surchargecoexistence de méthodes de même nom dans des classes différentes


115


Héritage : masquage

C++ et Java masquage seulement si les signatures sont strictement identiques,on ne peut pas représenter directement :

Magnitude

<(Magnitude)

Time

<(Time)

heureminiutesecondes

Date

<(Date)

jourmoisannée


116


Héritage : à chacun sa surcharge

Personne

Princesse

habiller(Vêtement)habiller(Vêtement, Chaussure)

habiller(Vêtement, Bijou)

VêtementChaussureBijou

QuiSePorte

En Java : correctement interprété comme de la surchargeEn C++ : habiller(Vêtement, Bijou) cache les deux autres


117


Héritage : ... l’utiliser pour des raisons d’implémentation ?

Liste

ajoutFin

Pile

pushpoptop

A éviter dans tous les cas ...même si les livres en sont pleins ...


118


Vers la programmation : ... à partir du modèle dynamique (diagrammes de séquence, de collaboration, etc.)

:C2« create »

Op1

:C1:C3

Op 2

Op 3


119

Persistance• Classes vs Types

persistants vs éphémères

• Points d’entrée (racine de persistance)

• Regroupements

Du modèle objet ... aux BDDu modèle objet ... aux BD

Adéquation aux BD « objet »


120

LDD, LMD, L Hôte• LDD, LMD, L Hôte équivalents LPO

• Langage de requête “like” SQL

• Transactions


Adéquation aux BD « objet »


121

Adéquation aux BD « classiques »

Traduction

comme précédemment

d. structurels --> schémas

d. dynamiques --> requêtes et traitements applicatifs divers

Mais règles de « passage »



122

Classes

AttributsAjout de l ’identifiant

Schéma relationnel

ADRESSE

N°RueCPVille

Attribut Domaine Non Null

Id_adresse Identifiant OuiN° Entier NonRue String(30) Non…..

Schéma AdresseClé primaireId_adresse



123

Associations

PERSONNE ADRESSE

nom....

N°RueCPVille

1 1a


Id_personne Identifiant OuiNom String(35) OuiId_adresse Identifiant Oui

Schéma PersonneClé primaireId_personne

Clé étrangèreId_adresse



124

Associations

PERSONNE COMPTE

nom....

N°Type

1 0..npossède


Id_personne Identifiant OuiNom String(35) OuiNO Identifiant Oui


Clé étrangèreNO



125

Associations

PERSONNE BIBLIOTHEQUE

nom....

nom0..nadhère->0..n

date adhésiontype adhésion (mensuelle, annuelle)


Id_personne Identifiant OuiId_bibliothèque Identifiant OuiDate_adhésion Date OuiType_adhésion String(10) Oui

Schéma AdhèreClé primaireId_personneId_bibliothèqueDateType



126

Spécialisation

PERSONNE

nom....

ETUDIANT

num....

ENSEIGNANT

grade....

Plusieurs choix

- « aplatir vers le haut »


- « aplatir vers le bas »Schémas Etudiant, EnseignantClé primaireId_personne

- conserver les niveaux



127

Processus de développement

Quatre phases

• Analyse

• Conception système

• Conception objet

• Implémentation

Démarche

Centrer l'effort sur l'analyse Processus itératif plutôt que séquentiel


128


Objectifs de l'analyse

• Obtenir une description initiale du problème et du système à réaliser (à partir des USE CASE)

• Construire les modèles objet (structurel) et dynamique

• Vérifier et itérer sur les modèles


129

Conception système

Décrire l'architecture générale du système

• Organiser en sous systèmes

• Grouper les objets en tâches concurrentes

• Décider des communications inter-processus, du stockage des données, de l'implémentation du modèle dynamique



130

Construire l'architecture générale du système

Un sous-système est un ensemble de composants qui englobe des aspects similaires :- fonctionnalités semblables- même caractéristiques techniques- même emplacement physique

Un sous-système fournit des services aux autres sous-systèmes.



131


Chaque sous-système doit être le plus autonome possible.

Un sous-système doit pouvoir être conçu indépendamment.

Composants ?



132


Le système peut être décomposé en couches et/ou en partitions


Gestionnaire base de données

Objets métier

BatchIHMRobustesseSécuritéRapiditéRépartitionMulti-tâches


133

Conception objet


Transposer les modèles d ’analyseEcriture des algorithmes

Il s ’agit de combiner modèles objet et dynamique…. En tenant compte des choix de la conception système

Documents

Formalismes et méthodes Objet 1 Méthodologie objet Survol du formalisme UML T. Libourel [email protected] Avec la complicité de M Huchard