Modélisation par Objets
À destination des étudiants du
2e année IUT Nice-Sophia Antipolis
- 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
Modélisation par Objets - Introduction - De Merise à UML
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/2010_2011/s3/omgl/mod-si/start
1
mercredi 8 septembre 2010
2. Modélisation
par
Objets
2
mercredi 8 septembre 2010
3. 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
IBM
mercredi 8 septembre 2010
4. 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
mercredi 8 septembre 2010
5. 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
mercredi 8 septembre 2010
6. 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
mercredi 8 septembre 2010
7. 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
mercredi 8 septembre 2010
8. 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
mercredi 8 septembre 2010
9. 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
mercredi 8 septembre 2010
10. 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
mercredi 8 septembre 2010
11. 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
mercredi 8 septembre 2010
12. 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
mercredi 8 septembre 2010
13. 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
mercredi 8 septembre 2010
14. 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 :
14
mercredi 8 septembre 2010
15. 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 :
15
mercredi 8 septembre 2010
16. 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 :
16
mercredi 8 septembre 2010
17. Intro. Intro. UML De Merise à UML
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
Présentation du Module
09/10 17 /99
mercredi 8 septembre 2010
18. I. Quels sont les problèmes
du développement logiciel?
18
mercredi 8 septembre 2010
19. I. Quels sont les problèmes
du développement logiciel?
Un peu d’histoire
19
mercredi 8 septembre 2010
20. Intro. ✓histoire Intro. UML De Merise à UML
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 20 /99
mercredi 8 septembre 2010
21. Intro. ✓histoire Intro. UML De Merise à UML
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 21 /99 END PROGRAM DEGRAD
mercredi 8 septembre 2010
22. Intro. ✓histoire Intro. UML De Merise à UML
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 22 /99 Phrase:=ConstruitPhrase(Phrase);
mercredi 8 septembre 2010
23. Intro. ✓histoire Intro. UML De Merise à UML
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 23 /99
mercredi 8 septembre 2010
24. Intro. ✓histoire Intro. UML De Merise à UML
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 24 /99
mercredi 8 septembre 2010
25. Intro. ✓histoire Intro. UML De Merise à UML
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 25 /99
mercredi 8 septembre 2010
26. I. Quels sont les problèmes
du développement logiciel?
Du bidouillage au génie logiel
26
mercredi 8 septembre 2010
27. Intro. Intro. UML De Merise à UML
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 27 /99
mercredi 8 septembre 2010
28. Intro. ✓Prog. Small ✓Validation Intro. UML De Merise à UML
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 28 /99
mercredi 8 septembre 2010
29. Intro. ✓Prog. Small ✓Validation Intro. UML De Merise à UML
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 29 /99
mercredi 8 septembre 2010
30. Intro. ✓Prog. Small ✓Validation Intro. UML De Merise à UML
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 30 /99
mercredi 8 septembre 2010
31. Intro. ✓Prog. Large ✓Complexité Intro. UML De Merise à UML
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 31 /99
mercredi 8 septembre 2010
32. Intro. ✓Prog. Large ✓Complexité Intro. UML De Merise à UML
Programming-in-the-Large
Augmentation exponentielle de la taille du logiciel
09/10 32 /99
mercredi 8 septembre 2010
33. Intro. ✓Prog. Large ✓Complexité Intro. UML De Merise à UML
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 33 /99
mercredi 8 septembre 2010
34. Intro. ✓Prog. Large ✓Diviser Intro. UML De Merise à UML
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 34 /99
mercredi 8 septembre 2010
35. Intro. ✓Prog. Durée Intro. UML De Merise à UML
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 35 /99
mercredi 8 septembre 2010
36. Intro. ✓Prog. Durée ✓Maintenance Intro. UML De Merise à UML
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 36 /99
mercredi 8 septembre 2010
37. Intro. ✓Prog. Durée ✓Maintenance Intro. UML De Merise à UML
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 37 /99
mercredi 8 septembre 2010
38. Intro. ✓Prog. Durée ✓Maintenance Intro. UML De Merise à UML
Programming-in-the-Duration
Réalisation
09/10 38 /99
mercredi 8 septembre 2010
39. Intro. ✓Prog. Durée✓Maintenance Intro. UML De Merise à UML
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 39 /99
mercredi 8 septembre 2010
40. Intro. ✓Prog. Durée✓Maintenance Intro. UML De Merise à UML
Programming-in-the-Duration
Coût de la Maintenance
09/10 40 /99
mercredi 8 septembre 2010
41. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML De Merise à UML
La découpe fonctionnelle d'un problème
informatique : une approche intuitive
Factorisation
09/10 41 /99
mercredi 8 septembre 2010
42. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML De Merise à UML
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 42 /99
->
mercredi 8 septembre 2010
43. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML De Merise à UML
Réunir données et traitements :
Programmation par objets
09/10 43 /99
mercredi 8 septembre 2010
44. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML De Merise à UML
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 44 /99
mercredi 8 septembre 2010
45. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML De Merise à UML
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 45 /99
mercredi 8 septembre 2010
46. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML De Merise à UML
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 46 /99
mercredi 8 septembre 2010
47. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML De Merise à UML
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 47 /99
mercredi 8 septembre 2010
48. Intro. Intro. UML De Merise à UML
Approche orientée-objet
Illustration de Jean-Marc Estay (IMA)
09/10 48 /99
mercredi 8 septembre 2010
49. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML De Merise à UML
L'approche objet : une solution
parfaite ?
L'approche objet est moins intuitive que l'approche
fonctionnelle !
➡ Quels moyens utiliser pour faciliter l'analyse objet ?
➡ Quels critères identifient une conception objet
pertinente ?
L'application des concepts objets nécessite une grande
rigueur !
➡ Le vocabulaire est précis (risques d'ambiguïtés,
d'incompréhensions).
➡ Comment décrire la structure objet d'un système de
manière pertinente ?
09/10 49 /99
mercredi 8 septembre 2010
50. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML De Merise à UML
Quels sont les remèdes
aux inconvénients de l'approche objet ?
Modéliser avec un langage pour exprimer les concepts objet afin de
pouvoir :
➡ Représenter des concepts abstraits (graphiquement par exemple…).
➡ Limiter les ambiguïtés (parler un langage commun).
➡ Faciliter l'analyse (simplifier la comparaison et l'évaluation de
solutions).
Une démarche d'analyse et de conception objet, pour :
➡ Ne pas effectuer une analyse fonctionnelle et se contenter d'une
implémentation objet, mais penser objet dès le départ.
➡ Définir les vues qui permettent de couvrir tous les aspects d'un
système, avec des concepts objets.
09/10 50 /99
mercredi 8 septembre 2010
51. Intro. ✓Prog. Durée Intro. UML De Merise à UML
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é
Gestion contrôlée des changements Utilisation de
Méthodes
«Agiles»
09/10 51 /99
mercredi 8 septembre 2010
52. Intro. Intro. UML De Merise à UML
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 52 /99
mercredi 8 septembre 2010
54. III. Introduction à UML
UML, histoire, généralité
54
mercredi 8 septembre 2010
55. Intro. Intro. UML ✓Histoire De Merise à UML
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 55 /99
mercredi 8 septembre 2010
56. Intro. Intro. UML ✓Histoire De Merise à UML
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 56 /99
mercredi 8 septembre 2010
57. Intro. Intro. UML ✓Histoire De Merise à UML
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 57 /99
mercredi 8 septembre 2010
58. Intro. Intro. UML De Merise à UML
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 58 /99
mercredi 8 septembre 2010
59. Intro. Intro. UML ✓Histoire De Merise à UML
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 59 /99
mercredi 8 septembre 2010
60. Intro. Intro. UML ✓Histoire De Merise à UML
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 60 /99
mercredi 8 septembre 2010
61. Intro. Intro. UML ✓Histoire De Merise à UML
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 61 /99
mercredi 8 septembre 2010
62. Intro. Intro. UML ✓Histoire De Merise à UML
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 62 /99
mercredi 8 septembre 2010
64. Intro. Intro. UML ✓Survol De Merise à UML
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 64 /99
mercredi 8 septembre 2010
65. Intro. Intro. UML ✓Survol De Merise à UML
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 65 /99
mercredi 8 septembre 2010
66. Intro. Intro. UML ✓Survol De Merise à UML
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 66 /99
mercredi 8 septembre 2010
67. Intro. Intro. UML ✓Survol De Merise à UML
Qu’est-ce qu’UML ?
Diagrammes de classes
Compte Banque
1..4 1..* 1..* 1..*
Client numéro
titulaires numéro
solde nom
... 0..*
1 signataire
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 67 /99
mercredi 8 septembre 2010
68. Intro. Intro. UML ✓Survol De Merise à UML
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 68 /99
mercredi 8 septembre 2010
69. Intro. Intro. UML ✓Survol De Merise à UML
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 69 /99
mercredi 8 septembre 2010
70. Intro. Intro. UML ✓Survol De Merise à UML
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 70 /99
mercredi 8 septembre 2010
71. 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 71 /99 le cours
mercredi 8 septembre 2010
72. IV. De Merise à UML
en bref
Attention UML n’est pas une méthode :
Nous étudions uniquement ici
le support de Merise par UML
72
mercredi 8 septembre 2010
73. Intro. Intro. UML De Merise à UML
Les principes de Merise
Approche systémique
Un système = Un ensemble d’éléments en interaction organisés en
fonction d’un but. Un système transforme des éléments reçus en
entrée (inputs) en éléments de sortie (outputs) par des actions
(processus). Il peut être contrôlé et régulé par un système de pilotage.
Intègre les notions de limites du système à étudier, découpage en sous-
ensembles, finalité, buts, objectifs et interactions.
Prise en charge par les cas d’utilisation en UML:
- Le système est considéré comme une boîte noire qui réagit à
des sollicitations extérieurs par des «acteurs».
- Chaque cas d’utilisation est modélisé par des collaborations
représentant ainsi la dynamique du système.
09/10 73 /99
mercredi 8 septembre 2010
74. Intro. Intro. UML De Merise à UML
Les principes de Merise
Cycles de construction du SI
Cycle de vie : il mène du
point de départ à
l’exploitation du système, en
passant par sa création, sa
maturité et sa maintenance.
Cycle de décision : Il
représente l’ensemble des
choix qui doivent être fait
durant le déroulement du
cycle de vie.
Cycle d’abstraction :
niveaux conceptuel,
organisationnel, physique.
09/10 74 /99
mercredi 8 septembre 2010
75. Intro. Intro. UML De Merise à UML
Les principes de Merise
Cycles de construction du SI
Cycle de vie : il mène du
Non défini par UML, mais une approche
point de départ à
l’exploitation du système, en itérative et incrémentale guidée par les
passant par sa création, sa use-cases & l’architecture sous-tend.
maturité et sa maintenance.
Cycle de décision : Il UML cible une intervention des
représente l’ensemble des utilisateurs aux tâches d’analyse et
choix qui doivent être fait conception.
durant le déroulement du
cycle de vie. UML supporte la modélisation des
Cycle d’abstraction : différents niveaux par différents types de
niveaux conceptuel, diagrammes : use-case, classes,
organisationnel, physique. composants, noeuds, ...
A l’utilisateur de décider du bon modèle au
09/10 bon niveau...l’architecture.
75 /99
mercredi 8 septembre 2010
76. Intro. Intro. UML De Merise à UML
Les principes de Merise
Approche fonctionnelle
Le problème est décomposé en UML n’utilise pas une approche
activités, décomposées en fonctionnelle.
fonctions, décomposées en Les diagrammes d’utilisations font place
règles de gestion. aux fonctions en plaçant les besoins dans
Les règles se décomposent en un contexte réel.
Des diagrammes d’interactions explicitent
modules.
les scenarios des cas d’utilisation.
Des diagrammes de fonctions Des diagrammes d’activités décrivent les
activités dans les processus métier.
Les besoins sont portés par des classes
donnant naissance à des composant
réutilisables.
09/10 76 /99
mercredi 8 septembre 2010
77. Intro. Intro. UML De Merise à UML
Les principes de Merise
Approche données-traitements
Merise considère le système - L’approche objet associe les
réel selon un point de vue informations et les traitements assurant
statique (les données) et un ainsi une certaine cohérence.
point de vue dynamique - Les scénarios permettent de valider les
(les traitements). classes.
Validation des - Il est possible d’ajouter des contrôles
données par liaison pour s’assurer que les besoins utilisateurs
aux traitements sont respectés.
- La place des use-cases est
Merise est une méthode de prépondérante pour assurer la cohérence
type "descendante" d’un ensemble.
( TOP -DOWN )
- UML supporte une approche aussi bien
descendante qu’ascendante.
09/10 77 /99
mercredi 8 septembre 2010
78. Intro. Intro. UML De Merise à UML
Modélisation du métier
Acteurs
Un acteur représente une entité active intervenant dans le fonctionnement de
l’entreprise :
Client, Fournisseurs, (acteur externe)
Un domaine de l’entreprise (Gestion Personnel, Comptabilité)
Le système de pilotage.
Distinction entre acteur externe et interne
Pour UML au niveau métier l’acteur est de fait externe.
De manière plus précise, les acteurs sont analysés en fonction de
leur rôle par rapport au périmètre d’étude.
09/10 78 /99
mercredi 8 septembre 2010
79. Intro. Intro. UML De Merise à UML
Modélisation du métier
Flux
L’analyse des flux permet de représenter le fonctionnement global de l’entreprise
Un flux de données est la représentation d’un échange d’informations entre deux
acteurs. Il est un support de communication avec les utilisateurs.
Le diagramme des flux est une représentation graphique des acteurs et des flux . Il
est construit par itération.
En UML les use-cases ne capturent que les liens de haut niveau
pas les échanges, par contre il précise le rôle des acteurs.
Au niveau interne les diagrammes de séquences et d’activités
permettent de représenter les flux en s’orientant davantage vers
une décomposition pour ce dernier en terme de fonctions.
09/10 79 /99
mercredi 8 septembre 2010
80. Intro. Intro. UML De Merise à UML
Modélisation du métier
Flux
09/10 80 /99
mercredi 8 septembre 2010
81. Intro. Intro. UML De Merise à UML
Modélisation du métier
Diagramme de Cas d’utilisation
09/10 81 /99
mercredi 8 septembre 2010
82. Intro. Intro. UML De Merise à UML
Modélisation du métier
Diagramme de Séquence
09/10 82 /99
mercredi 8 septembre 2010
83. Intro. Intro. UML De Merise à UML
Modélisation du métier
Niveau conceptuel
Le Modèle conceptuel des données (MCD) et le diagramme de classes
possèdent beaucoup de points communs et une approche de
structuration similaire.
Nous les comparerons en détail dans un prochain cours
En UML le diagramme de classes est utilisé au cours de
l’ensemble du processus:
• Les classes contiennent les opérations (services),
• Les contraintes sont exprimées dans un langage de contrainte (OCL),
• UML propose des stéréotypes,
• UML n’implique pas l’utilisation d’un formalisme de normalisation
sur les classes, mais des règles sont à respecter pour éviter les erreurs.
09/10 83 /99
mercredi 8 septembre 2010
84. Intro. Intro. UML De Merise à UML
Modélisation du métier
Niveau conceptuel
Le Modèle conceptuel des données (MCD)
09/10 84 /99
mercredi 8 septembre 2010
85. Intro. Intro. UML De Merise à UML
Modélisation du métier
Niveau conceptuel
Le Diagramme de classes Pas forcément celui-ci
09/10 85 /99
mercredi 8 septembre 2010
86. Intro. Intro. UML De Merise à UML
Modélisation du métier
Niveau conceptuel
Etats-transitions - cycle de vie (comportement)*
Dans Merise le cycle de vie des objets (CVO) traduit les différents états
que peut prendre l'entité, leur succession, les événements déclencheurs
UML fournit un diagramme états-transitions qui correspond
directement au CVO:
• Il s'agit des modèles les plus proches,
• UML propose des concepts de sous-états, de macro-états, d'états
parallèles et détaille d'avantage les actions et les opérations,
• Ce diagramme est lié au diagramme de classe.
Nous les comparerons en détail dans un prochain cours
86 /99
09/10
mercredi 8 septembre 2010
87. Intro. Intro. UML De Merise à UML
Modélisation du métier
Niveau conceptuel
Cycle de vie des objets (CVO)
09/10 87 /99
mercredi 8 septembre 2010
88. Intro. Intro. UML De Merise à UML
Modélisation du métier
Niveau conceptuel
Diagramme d’états-transitions
09/10 88 /99
mercredi 8 septembre 2010
89. Intro. Intro. UML De Merise à UML
Modélisation du métier
Niveau conceptuel
Dans le Modèle conceptuel des traitements (MCT), on trouve les
concepts d'événements, de règles de gestion, de synchronisation et
d'opérations qui réutilisent la notion de flux.
En UML, événements internes et externes apparaissent au
niveau des diagrammes séquences/activités.
• Les règles de gestion apparaissent dans les contraintes OCL et dans les
méthodes des classes,
• Les synchronisations apparaissent dans les diagrammes d'activités et
d'états-transitions,
• Les opérations sont représentées dans les diagrammes d'activités.
En résumé: pour retrouver les informations d'un MCT, il faut
jongler avec différents diagrammes en UML !!!
09/10 89 /99
mercredi 8 septembre 2010
90. Intro. Intro. UML De Merise à UML
Modélisation du métier
Modèle conceptuel
des traitements
(MCT)
09/10 90 /99
mercredi 8 septembre 2010
91. Intro. Intro. UML De Merise à UML
Modélisation du métier
Diagramme d’activités et de séquence
09/10 91 /99
mercredi 8 septembre 2010
92. Intro. Intro. UML De Merise à UML
Modélisation du métier
Diagramme d’activités et de séquence
09/10 92 /99
mercredi 8 septembre 2010
93. Intro. Intro. UML De Merise à UML
Modélisation du métier
Niveau organisationnel
La formalisation organisationelle vise à Spécifier l’organisation qui régira les
données et traitements
Modèle Organisationnel des Traitements (MOT) : complète le MCT avec les
acteurs, temps, types d’opérations
Modèle Logique des Données (MLD) fait suite au MCD
En UML, les aspects dynamiques apparaissent là encore dans les
diagrammes d'activités/séquences:
• Ils servent directement pour le passage du métier au système
informatique,
• Les échanges et les attentes apparaissent clairement dans les activités,
➡ Merise offre une vision plus globale de l'organisation.
09/10 93 /99
mercredi 8 septembre 2010
94. Intro. Intro. UML De Merise à UML
La démarche & les modèles
Merise adopte un nombre important de formalismes pour modéliser le
métier, mais il y a des ruptures pour le passage au modèle logique,
UML propose un nombre important de concepts et de diagrammes qui
suivent le processus de développement du métier au système informatique.
– Cas d'utilisation et modèle de contexte
ne sont pas équivalents,
– Diagramme de classes et MCD
sont voisins, mais les classes ne sont pas que conceptuels (métier et logique).
– Diagramme de séquence/activité et modèle de contexte et de flux
partagent des points communs,
– Le diagramme d'états-transition se retrouve en Merise,
– Diagramme de composants ne se retrouve pas directement dans un modèle en
Merise,
– Diagramme de déploiement est proche du modèle d'architecture
09/10 94 /99
mercredi 8 septembre 2010
95. Intro. Intro. UML De Merise à UML
De l’analyse à la conception...
en UML
1. Capture des besoins : diagrammes de cas d’utilisation
2. Focus sur les flots de communication : Diagrammes de
séquences
3. Construction du système : Diagrammes de Classes
4. De l’analyse à la conception
5. Point de vue général sur le procédé : Introduction à la méthode
orientée objet
09/10 95 /99
mercredi 8 septembre 2010
96. Intro. Intro. UML De Merise à UML
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
09/10 96 /99
mercredi 8 septembre 2010