Version simple de l'introduction au cours.

1. ACSI
Modélisation par Objets
À destination des étudiants de
1e année IUT Nice-Sophia Antipolis (S2)
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. 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
Présentation du Module : démarche générale
09/10 2

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

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

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

6. 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 6 END PROGRAM DEGRAD

7. 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 7 Phrase:=ConstruitPhrase(Phrase);

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

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

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

11. 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 10

12. 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 10

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

14. 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 12

15. 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 13

16. 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 14

17. 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 15

18. 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 16

19. 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 17

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

21. 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 19

22. 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 20

23. 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 21

24. 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 22

25. 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 23

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

27. 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 25

28. 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 25

29. 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 »… 26
Grimaldi 2010

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

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

32. 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 29
->

33. 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 29
->

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

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

36. 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 32

37. 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 33

38. 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 34

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

40. 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 36

41. 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 37

42. III. Introduction à UML
38

43. III. Introduction à UML
UML, histoire, généralité
39

44. 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 40

45. 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 41

46. 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 42

47. 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 43

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

49. 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 45

50. 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 46

51. 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 46

52. 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 46

53. 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 46

54. 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 47

55. 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 47

56. 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 47

57. 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 47

58. 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 48

59. 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 49

60. III. Introduction à UML
survol
50

61. 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 51

62. 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 52

63. 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 53

64. 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 54

65. 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 55

66. 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 56

67. 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 57

68. 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 58 le cours

69. V. Démarche générale suivie
dans le cadre de ce module
59

70. Intro. Intro. UML Démarche
Approche dirigée par les cas
09/10 60

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

72. 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 60

73. 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 60

74. 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 60

75. 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 60

76. 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 60

77. 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 des diagrammes de classes qui visualisent
l'architecture du logiciel, la hiérarchie et les associations entre classes
09/10 60

78. 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 des diagrammes de classes qui visualisent
l'architecture du logiciel, la hiérarchie et les associations entre classes
8. La structure de la BD peut alors être abordée.
09/10 60

79. Exemple: Une ludothèque
61

80. Intro. Intro. UML Démarche
Ludothèque
Les adhérents peuvent emprunter des jeux en s’adressant à un conseiller
qui enregistre l’emprunt.
Les jeux empruntés sont rendus à un conseiller....
Un adhérent peut réserver des jeux. Une réservation précise
l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent
est averti quand le jeu revient en rayon.
Pour organiser un événement le conseiller spécialisé doit alors donner
les informations suivantes : les jeux à tester, le nombre maximal et
minimal de participants attendus, la date, et l’heure de début de
l’événement.
Un adhérent peut s’inscrire pour participer à un événement à condition
qu’il y ait encore de la place.
Un adhérent peut payer sa cotisation en ligne par un système de
paiement externe
Un internaute peut consulter les jeux et s’inscrire.
09/10 62

81. Intro. Intro. UML Démarche
Ludothèque
Les adhérents peuvent emprunter des jeux en s’adressant à un
conseiller qui enregistre l’emprunt.
Les jeux empruntés sont rendus à un conseiller....
Un adhérent peut réserver des jeux. Une réservation précise
l’emprunteur, le jeu et la date de la demande de réservation.
L’adhérent est averti quand le jeu revient en rayon.
Pour organiser un événement le conseiller spécialisé doit alors
donner les informations suivantes : les jeux à tester, le nombre
maximal et minimal de participants attendus, la date, et l’heure
de début de l’événement.
Un adhérent peut s’inscrire pour participer à l’événement en en
faisant la demande à un conseiller spécialisé, à condition qu’il y
ait encore de la place.
Un adhérent peut payer sa cotisation en ligne par un système
09/10 de paiement externe 63

82. Intro. Intro. UML Démarche
Ludothèque : Dictionnaire
Adhérents : Personne connue du système par son nom, prénom, date
de naissance, adresse postale, date du dernier paiement de la cotisation et
adresse email éventuelle.
Conseiller : Personne identifiée qui a des droits sur le système.
Réservation : Une réservation précise l’emprunteur, le jeu et la
date de la demande de réservation. L’adhérent est averti quand le
jeu revient en rayon.
Evénement : temps de démonstration et de jeux organisé à
l’avance. Il précise les informations suivantes : les jeux à tester, le
nombre maximal et minimal de participants attendus, la date, et
l’heure de début de l’événement.
Jeux : Un jeu est caractérisé par un identifiant, un nombre de
joueurs, ...
09/10 64

83. Intro. Intro. UML Démarche
Acteurs et diagramme de contexte
09/10 65

84. Intro. Intro. UML Démarche
Diagramme
de cas
d’utilisation
09/10 66

85. Intro. Intro. UML Démarche
4) Description complète d'un cas d’utilisation
Emprunter un jeu
Acteurs : Conseiller
Objectif : Décrire l’emprunt d’un jeux
par un Conseiller
Aperçu : Un Conseiller passe le lecteur
de code barre sur le jeu; Le
Conseiller saisit l’identifiant
de l’adhérent. Le système
vérifie la droit d’emprunter
de l’adhérent. Il enregistre
l’emprunt.
09/10 67

86. Intro. Intro. UML Démarche
5) Capturer les concepts du domaine
Emprunter un jeu
Acteurs : Conseiller
Objectif : Décrire l’emprunt d’un jeux par un Conseiller
Aperçu : Un Conseiller passe le lecteur de code barre sur
le jeu; Le Conseiller saisit l’identifiant de
l’adhérent. Le système vérifie la droit
d’emprunter de l’adhérent. Il enregistre
l’emprunt.
09/10 68

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

88. Intro. Intro. UML Démarche
Scénarios : Niveau Analyse
09/10 70

89. Intro. Intro. UML Démarche
Scénarios : Niveau Conception
09/10 71

90. Intro. Intro. UML Démarche
Diagramme de classes :
Niveau Conception
09/10 72

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

92. Exemple: Une galerie d’art virtuelle
74

93. 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 75