Modélisation par Objets - Introduction - De Merise à UML

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

Modélisation
par
Objets
2

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

Question

Un modèle. . .?

A. doit être structurel et comportemental.
B. est inutile si les membres d’une équipe savent
programmer
C. est une simpliﬁcation de la réalité.
D. est une excuse pour retarder le développement

Réponse :

4

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 planiﬁcation
E. Toutes ces réponses

Réponse :
5

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éciﬁcation
F. simuler un système
G.autre
Réponse :
6

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 ﬁni de représenter la réalité
E. on n’a plus d’argent
F. le système s’arrête

Réponse :
7

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

Question
Un objet . . . ?

A. a un état déﬁni par la valeur de ses attributs
B. a une identité qui doit correspondre à une clef dans
une BD
C. est identiﬁé par une référence
D. peut recevoir des messages

Réponse :
9

Question

Pour communiquer avec un objet,
je ....?

A. lui envoie des messages
B. le stocke dans une base de données
C. modiﬁe la valeur de ses attributs

Réponse :

10

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éﬁnition abstraite d’un object.

Réponse :

11

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

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

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 modiﬁcations d’implémentations
D. engendre une gestion difﬁcile de l’évolution

Réponse :
14

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

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

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

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

18

Un peu d’histoire

19

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

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



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);



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 diversiﬁée, les besoins ont explosé.

09/10 23 /99


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
modiﬁcation des données peut entraîner d'importantes modiﬁcations 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


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

Du bidouillage au génie logiel

26


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éciﬁque 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

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 !

09/10 28 /99


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éciﬁques
…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


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

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.
09/10 31 /99


Augmentation exponentielle de la taille du logiciel

09/10 32 /99


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

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ériﬁcation »
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

Intro. ✓Prog. Durée Intro. UML De Merise à UML

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

Intro. ✓Prog. Durée ✓Maintenance Intro. UML De Merise à UML

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


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 ﬂots de données

∑(
09/10 37 /99


Réalisation

09/10 38 /99

Intro. ✓Prog. Durée✓Maintenance Intro. UML De Merise à UML

Maintenance
Demandes de modiﬁcations :
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 ﬁgé = rêve des années 70
09/10 39 /99

Intro. ✓Prog. Durée✓Maintenance Intro. UML De Merise à UML

Coût de la Maintenance

09/10 40 /99

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


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


Réunir données et traitements :
Programmation par objets

09/10 43 /99


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éﬁnit le
comportement.

09/10 44 /99


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


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


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


Approche orientée-objet

Illustration de Jean-Marc Estay (IMA)
09/10 48 /99


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 identiﬁent 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


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

Intro. ✓Prog. Durée Intro. UML De Merise à UML

Solution : approche par modélisation

Aspects techniques
Assurer une meilleure continuité entre
Domaine du problème
Domaine des solutions
Déﬁnir 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


Problématique du génie logiciel
WHAT IS SOFTWARE ENGINEERING?
The IEEE Computer Society deﬁnes software engineering as
“(1) The application of a systematic, disciplined, quantiﬁable
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

III. Introduction à UML

53

UML, histoire, généralité

54

Intro. Intro. UML ✓Histoire De Merise à UML

Pourquoi UML ?
➡ Objectifs : spéciﬁer, 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


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 uniﬁer les
modèles utilisés dans les méthodes

09/10 56 /99


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


Qu’est-ce qu’UML ?
un support à la modélisation
➡ Modèle : simpliﬁcation 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


➡ 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


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


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


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

survol

63

Intro. Intro. UML ✓Survol De Merise à 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


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


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


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


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


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ériﬁcation

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


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éciﬁcation complète et exécutable
Pas vraiment disponible actuellement !

Jean-Paul Rigault 2005
09/10 70 /99


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 ﬂots lors du processus de
développement
A venir dans
09/10 71 /99 le cours

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


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, ﬁnalité, 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


 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


 Cycles de construction du SI
Cycle de vie : il mène du
Non déﬁni 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


 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


 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


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


 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


 Flux

09/10 80 /99


 Diagramme de Cas d’utilisation

09/10 81 /99


 Diagramme de Séquence

09/10 82 /99


 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


Le Modèle conceptuel des données (MCD)

09/10 84 /99


Le Diagramme de classes Pas forcément celui-ci

09/10 85 /99



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


Cycle de vie des objets (CVO)

09/10 87 /99


Diagramme d’états-transitions

09/10 88 /99


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 ﬂux.

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


Modèle conceptuel
des traitements
(MCT)

09/10 90 /99


Diagramme d’activités et de séquence

09/10 91 /99


Diagramme d’activités et de séquence

09/10 92 /99


 Niveau organisationnel
La formalisation organisationelle vise à Spéciﬁer 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


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 ﬂux
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


De l’analyse à la conception...
en UML

1. Capture des besoins : diagrammes de cas d’utilisation
2. Focus sur les ﬂots 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


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

Modélisation par Objets - Introduction - De Merise à UML

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Mais de Mireille Blay-Fornarino

Mais de Mireille Blay-Fornarino (12)

Último

Último (20)

Modélisation par Objets - Introduction - De Merise à UML