Le document présente une introduction à la modélisation par objets pour les étudiants, abordant des questions et des concepts clés de la modélisation avec UML, ainsi que les défis du développement logiciel et l'évolution vers des méthodes plus abstraites. Il traite des problèmes liés à la complexité croissante et à la gestion des évolutions dans les systèmes logiciels, en soulignant l'importance de l'encapsulation et de la modularité. Enfin, le document mentionne des exemples historiques et contemporains illustrant les enjeux liés à la maintenance et à la qualité des logiciels.

1. ACSI
Modélisation par Objets
À destination des étudiants du
2e année IUT Nice-Sophia Antipolis
Mireille Blay-Fornarino
IUT Nice-Sophia Antipolis
blay@unice.fr
http://www.polytech.unice.fr/~blay
Site web du module :
http://anubis.polytech.unice.fr/iut/
1

2. Modélisation
par
Objets
2

3. Modélisation
par
Objets
2

4. Modélisation
par
Objets
2

5. Parlons-nous le même langage ?
Modélisation & 0bjets
Quiz
Sur la base du
Essentials of Visual Modeling with UML 2.0
Module 3a: VM Quiz Show
3
IBM

6. Question
Un modèle. . .?
A. doit être structurel et comportemental.
B. est inutile si les membres d’une équipe savent
programmer
C. est une simplification de la réalité.
D. est une excuse pour retarder le développement
Réponse :
4

7. Question
Pourquoi modéliser? Pour ...
A. Aider à visualiser un système
B. Documenter nos décisions
C. Comprendre et cerner les besoins fonctionnels et
techniques
D. Faciliter la planification
E. Toutes ces réponses
Réponse :
5

8. Question
A votre connaissance, à partir d’un modèle,
avec des outils, on peut. . .?
A. obtenir une bonne note
B. produire de la documentation
C. produire des squelettes de code
D. produire du code
E. valider une spécification
F. simuler un système
G.autre
Réponse :
6

9. Question
La modélisation s’arrête quand ?
A. on commence à développer
B. le prof n’est plus là pour l’exiger
C. tout le système a été modélisé
D. on a fini de représenter la réalité
E. on n’a plus d’argent
F. le système s’arrête
Réponse :
7

10. Question
La technologie objet est . . . ?
A. Une nouvelle théorie cherchant à se faire accepter.
B. Un nouveau langage dynamique inventé par Grady
Booch.
C. basée sur des principes de décomposition
fonctionnelle
D. Un ensemble de principes guidant le développement
du logiciel
E. faire compliqué quand on peut faire simple
Réponse :
8

11. Question
Un objet . . . ?
A. a un état défini par la valeur de ses attributs
B. a une identité qui doit correspondre à une clef dans
une BD
C. est identifié par une référence
D. peut recevoir des messages
Réponse :
9

12. Question
Pour communiquer avec un objet,
je ....?
A. lui envoie des messages
B. le stocke dans une base de données
C. modifie la valeur de ses attributs
Réponse :
10

13. Question
Une classe . . . ?
A. est une encapsulation d’un objet;
B. représente la hiérarchie d’un objet;
C. représente un ensemble d’objets;
D. est une instance d’un objet;
E. est une définition abstraite d’un object.
Réponse :
11

14. Question
Une classe définit . . . ?
A. les données portées par les objets
B. les comportements des objets
C. la manière de créer un objet
Réponse :
12

15. Question
Pour créer un objet, je dois ....?
A. demander à un autre objet de le créer
B. demander à sa classe
C. demander à une base de données
D. lui parler
E. lui envoyer un message
Réponse :
13

16. Question
Soit la méthode findAllStudents(), elle est définie
comme :
A. une méthode de Student :
appel : Student s; s.findAllStudents();
B. une méthode de la classe Course :
appel : Course c; d.findAllStudents();
C. une méthode «static» de Student :
appel : Student.findAllStudents();
D. autre
14
Réponse :

17. Question
L’encapsulation . . . ?
A. est souvent vue comme un moyen de cacher les
données dans des entités logicielles
B. empêche les codes de s’abîmer
C. facilite les modifications d’implémentations
D. engendre une gestion difficile de l’évolution
Réponse :
15

18. Question
Quelle phrase traduit le mieux la
Généralisation . . . ?
A. “Est une partie de”
B. “Est une sorte de”
C. “Est un réplica de”
D. “Est un héritage de”
Réponse :
16

19. Question
L’héritage . . . ?
A. permet de déclarer des propriétés une fois et
que les sous-classes les connaissent.
B. offre la possibilité de toucher dans l'âge adulte
les sommes qu'on vous a refusées dans votre
jeunesse.
C. améliore la productivité
D. améliore la maintenance
E. accroît la complexité
Réponse :
17

20. Intro. Intro. UML Démarche
Plan
Problèmes du développement logiciel
Histoire brève jusqu’aux limites de la programmation structurée
Du bidouillage au Génie logiciel
Introduction à UML
Un peu d’histoire
Survol
De Merise à UML (plus tard)
Présentation du Module : démarche générale
09/10 18

21. I. Quels sont les problèmes
du développement logiciel?
19

22. I. Quels sont les problèmes
du développement logiciel?
Un peu d’histoire
20

23. Intro. ✓histoire Intro. UML Démarche
La gestion progressive de la complexité
Premiers programmes en langage machine
 Les premiers programmes, écrits en langage machine,
dépendaient fortement de l'architecture des ordinateurs
utilisés.
sub $sp, $sp, 4
sw r,0($sp)
09/10 21

24. Intro. ✓histoire Intro. UML Démarche
La gestion progressive de la complexité
Programmation en langages évolués
 Lorsque le nombre d'architectures différentes a augmenté, un premier
effort a été produit pour séparer les concepts manipulés dans
les langages de leur représentation dans la machine et a abouti
à la création de langages comme FORTRAN.
PROGRAM DEGRAD
!
! Imprime une table de conversion degrés -> radians
! =================================================
!
! Déclaration des variables
INTEGER DEG
REAL RAD, COEFF
!
! En-tête de programme
WRITE ( *, 10)
10 FORMAT (' ',20('*') / &
& ' * Degres * Radians *' / &
& ' ', 20('*') )
!
! Corps de programme
COEFF = (2.0 * 3.1416) / 360.0
DO DEG = 0, 90
RAD = DEG * COEFF
WRITE ( *, 20) DEG, RAD
20 FORMAT (' * ',I4,' * ',F7.5,' *')
END DO
!
! Fin du tableau
WRITE ( *, 30)
30 FORMAT (' ',20('*') )
!
! Fin de programme
STOP
09/10 22 END PROGRAM DEGRAD

25. Intro. ✓histoire Intro. UML Démarche
La gestion progressive de la complexité
Méthode d’analyse par décomposition
 La complexité croissante des programmes a de nouveau suscité un effort
pour mieux structurer les programmes (abandon du goto et de la
programmation spaghetti)
 Les méthodes d'analyse consistait alors à «diviser pour mieux régner»,
i.e. à découper les tâches en modules indépendants.
 Niklaus Wirth va plus loin : les programmes sont la «somme» d'une
structure de données et d'un ensemble distinct d'algorithmes chargés de
les manipuler.
➡ La programmation structurée étaient alors synonyme de
programmation dirigée par les traitements.
function ConstruitPhrase(phrase:string):string;
var s : string;
begin
readln(s);
ConstruitPhrase:=phrase+', '+s;
end;
var
Phrase : string;
begin
Phrase:=''; {initialiser à chaîne vide}
{premier mot}
writeln('Entrez un mot :');
09/10 23 Phrase:=ConstruitPhrase(Phrase);

26. Intro. ✓histoire Intro. UML Démarche
La gestion progressive de la complexité
L’explosion des besoins
 Le coût du matériel informatique a fortement décru et ce matériel est devenu
un bien de consommation courant (tant dans des entreprises et des universités
que chez les particuliers).
 La clientèle s'est diversifiée, les besoins ont explosé.
09/10 24

27. Intro. ✓histoire Intro. UML Démarche
Limites de la programmation structurée
La diffusion de la structure des données
dans le code
 La programmation structurée nécessite de faire des hypothèses sur les
données à traiter. La structure physique des données à traiter est
diffusée dans une part importante du code.
 Une simple modification des exigences des utilisateurs ou une
modification des données peut entraîner d'importantes modifications au
niveau des codes chargés de les traiter.
 Par exemple, en 1982, les postes américaines sont passés du code
postal à 5 chiffres à celui à 9 chiffres. Beaucoup de programmes
gérant des fichiers d'adresses ont dû être récrits à grands frais.
09/10 25

28. Intro. ✓histoire Intro. UML Démarche
Et après
Encapsuler, assembler, réutiliser
Pour répondre à ces besoins croissants, la
programmation a connu une évolution et une
montée en abstraction encore plus importante :
09/10 26

29. Intro. ✓histoire Intro. UML Démarche
Et après
Encapsuler, assembler, réutiliser
Pour répondre à ces besoins croissants, la
programmation a connu une évolution et une
montée en abstraction encore plus importante :
Objets, Composants, Services, Composants as
Services, Génération des codes à partir de modèles,
Frameworks, Usines logicielles, ....
09/10 26

30. Intro. ✓histoire Intro. UML Démarche
Et après
Encapsuler, assembler, réutiliser
Pour répondre à ces besoins croissants, la
programmation a connu une évolution et une
montée en abstraction encore plus importante :
Objets, Composants, Services, Composants as
Services, Génération des codes à partir de modèles,
Frameworks, Usines logicielles, ....
Mais le plus important des changements de
«méthodes» de développement...
09/10 26

31. I. Quels sont les problèmes
du développement logiciel?
Du bidouillage au génie logiel
27

32. Intro. Intro. UML Démarche
Problématique du génie logiciel
➡ Programming-in-the-Small
Problème de la qualité interne d'un composant
➡ Programming-in-the-Large
Faire face à la construction de systèmes de plus en plus gros :
non spécifique au logiciel, mais aggravé par sa “mollesse”.
Problème de gestion de la complexité, de communication, etc.
Maîtrise du processus de développement: délais, coûts, qualité.
Programming-in-the-Duration
Problème de la maintenance corrective et évolutive.
Notion de ligne de produits.
Pr. Jean-Marc Jézéquel
09/10 28

33. Intro. ✓Prog. Small ✓Validation Intro. UML Démarche
Programming-in-the-Small
Problème de la validité du logiciel
Acquérir une valeur positive n
Tant que n > 1 faire
si n est pair
alors n := n / 2 Prouver que le prog. termine pour tout n?
sinon n := 3n+1 -> Indécidabilité de certaines propriétés
Sonner alarme;
Recours au test
– ici, si machine 32 bits, 2^31 = 10^10 cas de tests
– 5 lignes de code => 10 milliards de tests !
Pr. Jean-Marc Jézéquel
09/10 29

34. Intro. ✓Prog. Small ✓Validation Intro. UML Démarche
Programming-in-the-Small
Produire des programmes prouvés
C’est possible…
On peut construire des programmes de tel manière qu’ils
soient prouvables
En partie automatisable (Atelier B, etc.)
Outils spécifiques
…mais coûteux
Preuve au moins aussi complexe que le code
Autant de chances de se tromper dans la preuve…
En pratique :
Réservé à des (petits) sous-systèmes (très) critiques
Recours aux tests pour le reste
09/10 30

35. Intro. ✓Prog. Small ✓Validation Intro. UML Démarche
Programming-in-the-Small
Syntaxe JML Préconditions :
/** Ce qui doit être satisfait
* @param double x réel positif pour appeler la méthode
* @result double racine carrée de x
*/
/*@
@ requires x >= 0.0 ; Assertions
@ ensures x == result * result ;
@*/
public static double sqrt(double x) {
Postconditions :
Ce qui est satisfait en cas de retour
normal
Invariant =
propriété toujours vraie quelque soit l’état du système
09/10 31

36. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche
Programming-in-the-Large
Gérer la complexité due à la taille
a) c)
b) d)
Si l'automobile avait suivi le même développement que l'ordinateur, une Rolls-Royce coûterait aujourd'hui 100$, pourrait rouler un
million de kilomètres avec un litre d'essence, et exploserait une fois par an en tuant tout le monde à bord. Robert Cringely.
Pr. Jean-Marc Jézéquel
09/10 32

37. Intro. Intro. UML Démarche
Exemple Windows Vista …
65 millions de lignes de code, 6 années de développement,
9000 développeurs (54 000 années développeurs)
http://www.clubic.com/article-66145-1-microsoft-windows-vista-rtm-dossier.html
… sur les vingt années d'existence de Windows, Vista aura été le système d'exploitation
dont le cycle de développement fut le plus long ! Et pour cause, puisqu'après avoir
démarré le développement de Longhorn en 2001, Microsoft a du remettre à plat
l'intégralité du projet en 2004, réalisant alors que celui-ci était par trop complexe et
tentaculaire. En repartant de zéro, Microsoft a entièrement révisé son cahier des charges
en supprimant au passage certaines fonctionnalités pourtant très attendues de Vista ; on
pense bien sûr au système de fichiers WinFS qui est ainsi tombé purement et simplement
aux oubliettes. C'est au maître d'œuvre de Vista, Jim Allchin, que l'on doit cette décision,
certainement très difficile à prendre vu ses implications pour l'époque. Lorsque, fin 2004,
les équipes à la tête de Microsoft décident de repartir de zéro, c'est pratiquement tout le
travail des 9 000 développeurs mobilisés sur Windows Vista qui est à recommencer…
09/10 33

38. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche
Programming-in-the-Large
Augmentation exponentielle de la taille du logiciel
09/10 34

39. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche
Programming-in-the-Large
Echecs logiciels
Premier vol d’Ariane 5 (1996)
ATT (1990):
interruption du service téléphonie
pendant 5 heures à l'Est des Etats-Unis.
Aéroport de Denver, 1993-1995:
logiciel de suivi des bagages,
coût 3 milliards de $, retard de 18 mois.
National Cancer Institute, Panama
City,2000 : Logiciel non adapté aux
médecins => 8 morts, 20 personnes Out of range
“surexposées”.
etc., etc.
09/10 35

40. Intro. ✓Prog. Large ✓Diviser Intro. UML Démarche
Gestion de la complexité due à la taille :
diviser pour résoudre
Aspects techniques
en s'appuyant techniquement sur la modularité
« Encapsulation et masquage d'information, faible couplage »
Importance de la notion d’Objets
Aspects organisationnels
S’organiser au delà de la réalisation : méthodes
« Analyse, conception »
« Validation et vérification »
Ingénierie de la conduite de projet = compromis entre
respect des délais
respect des coûts
réponse aux besoins/assurance qualité
Problèmes de gestion de ressources (humaines, etc.) et
de synchronisation entre tâches
09/10 36

41. Intro. ✓Prog. Durée Intro. UML Démarche
Programming-in-the-Duration
Gestion de l’évolution d'un système
D’après Swanson & Beath (Maintaining
Information Systems in Organizations, 1989)
Durée de vie moyenne d’un système : 6.6 ans
26% des systèmes sont âgés de plus de 10 ans
Problème de la maintenance corrective et évolutive
Adaptation aux changements des besoins
Adaptation aux changements de l’environnement
Support nouvelles plateformes, bug « an 2000 »
09/10 37

42. Intro. ✓Prog. Durée ✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Problème de la maintenabilité
Exemple critique dû à M. Jackson
Barques à louer sur un lac
Enregistrement des départs (S) et retours (E) sur un
terminal, avec horodatage automatique
On veut chaque jour un rapport avec :
le nombre de sessions
la durée moyenne d'une session
09/10 38

43. Intro. ✓Prog. Durée ✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Approche « droit au but »
Décomposition fonctionnelle en 1980
Structured Analysis and Design technique : SADT
Le système a une fonction…
Décomposée récursivement en sous-fonctions…
Jusqu’à tomber sur des fonctions élémentaires
Reliées par flots de données
∑(
09/10 39

44. Intro. ✓Prog. Durée ✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Réalisation
currentTime;
currentTime;
09/10 40

45. Intro. ✓Prog. Durée✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Maintenance
Demandes de modifications :
durée de la session la plus longue
un état pour le matin, un autre pour le soir
corriger la perte de S ou de E
09/10 41

46. Intro. ✓Prog. Durée✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Maintenance
Demandes de modifications :
durée de la session la plus longue
un état pour le matin, un autre pour le soir
corriger la perte de S ou de E
Dans la réalité, c’est pire!
Nokia rapporte à propos de son infrastructure GSM
50% des exigences (besoins numérotés) ont changé après le gel du
cahier des charges
60% de ceux-ci ont changé au moins 2 fois!
C’est le cas général plutôt que l’exception
Cahier des charges figé = rêve des années 70
09/10 41

47. Exemple Windows Vista …
Vista prêt à en découdre avec les failles de sécurité!
C'est inévitable. La découverte de failles devrait s'accélérer avec le lancement en
grandeur réelle de Windows Vista. Microsoft s'y prépare…
…« Les failles sont inhérentes au développement logiciel. Elles reposent sur des
erreurs de programmation. Or, détecter absolument toutes les erreurs est
impossible même avec des moyens financiers comme ceux dont dispose
Microsoft »…
8 000 dollars pour chaque trou de sécurité!
… Idefense Labs, une filiale de Verisign, va encore plus loin. Elle promet
8 000 dollars (assortis d'un bonus oscillant entre 2 000 et 4 000 dollars selon la
qualité des explications fournies) à qui découvrira une faille critique dans Vista ou
Internet Explorer 7…
… « La démarche est pertinente dans la mesure où elle permet de mobiliser les
chercheurs du monde entier à moindre frais »… 42
Grimaldi 2010

48. Intro. ✓Prog. Durée✓Maintenance Intro. UML Démarche
Programming-in-the-Duration
Coût de la Maintenance
09/10 43

49. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
La découpe fonctionnelle d'un problème
informatique : une approche intuitive
Factorisation
09/10 44

50. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Le revers de la médaille :
maintenance complexe en cas d'évolution
09/10 45
->

51. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Le revers de la médaille :
maintenance complexe en cas d'évolution
La séparation des données et des
traitements : le piège !
09/10 45
->

52. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Réunir données et traitements :
Programmation par objets
09/10 46

53. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Vision objet du système
informatique (1)
➡ Le système d ’informatique est modélisé comme un ensemble
d ’objets, avec leurs propriétés et leurs comportements, qui
collaborent entre eux
• Un objet est une entité aux frontières précises
• Un ensemble d'attributs caractérise l'état de l'objet.
• Un ensemble d'opérations (méthodes ou comportements) en définit le
comportement.
09/10 47

54. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Vision objet du système
informatique (2)
➡ Un objet est une instance de classe (une occurrence d'un type
abstrait).
➡ Une classe est un type de données abstrait (modèle) ,
caractérisé par des propriétés (attributs et méthodes)
communes à des objets et permettant de créer des objets
possédant ces propriétés.
09/10 48

55. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Vision objet du
système informatique (3)
➡ Héritage (et polymorphisme)
L'héritage est un mécanisme de transmission des propriétés
d'une classe (ses attributs et méthodes) vers une sous-
classe.
09/10 49

56. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche
Vision objet du système
informatique (4)
➡ Héritage (et polymorphisme)
Le polymorphisme représente la faculté d'une méthode
à pouvoir s'appliquer à des objets de classes
différentes.
09/10 50

57. Intro. Intro. UML Démarche
Approche orientée-objet
Illustration de Jean-Marc Estay (IMA)
09/10 51

58. Intro. ✓Prog. Durée Intro. UML Démarche
Programming-in-the-Duration
Solution : approche par modélisation
Aspects techniques
Assurer une meilleure continuité entre
Domaine du problème
Domaine des solutions
Définir les fonctionnalités
Prévoir les scénarios de tests
Maintenance traitée comme le développement initial
Aspects organisationnels
Traçabilité Utilisation de
Gestion contrôlée des changements Méthodes
«Agiles»
09/10 52

59. Intro. Intro. UML Démarche
Problématique du génie logiciel
WHAT IS SOFTWARE ENGINEERING?
The IEEE Computer Society defines software engineering as
“(1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance
of software; that is, the application of engineering to
software.
(2) The study of approaches as in (1).”
http://www.swebok.org/
09/10 53

60. III. Introduction à UML
54

61. III. Introduction à UML
UML, histoire, généralité
55

62. Intro. Intro. UML ✓Histoire Démarche
Pourquoi UML ?
➡ Objectifs : spécifier, construire, visualiser et documenter les
systèmes à base de logiciel
Pour communiquer, travailler à plusieurs
Pour comprendre la « big picture »
Par approche orientée objets
Avec différents modèles pour différentes vues
➡ UML : Langage et non simple notation graphique (ni méthode)
➡ UML est Indépendant des méthodologies
09/10 56

63. Intro. Intro. UML ✓Histoire Démarche
Un peu d’histoire :
La guerre des Méthodes
Booch, OMT, Coad/Yourdon, Fusion,SADT, OOSE,
Schlaer/Mellor, HOOD…
UML: un méta-langage de modélisation pour unifier les
modèles utilisés dans les méthodes
09/10 57

64. Intro. Intro. UML ✓Histoire Démarche
Et un langage unique, un !
Un cocktail de notations éprouvées.
(...mais pas toutes, p. ex. RdP,
SADT/IDEF0, DFD, etc.)
Auteurs : Grady Booch, Ivar Jacobson, James Rumbaugh.
Standardisation OMG (Object Management Group) en 1997
Promoteurs :
Rational Software, Oracle
Hp, Microsoft, IBM
09/10 58

65. Intro. Intro. UML ✓Histoire Démarche
http://www.omg.org/spec/UML/2.3/Superstructure/PDF/ 758 pages
UML 2.3 May 2010
Commentaires du
public
09/10 59

66. Intro. Intro. UML ✓Histoire Démarche
Ingénierie Électrique Ingénierie du
Bâtiment
Ingénierie Ingénierie
09/10
Mécanique 60
Logicielle Grimaldi 2010

67. Intro. Intro. UML Démarche
Qu’est-ce qu’UML ?
un support à la modélisation
➡ Modèle : simplification de la réalité dont les buts sont
Visualiser Spécifier la
le système structure et le
comportement
du système
Aider à la
construction Documenter
du système les décisions
09/10 61

68. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
➡ UML est un langage «visuel»
➡ Il supporte
La visualisation
La spécification
La construction
La documentation
Jean-Paul Rigault 2005
09/10 62

69. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
➡ UML est un langage «visuel»
➡ Il supporte
La visualisation Syntaxe et sémantique
La spécification Descriptions graphiques et textuelles
La construction Architecture et comportement
Génération de code
La documentation
Jean-Paul Rigault 2005
09/10 62

70. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
➡ UML est un langage «visuel»
➡ Il supporte
La visualisation Syntaxe et sémantique
La spécification Descriptions graphiques et textuelles
La construction Architecture et comportement
Génération de code
La documentation
On ne décrit pas l’univers tout entier…
Le logiciel joue un rôle majeur
Jean-Paul Rigault 2005
09/10 62

71. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
➡ UML est un langage «visuel»
➡ Il supporte
La visualisation Syntaxe et sémantique
La spécification Descriptions graphiques et textuelles
La construction Architecture et comportement
Génération de code
La documentation
On ne décrit pas l’univers tout entier…
Le logiciel joue un rôle majeur
 UML n’est pas une méthodologie de développement, contrairement
à RUP (Rational Unified Process).
Jean-Paul Rigault 2005
09/10 62

72. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
Axes de modélisation d’un système
Statique (ce que le système EST)
Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système
FAIT)
09/10 63

73. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
Axes de modélisation d’un système
Statique (ce que le système EST)
• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système
FAIT)
09/10 63

74. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
Axes de modélisation d’un système
Statique (ce que le système EST)
• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système
FAIT)
• diagramme de cas d’utilisation
• diagramme de collaboration
09/10 63

75. Intro. Intro. UML ✓Histoire Démarche
Qu’est-ce qu’UML ?
Axes de modélisation d’un système
Statique (ce que le système EST)
• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système
• diagramme de séquences FAIT)
• diagramme de collaboration • diagramme de cas d’utilisation
• diagramme d’états-transitions • diagramme de collaboration
• diagramme d’activités
09/10 63

76. Intro. Intro. UML ✓Histoire Démarche
Les points forts d'UML
UML est un langage normalisé
gain de précision
gage de stabilité
encourage l'utilisation d'outils
UML est un support de communication performant
Il cadre l'analyse.
Il facilite la compréhension de représentations abstraites
complexes.
Son caractère polyvalent et sa souplesse en font un langage
universel.
09/10 64

77. Intro. Intro. UML ✓Histoire Démarche
Les points faibles d'UML
La mise en pratique d'UML nécessite un apprentissage et
passe par une période d'adaptation.
Le processus (non couvert par UML) est une autre clé de la
réussite d'un projet.
09/10 65

78. III. Introduction à UML
survol
66

79. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes des cas d’utilisation
Ce diagramme montre ce que que fait le système et qui l’utilise
Entrer
DébloquerLesPortes
PorteurDeCarte Capteur
AIncendie
Sortir
ListerLes
TentativesDeFraudes
GérerLesCartes
Gardien Administrateur
SystèmeDeContrôleDAcces
09/10 67

80. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes de séquence
Ce diagramme montre les flots de communications
paul le distrib. la carte de P. la reserve la banque le compte de P.
retirer(500)
lireN°Compte()
retirerDeLArgent(500,88219)
débiter(500)
sortirDesBillets(5)
sortirBillets ()
09/10 68

81. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes de collaboration
6 : prendreBillet()
la reserve de billets
5 : sortirDesBillets(5)
1 : retirer(500) 3 : retirerDeLArgent 4 : débiter(500)
le distributeur (500,88219)
la banque
paul
88219 2 : lireN°Compte()
le compte de paul
la carte de P.
09/10 69

82. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes de classes
Compte Banque
1..4 1..* 1..* 1..*
Client numéro
titulaires numéro
solde nom
1 signataire ... 0..*
1 Consortium
CarteBleue
0..* 0..* 1
Code
retraitMax AcceptéPar> 0..*
Distributeur
1..*
Ce diagramme montre les classes et les relations entre elles
09/10 70

83. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes d’objets
EstAcceptéPar>
: Distributeur
: CarteBleue
signataire
titulaires
fred : Client c4 : Compte : Banque : Consortium
: CarteBleue
signataire
paul : Client c1 : Compte : Banque
titulaires
titulaires
pierre : Client c2 : Compte
: Consortium
titula
ires
titulaires
marie : Client c3 : Compte : Banque
signataire
: CarteBleue
EstAcceptéPar>
Ce diagramme montre les instances
sophie : Client
EstAcceptéPar>
: Distributeur
et les liens entre elles à l’exécution.
09/10 71

84. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Diagrammes d’états
carte insérée
En attente En attente du code
carte retirée mauvais code code frappé
En attente retrait carte En vérification
code bon
Pour expliciter
les attentes
montant incorrect En attente du montant
d’évènements &
les différents montant correct
états d’un objet.
billets retirés
En distribution
09/10 72

85. Intro. Intro. UML ✓Survol Démarche
Qu’est-ce qu’UML ?
Divers modes d’utilisation
➡ Mode esquisse (sketch)
Informelle, incomplète
Souvent manuelle (tableau)
➡ Mode plan (blue print)
Diagrammes détaillés
Production de documents
Pro- et rétro-ingénierie
➡ Mode langage de programmation
Spécification complète et exécutable
Pas vraiment disponible actuellement !
Jean-Paul Rigault 2005
09/10 73

86. Intro. Intro. UML ✓Survol De Merise à UML
Unified Process (UP)
➡ UML se veut indépendant de toute méthodologie
➡ Cependant, il est mieux adapté à un processus (tel le RUP)
dirigé par les cas d’utilisation (use-case driven)
centré sur l’architecture (architecture centric)
itératif et incrémental
➡ Le UP propose en outre
des techniques de modélisation pour les différentes phases et
activités
une organisation des rôles et des flots lors du processus de
développement
A venir dans
09/10 74 le cours

87. V. Démarche générale suivie
dans le cadre de ce module
75

88. Intro. Intro. UML Démarche
Approche dirigée par les cas
09/10 76

89. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
09/10 76

90. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
09/10 76

91. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
09/10 76

92. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
4. Pour chaque cas d'utilisation seront décrits les principaux flux qui
visualisent la chronologie des échanges entre les acteurs et le système
09/10 76

93. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
4. Pour chaque cas d'utilisation seront décrits les principaux flux qui
visualisent la chronologie des échanges entre les acteurs et le système
5. Capturer les concepts du domaine
09/10 76

94. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
4. Pour chaque cas d'utilisation seront décrits les principaux flux qui
visualisent la chronologie des échanges entre les acteurs et le système
5. Capturer les concepts du domaine
6. A chaque flux sera associé un diagramme de séquence qui mettra en avant
l'aspect temporel des interactions entre les objets de l'application qui
participent au scénario
09/10 76

95. Intro. Intro. UML Démarche
Approche dirigée par les cas
1. Établir le dictionnaire
2. Identification des acteurs qui agissent sur le système à étudier.
3. Définition et description des cas d'utilisation qui montreront les
interactions entre les acteurs actifs externes et le système vu comme une
boîte noire.
4. Pour chaque cas d'utilisation seront décrits les principaux flux qui
visualisent la chronologie des échanges entre les acteurs et le système
5. Capturer les concepts du domaine
6. A chaque flux sera associé un diagramme de séquence qui mettra en avant
l'aspect temporel des interactions entre les objets de l'application qui
participent au scénario
7. Ces diagrammes serviront alors de base à la construction des diagrammes
de séquence de conception et les diagrammes de classes qui visualisent
l'architecture du logiciel, la hiérarchie et les associations entre classes
09/10 76

96. Exemple: Une galerie d’art virtuelle
77

97. Intro. Intro. UML Démarche
1) Dictionnaire
Personne identifiée par la galerie à l'origine d'une ou plusieurs
Artiste œuvres.
Création d’un artiste destinée à être vendue sur le site.
Œuvre
Client Internaute qui possède un compte sur le site.
Galerie Lieu d'exposition et de vente d'œuvres d'art moins une œuvre.
Gérant Responsable du magasin, initialise les caisses,
Personne en charge du suivi du site ayant la possibilité de gérer
Administrateur l'ajout de nouveaux artistes, œuvres et de modifier les
informations concernant un artiste et/
09/10 78

98. Intro. Intro. UML Démarche
2) Acteurs et diagrammes de contexte
09/10 79

99. Intro. Intro. UML Démarche
3) Diagramme des cas d'utilisation
uses case diagram
09/10 80

100. Intro. Intro. UML Démarche
4) Description complète d'un cas d’utilisation
Acheter des oeuvres
Acteurs : Client
Objectif : Décrire un achat d’oeuvre
par le Client
Aperçu : Un Client sélectionne des
oeuvres qu’il met dans son
panier. Le Client demande à
passer commande. Le
système vérifie la
disponibilité des oeuvres et
bloque leur vente. Il calcule le
montant de la comma ces
09/10
produits, 81
annonce le total,

101. Intro. Intro. UML Démarche
5) Capturer les concepts du domaine
Acheter des oeuvres
Acteurs : Client
Objectif : Décrire un achat d’oeuvre
par le Client
Aperçu : Un Client sélectionne des
oeuvres qu’il met dans son
panier. Le Client demande à
passer commande. Le
système vérifie la
disponibilité des oeuvres et
bloque leur vente. Il calcule le
montant de la comma ces
09/10
produits, annonce le total,
82

102. Intro. Intro. UML Démarche
5) Capturer les concepts du domaine
09/10 83

103. Intro. Intro. UML Démarche
Scénarios : Niveau Analyse
09/10 84

104. Intro. Intro. UML Démarche
Scénarios : Niveau Conception
09/10 85

105. Intro. Intro. UML Démarche
Diagramme de classes :
Niveau Conception
09/10 86

106. Intro. Intro. UML Démarche
Diagramme de classes :
Niveau Conception : Tables
(partiel)
09/10 87

107. Intro. Intro. UML Démarche
Bibliographie
Ce cours a été monté en utilisant de nombreux supports
dont je remercie chaleureusement ici les auteurs
D’autres références se trouvent sur le site du module.
Merise: 5ème Partie Dossier "SAM l'Informaticien" du 5 Mars au 18 Mars 2001
par Stéphane Lambert http://www.vediovis.fr/index.php?page=merise5
Introduction au langage UML, SUPINFO
De Merise à UML, Nasser Kettani, Dominique Mignet, Eyrolles
http://www.compucycles.com/nouveausite/articles/Merise/Article_07.htm
UML-MERISE Etude Comparative, OSITEC-Consultants, 2004-2005
Modélisation Orientée objet, M.Grimaldi – janvier 2010
09/10 88