Autour des objets

1
Autour des objets

• T. Libourel - P. Bommel
• libourel_at_lirmm.fr - bommel_at_cirad.fr

2
PLAN

• Introduction
• Modèles mathématiques versus modèles objets
• Systèmes et objets
• Pourquoi des méthodes ?
• Approche objet
• Atouts
• Historique
• Concepts objet et formalisme UML
• Concepts généraux
• Modèle fonctionnel
• Modèle structurel
• Modèle dynamique
• Discussion

3
PLAN

• Introduction
• Modèles mathématiques versus modèles objets
• Systèmes et objets
• Pourquoi des méthodes ?
• Approche objet
• Atouts
• Historique
• Concepts objet et formalisme UML
• Concepts généraux
• Modèle fonctionnel
• Modèle structurel
• Modèle dynamique
• Discussion

4
Modèles mathématiques versus modèles objets

• L'approche mathématique
• Représentation de types, de variables et de
  fonctions.
• Culture scientifique
• L'approche objet
• Représentation abstraite d'entités ayant une
  existence matérielle (arbre, personne) ou
  virtuelle (sécurité sociale, compte bancaire,
  ...).
• Culture implicite et philosophique
• Confluent de plusieurs disciplines informatiques

5
Systèmes et objets

• 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 linterface avec le métier (domaine
  dapplication)

6
Systèmes et objets

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

7
Pourquoi des méthodes ?
Rien ne dicte a priori comment modéliser un
système de manière pertinente

• Besoin de méthodologie

Outils Informatiques
Entreprise
8
Pourquoi des méthodes ?

• 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
Pourquoi des méthodes ?

• Démarche qui distingue les étapes du
  développement dans le cycle de vie du logiciel
• Modularité, réduction de la complexité,
  réutilisabilité, abstraction
• Un formalisme de représentation qui facilite la
  communication, lorganisation et la vérification
• Production de documents (modèles) qui facilitent
  les retours sur conception et lévolution des
  applications

10
PLAN

• Introduction
• Modèles mathématiques versus modèles objets
• Systèmes et objets
• Pourquoi des méthodes ?
• Approche objet
• Atouts
• Historique
• Concepts objet et formalisme UML
• Concepts généraux
• Modèle fonctionnel
• Modèle structurel
• Modèle dynamique
• Discussion

11
Atouts

• Universalité de lObjet
• la notion dobjet, plus proche du monde réel,
  est compréhensible par tous et facilite la
  communication entre tous les intervenants dun
  projet.
• Omniprésence technique de lObjet
• dans les langages de programmation, les bases de
  données, les interfaces graphiques, ... et les
  méthodes danalyse et de conception.

12
Historique

• Plus de 50 méthodes objet sont apparues durant
  la période 90-95 Booch, Classe-Relation, OMT,
  OOA, OOD, OOM, OOSE...
• Grady Booch OOD, BOOCH'93 (Société RATIONAL)
• 1987 pour ADA,
• 1990 générale                        
• James Rumbaugh OMT 1990-1991
• "Object Modeling Techniques"
• General Electric
• Ivar Jacobson Objectory 1992,
• Ericsson,
• suite de OOSE "Object Oriented Software
  Engineering"
• Regroupement de BOOCH-OMT puis Objectory

13
Historique

• Recherche dun 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.
• UML (Unified Modeling Language)

http//www.omg.org
14
PLAN

• Introduction
• Modèles mathématiques versus modèles objets
• Systèmes et objets
• Pourquoi des méthodes ?
• Approche objet
• Atouts
• Historique
• Concepts objet et formalisme UML
• Concepts généraux
• Modèle fonctionnel
• Modèle structurel
• Modèle dynamique
• Discussion

15
Concepts généraux

• Un modèle est une représentation abstraite
  dune 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 )

16
Concepts généraux
Les modèles d'UML
modèle des classes
statique modèle des états
dynamique des objets modèle des cas
d'utilisation besoins utilisateur modèle
d'interaction scénarios et
flots de messages modèle de réalisation
unités de travail modèle de déploiement
répartition des processus
17
Concepts généraux
La perception des modèles Les vues graphiques
(diagrammes )
diagrammes de classes diagrammes
d'objets diagrammes de séquences diagrammes de
collaboration diagrammes états-transitions diagra
mmes d'activités diagrammes de cas
d'utilisation diagrammes de composants diagrammes
de déploiement
18
Concepts généraux
Définir une architecture . divers points de
vue sur le système
Vue   structurelle
Vue Implémentation
Vue Cas d utilisation
Vue Architecture (déploiement)
Vue dynamique
lt------- Logique Physique ------gt
19
Concepts généraux
Processus incrémental
Conception
Analyse
Réalisation
Tests - Maintenance
Même formalisme lors de toutes les phases du
cycle de vie
20
Modèle fonctionnel
Les   USE CASE 

• Modèles descriptifs du point de vue des
  utilisateurs
• Scénarios fonctionnels
• Focus
• La manière dutiliser le système

21
Modèle fonctionnel

• Deux concepts
• Acteur
• Use case

Acteur (rôle 2)
22
Modèle fonctionnel

• Les cas dutilisation peuvent être liés par des
  relations
• dutilisation  use  (décomposition)
• de raffinement  extend  (traitement
  dexceptions)

Acteur (rôle 2)
 use 
 extend 
23
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.

24
Modèle structurel
Les objets
Objets du monde réel
Objets informatiques
Comportement visible
État Interne caché
25
Modèle structurel
Objet Etat évolue au cours du
temps Comportement actions et
réactions Identité essence
Comportement influe sur l'état Etat reflète les
comportements passés
26
Modèle structurel
BD
Deux objets ou instances
Luc
Système
Alain
Discipline
Sophie
Professeur
27
Modèle structurel

• Première abstraction
• Une classe peut être vue
• la description en intension 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

28
Modèle structurel
Classe Attributs (propriétés)
Instance Valeurs d'attributs (État)
Voiture
titine Voiture
type 205 Peugeot rouge
 Est-instance-de 
type string marque string couleur string
29
Modèle structurel
nom de la classe
attributs
Voiture
type string marque string couleur string
opérations
repeindre(c Couleur) déplacer (d longueur)
30
Modèle structurel

• Représentation graphique  les boites  (à
  différents niveaux de détail)
• Les types sont optionnels et ne figent pas les
  choix d'implémentation
• La description des opérations sera complétée
  dans les phases de conception

31
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).

32
Modèle structurel
Association / Lien (analogie Classe /
Instance)
Pays
Ville
a-pour-capitale
nom
nom
Association
a-pour-capitale
Pays nomFrance
Ville nom Paris
Lien
33
Modèle structurel
Association en général binaire (degré 2) mais
..
nom d'association
Adhérent
Exemplaire
lire
association ternaire
association binaire
DispositifDeLecture
34
Modèle structurel
Multiplicité et rôles d'une association
emploie
employeur
employé
Personne
Société
1..

nom date de nais. nSS adresse
nom adresse
travaille-pour
chef
0..1
encadre
1..
travailleur
35
Modèle structurel
Multiplicité
exactement 1
1
Classe
au plus 1
0..1
Classe
aucun, 1 ou plusieurs (défaut)
0..
Classe
1..
au moins 1
Classe
2..4
de 2 à 4
Classe
2,4
Classe
2 ou 4
36
Classe association
Modèle structurel
Possède-des-actions
Entreprise
Personne
1..

nom date de nais. adresse
capital
nom adresse
actionnaire
PossessionLigne de portefeuille
quantité
37
Modèle structurel
Classe association
Autorisé sur
Utilisateur
Station de travail
1..
1..
nom
nom
Autorisation
priorité droits
1..
répertoire de rattachement
Répertoire
38
Modèle structurel
D autres  abstractions 

• associations particulières
• (composition / agrégation)
• spécialisation / généralisation

39
Modèle structurel
Composition
Association particulière Tout /partie
Fenêtre
0..2
Barre Ascenseur
Barre titre
Fond
Frontière
2
Titre
Bouton Ferm
Indicateur
Flèche
40
Modèle structurel
Agrégation
Sémantique Collection/Élément
Pays
1
Forêt
1..n
1
Région
1
1..n
Arbre
1..n
Département
41
Modèle structurel
Composition / Agrégation
Contraintes - Exclusivité / Partage -
Dépendance / Indépendance Propagation / Diffusion
42
Modèle structurel
Généralisation / Spécialisation

• Mécanismes dinfé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

43
Modèle structurel
Généralisation / Spécialisation
Personne
nom adresse
disjoint
Enseignant
grade adresse
enseigner
44
Modèle structurel
Généralisation / Spécialisation
Équipement
Type d'équipement
...
Réservoir
Pompe
Échangeur
Type de pompe
Type de réservoir
...
...
Pompe Cent.
Pompe Imm.
Réservoir Press.
45
Modèle structurel
Généralisation / Spécialisation multiple
Véhicule
Véhicule aquatique
Véhicule terrestre
Auto
Véhicule amphibie
Bateau
46
Modèle structurel
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

47
Modèle structurel
Généralisation / Spécialisation

• Une sous-classe hérite des descriptions de sa
  super-classe
• 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 .

48
Modèle structurel
Les contraintes

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

49
Modèle structurel
Les contraintes Exemples de contraintes sur
associations
membreDe
Chemin
Personne
Comité


subset


1
ordered
contrainte entre 2 associations
1..
contrainte sur extrémité d'association
Arête
50
Modèle structurel
Les contraintes Exemple de contraintes à
différents niveaux
actif passif
contrainte sur classe
subordonné
employeur
Personne
Société

1..
0..1
0..1
actif Real value ? 0 passif Real
Personne.employeur Personne.chef.employeur
chef
ltdirige
contrainte sur attribut
contrainte sur 2 associations
51
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
52
Modèle dynamique

• diagrammes de collaboration
• diagrammes de séquences
• diagrammes états-transitions
• diagrammes d'activités (non traités)

53
Modèle dynamique
La communication
Systèmes informatiques Société d'objets
travaillant en synergie pour réaliser les
fonctions de l'application
Communication
Client
Acteur
Serveur
message
54
Modèle dynamique
Les messages
Types
Synchronisation
simple synchrone dérobant minuté asynchrone
constructeurs destructeurs sélecteurs modificateu
rs itérateurs
55
Modèle dynamique
Diagramme de collaboration
2 M2
B
1 M1
5 M5
4 M4
A
C
6 M6
message
3 M3
56
Modèle dynamique
Diagramme de séquence
C
B
A
M1
M2
M3
M4
M5
M6
57
Modèle dynamique
La ligne de vie
 create 
C1
op
Création par le message create
Activation de lobjet qui exécute une opération
op
destroy
Destruction par un autre objet
58
Modèle dynamique
É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

59
Modèle dynamique
Diagramme d état
Événement 1 Cond1 / Action1 (attrib)
État 1 faire Activité 1
État 2 ...
É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
60
Modèle dimplé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 quil 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

61
Modèle dimplémentation
Les packages
Liens de dépendance
Classes avec fort couplage  sémantique 
62
PLAN

• Introduction
• Modèles mathématiques versus modèles objets
• Systèmes et objets
• Pourquoi des méthodes ?
• Approche objet
• Atouts
• Historique
• Concepts objet et formalisme UML
• Concepts généraux
• Modèle fonctionnel
• Modèle structurel
• Modèle dynamique
• Discussion

63
Discussion
Des bienfaits de l encapsulation .
Données
Encapsulation
Messages
Opérations

• Proposer un service et réagir aux messages

64
Discussion
La méta-modélisation
Langage pour spécifier tout métamodèle
Meta-Class, Meta-Attribut, etc
Meta-Meta Modèle
Class, Attribut, etc
Langage pour spécifier un modèle
Meta-Modèle
Parcelle, Surface, etc
Langage pour spécifier un domaine dinformation
Modèle
A120, 50, etc
Définition spécifique dun domaine
Objets utilisateur
65
UML et Merise
Discussion

• UML n est pas une méthode comme Merise
• Ne dit rien sur le processus de mise en uvre
  chaque société peut proposer son processus
• RUP  Rational Unified Process  (Rational)
• EAI (Valtech)
• MEGA Process (MEGA)
• UML cible toute application informatique, alors
  que Merise cible les SI

66
Les outils
Discussion
Modèles UML, ...
AGL
Schéma de la base relationnelle ou objet
re-engineering
SGBD-R ou SGBD-OO
Langages JAVA, C, ..
67
Discussion

• Outil de dialogue
• langage de représentation des modèles
• graphique et simple
• formel et normalisé (OMG)
• Outil ouvert
• Indépendant des langages de programmation
• Pas un processus d'élaboration des modèles
• Adaptable (stéréotype)

68
Livres UML (1)

• Booch Grady, Rumbaugh James, and Jacobson Ivar,
  The Unified Modeling Language User Guide,
  0-201-57168-4, Addison Wesley, Fall 1998, traduit
  Le guide de l'utilisateur UML, Eyrolles 2000.
• Jacobson Ivar, Booch Grady and Rumbaugh James,
  The Unified Software Development Process,
  0-201-57169-2, Addison Wesley, Fall 1998, traduit
  Le processus unifié de développement logiciel,
  Eyrolles 2000.
• Rumbaugh James, Jacobson Ivar, and Booch Grady,
  The Unified Modeling Language Reference Manual,
  0-201-30998-X, Addison Wesley, Fall 1998

69
Livres UML (2)

• Conallen Jim, Concevoir des applications Web avec
  UML, Eyrolles , 2000.
• Douglass Bruce Powell, Doing Hard Time
  Developping Real-Time Systems with UML, Addison
  Wesley, 1999.
• Eriksson , UML Toolkit, Wiley, 1997
• Fowler Martin, UML Distilled, Applying the
  Standard Object Modeling Language Addison Wesley,
  1997
• Kettany N et al, De Merise à UML,Eyrolles , 1998
• Larman Craig, Applying UML and Patterns,Prentice
  Hall, 1998
• Lee R, Tepfenhart W, UML et C, Simon et Schuste
  , 1998
• Lopez N, Intégrer UML dans vos projets, Eyrolles,
  1997
• Muller Pierre-Alain, Modélisation objet avec UML,
  Eyrolles, 1997
• Roques Pascal, Vallée Franck, UML en action,
  Eyrolles, 2000.
• Roques Pascal, UML par la pratique, Eyrolles,
  2001.
• Schmuller Joseph, Teach Yourself UML in 24 Hours,
  Sams Publishing, 1999
• Texel Williams, Uses cases combined with
  Booch/OMT/UML, Prentice Hall, 1998