Modélisation UML-Cour PDF

1
Freddy Fabrice G
Institut Supérieur De Formation En Commerce Et Gestion
1
Bibliographique UML
UML 2.0 guide de référence

James Rumbaugh, Ivar Jacobson, Grady Booch
Editions Campus Press (2005)
UML 2.0
https://laurent-audibert.developpez.com/Cours-
UML/?page=mise-en-oeuvre-uml
UML 2.0 Superstructure et UML 2.0 Infrastructure
OMG (Object Management Group)
www.uml.org (2004).
UML
https://www.futura-
sciences.com/tech/definitions/informatique-
uml-3979/
Introduction UML 22 / 342

Etapes du Développement
Analyse des besoins

spécification
Déterminer les fonctionnalités du logiciel.
Conception
Codage
Tests
Essayer le logiciel sur des données d'exemple pour
s'assurer qu'il fonctionne correctement.
Maintenance
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 3 / 342

10
Modélisation
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 141 / 342
Modèle
Modèle
Un modèle est une représentation abstraite de la

réalité qui exclut
certains détails du monde réel.
Il permet de réduire la complexité d'un phénomène en

éliminant les
détails qui n'influencent pas son comportement de
manière significative.
Il reflète ce que le concepteur croit important pour la
compréhension et
la prédiction du phénomène modélisé, les limites du
phénomène
modélisé dépendent des objectifs du modèle.
Modélisation
Pourquoi Modéliser
orientée objets
Pour visualiser le système comme il est ou comme il devrait être.

De valider le modèle vis à vis des clients
De spécifier les structures de données et le comportementdu système.
De fournirun guide pour la constructiondu système.
De documenterle système et les décisions prises.
L’objectif de UML
est d’assister le design et le développementdu logiciel
C'est un langage de modélisation pas une
méthodologie
Modélisation orientée objets
Historique
Début des années 1990
Les premiers processus de développement OO apparaissent
Entre 1990 et 1994 : Plus de 50 méthodes objet sont apparues:

méthode OODde GradyBooch(1991)
méthode OMT de James Rumbaugh(1991)
méthode OOSE de Ivar Jacobson(1991)
méthode OOA/OODde Coadand Yourdon(1992)
méthode de Schlaerand Mellor(1992)
visualiser le système comme il est ou comme
il devrait être
Modélisation
L’arrivée d’UML
orientée objets
La Normalisation
UML devient une normede l’OMGen 1997

L’OMG(Object ManagementGroup) est un organisme créé en 1989 afin
de promouvoirdes standards (comme CORBApar exemple) qui
garantissent l’interopérabilitéentre des applications orientées objet
développées sur des réseaux hétérogènes.
Cet organismea été créé et est soutenu par des industriels comme HP,
Sun, Unisys, AmericanAirlines, Philips
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 18
5 / 342
UML
UML : UnifiedModelingLanguage
Langage de ModélisationUnifié.
Appliqué à l’analyse et à la conceptiondes logiciels.
Langage essentiellement graphique.
Facile à lire et à comprendre.
UML : norme qui définit les diagrammes et les conventionsà utiliser

lors de la constructionde modèles décrivantla structure et le
comportementd’un logiciel.
Les modèles sont des diagrammesconstitués d’éléments graphiques et
de texte.
UML n’est pas une méthode, mais un langage.
UML
L'UML(UnifiedModelingLanguageou Langage de modélisationunifiée en

français) est un langage graphique de modélisationinformatique.
Ce langage est désormaisla référenceen modélisationobjet, ou
programmationorientée objet. Cette dernièreconsiste à modéliser
des éléments du monde réel (immeuble, ingrédients,personne,logos, organes
du corps...) ou virtuel (temps, prix, compétence...)
en un ensemble d'entités informatiquesappelées « objet ».
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 1150/ 342
UML
L'UMLest constitué de diagrammesqui servent à visualiser et décrire
la structure et le comportementdes objets
qui se trouventdans un système. Il permet de présenterdes systèmes
logiciels complexes de manière plus simple et
compréhensiblequ'avec du code informatique.L'UMLa des
applications dans le développementlogiciel, mais aussi dans
l'industrie(pour modéliserles flux de processus par exemple), dans
l'ingénierieou le marketing.
L'UML1.0 a été adopté comme standardpar l'ObjectManagement

Group (OMG) en janvier 1997. Il est issu de la fusion
de trois méthodes orientées objet issues des travaux de GradyBooch,
de Jim Rumbaughet d'IvarJacobson.Des versions successives
ont ensuite été validées, la dernièreen date étant l'UML2.5.1.
UML
UML : UnifiedModelingLanguage
Langage de ModélisationUnifié.
Appliqué à l’analyse et à la conceptiondes logiciels.
Langage essentiellement graphique.
Facile à lire et à comprendre.
UML : norme qui définit les diagrammes et les conventionsà utiliser

lors de la constructionde modèles décrivantla structure et le
comportementd’un logiciel.
Les modèles sont des diagrammesconstitués d’éléments graphiques et
de texte.
UML n’est pas une méthode, mais un langage.
UML
EXEMPLE DE CARTE CONCEPTUELLE SUR LA PHOTOSYNTHÈSE EN UML RÉALISÉ AVEC LUCIDCHART
Modélisation
Définition d’un
orientée
diagramme
objets
Un diagramme UML est une représentation graphique, qui

s'intéresse à un aspect précis du modèle.
Chaque type de diagramme UML possède une structure (les
types des éléments de modélisation qui le composent sont
prédéfinis).
Un type de diagramme UML offre toujours la même vue d'un
système (il véhicule une sémantique précise).
Combinés, les différents types de diagrammes UML offrent une
vue complète des aspects statiques et dynamiques d'un système
Modélisationde
L’utilisation orientée
diagrammes
objets
Pour visualiser le système comme il est ou comme il devrait être.

De valider le modèle vis à vis des clients
De spécifier les structures de données et le comportementdu système.
De fournirun guide pour la constructiondu système.
De documenterle système et les décisions prises.
L’objectif de UML
est d’assister le design et le développementdu logiciel
C'est un langage de modélisation,pas une
méthodologie
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 1 5 1/5342
Modélisation
Logiciels de modélisation
orientée objets
UML
Aucun d'entreeux ne respecte strictement aucune des versions de UML,

particulièrementUML2
Logiciels open-source:ArgoUML,Papyrus UML, StarUML,BOUML
Logiciels payants: RationalRose ,EDGEDiagrammer,Visual Paradigm
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 1 5 /1 6
342
Modélisation orienté
orientéeobjets
objets
La Conception Orientée Objet (COO) est la méthode qui

conduit des architectures logicielles fondées sur les objets du
système,plutôt que sur une décomposition fonctionelle.
C'est la structure du système lui donnesa forme.
On peut partir desobjets du domaine (briques debase) et

remonter vers le système global : approche ascendante.
Attention, l'approche objet n'est passeulement ascendante.
7
Processus de développement en V
Analyse
«que doit faire Analyse et
le système ?» Vérification
« Fait t’il ce qui étais
demandé et le fait –il

Conception
correctement ?»
« Comment va-t-il
le réaliser ?»
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 1 6 / 342
Objectif de l’analyse
Comprendre les besoins du client pour établir,

pour rédiger le cahier des charges
fonctionnel
Trois questions
1.Definir les utilisateurs principales du systèmes :à quoi sert ’il ?
2.Définir l’ environnement du systèmes : qui va l’utiliser ou interagir avec

lui ?
3.Définir les limites du systèmes : ou s’arrête sa responsabilité
Eléments de description :
Diagramme de cas d’ utilisation
Description textuelle des cas d’ utilisation
Diagramme de séquences des scénarios d’utilisation Comprendre
9
Modélisation des besoins
Avant de développer un système, il faut savoir précisement

QUOI il devra servir, cad quels besoins il devra
répondre.
Modéliser les besoins permet de :

Faire l'inventaire des fonctionnalitées attendues ;
Organiser les besoins entre eux, de manière à
faire apparaitre des relations (reutilsations
possibles, ...).
Avec UML, on modélise les besoins au moyende
diagrammes de cas d'utilsation.
Pierre G rard (P13 IUT Villetaneuse) DUT Informatique S2D 1 82 /0 342

Diagrammes de cas d’utilisation
Objectifs
Lesdiagrammes de cas d'utilisation modélisent à QUOI

sert le syst me.
Le système est composé d'objets qui interagissent entre eux et
avec les acteurs pour réaliser ces cas d'utilisation.
Lesdiagrammes de classes permettent de spécier la structure et
les liens entre les objets dont le système est composé .
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 35 /2342
1
Exemple de diagramme de cas d'utilisation
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 19 2
/2342
Cas d'utilisation
Un cas d'utilisation est un service rendu l'utilisateur, il

implique des séries d'actions plus élémentaires.
Un acteurs est une entité extérieure au système modelisé

, et qui interagit directement avec lui.
Uncasd'utilisation estl'expressiond'un service réalisé de bout en bout, avec un

déclenchement, un déroulement et une fin, pour l'acteur qui l'initie.
3
Acteurs et cas d'utilisation
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 21 /2 342
4
Relations entre cas d'utilisation en acteurs
Lesacteursimpliqu s dansuncasd'utilisation lui sont li s par une

association.
Un acteur peut utiliser plusieurs fois le m me casd'utilisation.
/ 5342
Relations entre cas d'utilisation
Inclusion : le cas A inclut le cas B (B est une partie obligatoire

de A).
Extension : le cas B tend le cas A (A est une partie optionelle

de A).
Généralisation : le casA est unegénéralisation du cas B (B est

une sorte de A).
/6342
Dépendances d'inclusion et d'extension
Les inclusions et les extensions sont représentées par

des dépendances.
Lorsqu'un cas B inclut un cas A, B dépend de A.
Lorsqu'un cas B tend un cas A, B dépend aussi de A.
On note toujours la dépendance par une fèche
pointillée B −−·A qui se lit B dépend de A.
Losqu'un élément A dépend d'un élément B, toute modifcation
de B serasusceptible d'avoir un impact sur A.
Lesincude et les extend sont desstéréotypés (entre
guillements) des relations de dépendance.
Attention
Le sensdes flèches indique le dépendance, pasle sensdela relation d'inclusion.
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 24 2/ 7342
Réutilisabilité avec les inclusions et les extensions
Les relations entre cas permettent la reutilisabilition

du cas
s'authentifer : il serainutile dedévelopper plusieurs fois
un module d'authentifcation.
/8342
Décomposition grâce aux inclusions et aux
extensions
Quandun cas est trop complexe(faisant intervenir un trop grand

nombre d'actions), on peut procéder à sa décomposition en cas plus
simples
9
Généralisation
Un virement est est un cas

particulier de paiement.
Un virement est une sorte de

paiement.
La flèche pointe vers l' élément général.

Cette relation de généralisation/spécialisation est présente dans la
plupart des diagrammes UML et se traduit par le concept d'héritage
dans les langages orientés objet.
/0342
Relations entre acteurs
Une seule relation possible : la généralisation.
28
Identification des acteurs
Lesprincipaux acteurs sont les utilisateurs du syst me.

Attention
Un acteur correspond à un rôle le, pas une personne physique.
Une même personne physique peut être représentée par plusieurs

acteurs si elle a plusieurs rôles.
Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles
seront représentées par un seul acteur.
En plus des utilisateurs, les acteurs peuvent ê t r e :
Des périphériques manipulés par le système (imprimantes...) ;
Des logiciels déjà disponibles à intégrer dans le projet ;
Des systèmes informatiques externes au système mais qui interagissent
avec lui, etc .
Pour faciliter la recherche des acteurs, on se fonde sur les frontières du
système.
342
Acteurs principaux et secondaires
L'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est
l'initiative des changes nécessaires pour réaliser le cas d'utilisation.
Lesacteurs secondaires sont sollicités par le système alors quele

plus souvent, les acteurs principaux ont l'initiative desinteractions.
Le plus souvent, les acteurs secondaires sont d'autres systèmes
informatiques avec lesquels le système développé est inter-connect .
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 33
Recenser les cas d'utilisation
Il n'y apasunemanière m canique et totalement objective derep rer

les cas d'utilisation.
Il faut se placer du point de vue de chaque acteur et déterminer
comment il se sert du système, dans quels cas il l'utilise, et quelles
fonctionnalités il doit avoir accès.
Il faut viter les redondances et limiter le nombre de cas en se situant
au bon niveau d'abstraction (par exemple, ne pas r duire un cas une
seule action).
Il ne faut pas faire appara tre les d tails des cas d'utilisation, mais il
faut rester au niveau des grandes fonctions du syst me.
Trouver le bon niveau de détail pour les cas d'utilisation est un problème
difficile qui nécessite de l'expérience.
/4342
Description des cas d'utilisation
Le diagramme decasd' utilisation décrit les grandes fonctions

d'un système du point de vue des acteurs, mais n'expose pas de
façon détaillée le dialogue entre les acteurs et les cas
d'utilisation.
Un simple nom est tout fait insuffisant pour décrire un
casd'utilisation.
Chaque cas d‘ utilisation doit être documenté pour qu‘ il n'y ait aucune
ambiguïté concernant son déroulement et ce qu‘ il recouvre précisément.
.
/5342
Description textuelle
Identification :
Nom du cas : Payer CB
Objectif : Détailler les tapes permettant à client de
payer par carte bancaire
Acteurs : Client, Banque (secondaire)
Date : 18/09
Responsables :
Toto
Sequencements :
Le cas d'utilisation commence lorsqu'un client demande le paiement
par carte bancaire
Pré-conditions
Le client a validé sa commande
Enchaînement nominal
1 Le client saisit les informations de sa carte bancaire
2 Le système vérifie que le numéro de CB est correct
3 Le système vérifie la carte auprès du système bancaire
4 Le système demande au système bancaire de débiter le client
5 Le système notie le client du bon déroulement de la transaction
Enchaînements alternatifs
1 En (2) : si le numéro est incorrect, le client est averti de l'erreur, et
invité à recommencer
2 En (3) :si les informations sont erronées, elles sont re-demandées au
client
Post-conditions
La commande est validée
Le compte de l'entreprise est crédité
7
Rubriques optionnelles
Contraintes non fonctionnelles :
Fiabilité : les accès doivent être sécurisés
Confidentialité : les informations concernant le client ne
doivent pas
être divulgués.
C o n t r a in t e s l ié e s à l ' in t e r f a c e h o m m e- m a ch in e :
Toujours demander la validation des opérations bancaires
8
Diagrammes de classes
Objectif
s
Lesdiagrammes de cas d'utilisation modélisent à QUOI
sert le système.
Le système est composé d'objets qui interagissent entre eux et
avec les acteurs pour réaliser ces cas d'utilisation.
Les diagrammes de classes permettent de spécifier la structure et
les liens entre les objets dont le système est composé. .
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 353/9342
Exemple de diagramme de classes
Concepts et instances
Uneinstance est la concrétisation d'un concept abstrait.

Concept : Stylo
Instance : le stylo que vous utilisez à ce moment précis est une instance
du concept stylo : il a sa propre forme, sa propre couleur, son propre
niveau d'usure, etc.
Un objet est une instance d'une classe
Classe : Vidéo
Objets : Pink Floyd (Live à Pompey), 2001 Odyssée de l'Espace etc.
Une classe décrit un type d'objets concrets..
Une classe spécifie la manière dont tous les objets de même type seront
décrits (désignation, label, auteur, etc).
Un lien est uneinstance d'association.
Association : Concept avis d'internaute qui lie commentaire et
article
Lien : instance [Jean avec son avis négatif], [Paul avec son avis
positif]
1
Classes et objets
Uneclasse est la description d'un ensemble d'objets ayant une

sémantique, desattributs, desméthodes et des relations en commun. Elle
spécifie l'ensemble des caractéristiques qui composent des objets de
meme type.
Une classe est

composée d'un nom,
d'attributs et
d'opérations.
Selon l'avancement
de la modélisation,
ces
informations ne sont pas
forcement toutes connues.
D'autres compartiments peuventêtre ajoutés : responsabilités,
exceptions, etc.
/2342
Propriétés : attributs et opérations
Lesattributs et les opérations sont les propriétés d'une

classe. Leur nom commence par une minuscule.
Un attribut décrit une donnée de la classe.
Les types des attributs et leurs initialisations
ainsi que les modificateurs accès peuvent
être précisés dans le modèle
Les attributs prennent des valeurs lorsque la
classe est instanciée : ils sont en quelque sorte
des variables attachées aux objets.
Une opération est un service offert par la classe (un
traitement que les objets correspondant peuvent
effectuer).
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 39 / 4 3
342
Compartiment des attributs
Un attribut peut être initialisé et sa visibilité est définie

lors de sa
déclaration.
/ 4
342
Types de base
II existe huit type de base en java.
Les types entier : byte, short, int ,long

Un types caractère : char.
Un type booléen: booléen.
Deux types flottants : float et double.
342
Types base en java
Types de Types Nombres de Valeurs
base bits possibles
boolean booléen 32 (effectifs) true et false
byte entier 8 signées
short entier 16 signées
int entier 32 signées
entier 64 signées
long
float virgule 32 IEEE 754

flottante
double virgule 64 IEEE 754

flottante
char caractère 16 Unicode
6
Relations entre classes
Unerelation d'héritage est une relation de

généralisation/spécialisation permettant l'abstraction.
Unedépendance est une relation unidirectionnelle exprimant
une
dépendances semantique entre les éléments du modèle.
Uneassociation represente unerelation sémantique entre les
objets d'une classe.
Unerelation d'agrégation décrit unerelation de contenance
ou de composition.
7
Association
Une association est une relation structurelle entre objets.

Une association est souvent utilisée pour représenter
les liens posibles entre objets de classes données.
Elle est représentée par un trait entre classes.
8
Multiplicités des associations
Nombre d’objets de la classe B associés à un objets de
la classe A
A n B
Exactement n
n,m,p
A B Exactement n ou
m ou p
n..m
A B Entre n et m
n..*
A B Au moins n
A * B Plusieurs(0
ou plus)
9
Nombre d’objets de la classe B associés à un objet de la
classe A
1
Exactement 1
0..1
Au plus 1 (0 ou 1)
1..*
Au moins 1(jamais 0)
*
0 ou plus

0
La notion demultiplicité permet le controle du nombre d'objets

intervenant danschaque instance d'une association.
Exemple : un article n'appartient qu'a une seule
catégorie (1) ; une catégorie concerne plus de 0 articles,
sans maximum (*).
La syntaxe est MultMin..MultMax.

* la place de MultMax signifie plusieurs sans
préciser de nombre.
n..n se note aussi n , et 0..* se note * .

1
Navigabilité d'une association
La navigabilité permet de spécifier dansquel(s) sensil est

possible de traverser l'association l'exécution.
On restreint la navigabilité d'une association à un seul sens à
l 'aide d'une flèche.
Exemple : Connaissant un article on connait les

commentaires, mais pas l'inverse.
On peut aussi représenter les associations navigables dansun seul
sens par des attributs.
Exemple : En ajoutant un attribut
<<avisInternaute> > de classe
<<Commentaire> > à la place de l'association.
2
Association unidirectionnelle de 1 vers 1
3
Association bidirectionnelle de 1 vers 1
4
Association unidirectionnelle de 1 vers *
342
Implantation d'une association
bidirectionnelle de * vers *
Plus difficile : gérer à la fois la cohérence et les collections
342
Associations réflexives
L'association la plus utilisée est l'association binaire (reliant

deux classs).
Parfois, les deux extrémitées de l'association pointent vers le
meme classeur. Dans ce cas, l'association est dite
<<réflexive>> .
/7342
Classe-association
Une association peut être ranée et avoir ses propres attributs, qui ne
sont disponibles dans aucune des classes qu'elle lie.
Comme, dans le modèle objet, seules les classes peuvent avoir des
attributs, cette association devient alors une classe appelée.
55
Associations n-aire
Une association n-aire lie plus de deux classes.

Notation avec un losange central pouvant
éventuellement accueillir une classe-association.
La multiplicitée de chaque classe s'applique une
instance du losange.
Lesassociationsn-airessont peufréquenteset concernentsurtout lescasoùlesmultplicitéssonttoutes *

Danslaplupartdescas,on utiliseraplusavantageusement
desclasses-associationouplusieursrelationsbinaires.n ou plusieurs relations binaires.
/9342
Association de type agrégation
Une agrégation est une forme particulière

d'association. Elle represente la relation
d'inclusion d'un element dans un ensemble.
On représente l'agrégation par l'ajout d'un
losange vide du coté de l'agrégat.
Uneagrégation note unerelation d'un ensemblesesparties.

L'ensemble est l'agrégation et la partie l'agrégé .
/0342
Association de type composition
La relation decomposition décrit unecontenance structurelle
entre instances. On utilise un losange plein.
La destruction et la copie de l'objet composite (l'ensemble) impliquent

respectivement la destruction ou la copie de ses composants (les parties).
Une instance de la partie n'appartient jamais à plus d'une instance de l'

element composite.
1
Composoition et agrégation
Dès lors que l'on a une relation du tout à sa partie, on a une

relation d'agrégation ou de composition.
La composition est aussi dite agrégation forte .

Pour décider de mettre une composition plutôt qu'une
agrégation, on doit se poser les questions suivantes :
Est-ce que la destruction de l'objet composite (du
tout) implique nécessairement la destruction des
objets composants (les parties) ? C'est le cas si les
composants n'ont pas d'autonomie vis- -vis des
composites.
Lorsque l'on copie le composite, doit-on aussi copier les
composants,
ou est-ce qu'on peut les réutiliser, auquel cas un
composant peut faire partie de plusieurs composites ?
Si on répond par l'affirmative à cesdeux questions, on doit utiliser une

2
Relation d'héritage
L'héritage une relation de

spécialisation/généralisation.
Les éléments spécialisés

héritent de la structure
et du comportement des
élémentsplus généraux
(attributs et opérations)
Exemple : Par héritage

d'Article, un livre a
d' office un prix, une
désignation et une
opération acheter(), sans
qu'il soit nécessaire de le
préciser
342
Relation d’héritage et propriétés
La classe enfant possède toutes les

propriétés de ses classes parents (attributs et
opérations)
La classe enfant est la classe spécialisée
(ici Livre) La classe parent est la classe
générale (ici Article)
Toutefois, elle n'a pas accès aux propriétés
privées.
342
Classes abstraites
Une méthodeest dite abstraite lorsqu'onconnaîtson entête mais pas

la manièredontelle peut êtreréalisée.
Ilappartient auxclasses enfant de definir methodesabstraites.
Uneclasseest dite abstraite lorsqu'elle définit au moins une

méthode abstraite ou lorsqu'une classe parent
contient une méthode abstraite non encore réalisé
5
Attributs de classe
Pardéfaut, lesvaleurs des attributs définis dans une classe

diffèrent d'un objet à un autre. Parfois, il est nécessaire de
définir un attribut de classe qui gardeunevaleur unique et
partagée par toutes les instances.
Graphiquement, un attribut de classe est souligné
6
Opérations de classe
Semblable aux attributs de classe

Une opération de classe est une propriété de la
classe, et non de ses instances.
Elle n'a pas accès aux attributs des objets de la
classe.
7
Diagrammes de classes à differentes étapes de la
conception
On peut utiliser les diagrammes declassespour représenter un système à

différents niveaux d'abstraction :
Le point de vue spécification met l'accent sur les interfaces des
classes plutôt que sur leurs contenus.
Le point de vue conceptuel capture les concepts du domaine et les
liens qui les lient. Il s'intéresse peu à la manière eventuelle
d'implémenter ces concepts et relations et aux langages
d'implantation.
Le point de vue implantation, le plus courant, détaille le contenu
et l'implantation de chaque classe.
Lesdiagrammes declassess'etoffent à mesurequ'on va dehauts niveauxdebas
niveauxd'abstraction(dela spécification vers l'implantation)
8
Construction d'un diagramme de classes
1
Trouver les classes du domaine étudier ;
Souvent, concepts et substantifs du domaine.
2
Trouver les associations entre classes ;
Souvent, verbes mettant en relation plusieurs classes.
3
Trouver les attributs des classes;
Souvent, substantifs correspondant à un niveau de
granularité plus f i n que les classes. Les adjectifs et
les valeurs correspondent souvent à des valeurs
d'attributs.
4
Organiser et simplifier le modèle en utilisant
5
l'heritage ; Tester les chemins d'accès aux classes ;
6
Itérer et raffiner le modèle.
9
Objectif
Le diagramme d'objets représente les objets d'un

système à un instant donnée. Il permet de :
D’illustrer le modèle de classes (en montrant un
exemple qui explique le modèle) ;
Préciser certains aspects du système (en mettant en
vidence des
détails imperceptibles dans le diagramme de classes) ;
Exprimer une exception (en modélisant des cas
particuliers, des connaissances non
généralisables. . . ).
Le diagramme declassesmod lise des regleset le

diagramme d'objets mod lise des faits
0
Représentation des objets
Commeles classes, on utilise des cadres compartimentés.

En revanche, les noms des objets sont soulignés et on
peut rajouter son identifant devant le nom de sa classe.
Les valeurs (a) ou l' état (f) d'un objet peuvent etrespécifiés
Lesinstances peuvent etre anonymes (a,c,d), nommées
(b,f), orphelines (e), multiples (d) ou stéréotypées (g).
1
Diagramme de classes et diagramme d'objets
Le diagramme declassescontraint la structure et les liens entre les

objets.
Diagramme cohérent avec le diagramme de classes

:
2
Liens
Un lien est une instance d'une association.

Un lien sereprésente commeuneassociation mais s'il aun nom, il est
souligné.
Attention
Naturellement, on ne représente pas multiplicités qui n'ont aucun sensau
niveau des objets.
3
Relation de dépendance d'instanciation
La relation de dépendance d'instanciation

(stéréotypée) décrit la relation entre un classeur et
ses instances .
Elle relie, en particulier, les associations aux liens et
aux liens et les classes aux objets .
4
Objectif des diagrammes de séquence
Lesdiagrammes de cas d'utilisation mod lisent QUOI sert le syst

me, enorganisant les interactions possibles avecles acteurs.
Lesdiagrammes de classes permettent desp ci er la structure et lesliens
entre les objets dont le syst me est compos : ils sp ci e QUI
sera l'oeuvre dans le syst me pour r aliser les fonctionnalit s d crites par
les diagrammes decasd'utilisation.
Lesdiagrammes de s quences permettent ded crire COMMENT les l
ments du syst me interagissent entre eux et avecles acteurs.
Les objets au coeur d'un syst me interagissent en s'
changent des messages.
Les acteurs interagissent avec le syst me au moyen d'IHM
(Interfaces
Homme-Machine).
5
Exemple d'interaction
Cas d'utilisation :
Diagramme de séquences correspondant

:
6
Exemple d'interaction
Diagramme de séquences
correspondant :
Opérations necessaires dans le diagramme de

classes :
7
Ligne de vie
Uneligne devie représente un participant uneinteraction (objet
ou acteur).
nomLigneDeVie[ selecteur]: nomClasseOuActeur
Dans le casd'une collection departicipants, un selecteur
permet de choisir un objet parmi n (par exemple objets[2] ).
78
Messages
Lesprincipales informations contenues dans un diagramme de

séquence sont les messages échangés entre les lignes devie,
présentés dans un ordre chronologique.
Un message définit une communication particulière entre
des lignes de vie (objets ou acteurs).
Plusieurs types de messages existent, dont les plus courants :
l'envoi d'un signal ;
l'invocation d'une opération (appel de
métho de) ; la création ou la destruction
d'un objet.
La réception desmessagesprovoque unepériode d'activité
(rectangle vertical sur la ligne devie) marquant le traitement du
message
(spécification d'exécution dans le cas d'un appel de méthode).
Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 87 / 7 9

342
Principaux types de messages
Un message synchrone bloque l'expéditeur jusqu'à la
réponse du destinataire. Le flot decontrôle passede
l'émetteur au récepteur.
Typiquement : appel de méthode
Si un objet A invoque une m é thode d'un objet B, A reste bloqué
tant que B n'a pas terminé .
On peut associer aux messages d'appel de méthode un message de

retour (en pointillés) marquant la reprise du contrôle par l'objet
émetteur du message synchrone.
Un message asynchrone n'est pas bloquant

pour l'expéditeur.
Le message envoyé peut être pris en compte par le récepteur à
tout
moment ou ignoré .
Typiquement : envoi de signal (voir st r otype de classe signal ) .
342
Correspondance messages / opérations
Lesmessages synchrones correspondent desop2rations dansle

diagramme de classes.
Envoyerunmessageet attendre la réponsepour poursuivresonactivités

revient invoquer uneméthode et attendre le retour pour poursuivre ses
traitements.
342
Création et destruction de lignes de vie
La création d'un objet est matérialisé par une flèche qui pointe
sur le sommet d'une ligne de vie.
On peut aussi utiliser un message asynchrone ordinaire
portant le nom
<<create>> .
La destruction d'un objet est matérialisée par une croix qui

marque la fin de la ligne de vie de l'objet.
2
Messages complets, perdus et trouvés
Un message complet est tel que les évènements

d'envoi et de réception sont connus.
Un message complet est représenté par une f l è che partant
d'une ligne de vie et arrivant une autre ligne de vie.
Un message perdu est tel quel'évènement d'envoi est
connu, mais pas l'évènement de réception.
La f lè che part d'une ligne de vie mais arrive sur un cercle indé
pendant marquant la méconnaissance du destinataire.
Exemple : broadcast.
Un message trouv est tel quel'évènement deréception

est connu, mais pas l' évènement d' émission.
3
Syntaxe des messages
La syntaxe des messages est :

nomSignalOuOperation( parametres)
La syntaxe des arguments est la suivante :

nomParametre= valeurParametre
Pour un argument modifable :

nomParametre: valeurParametre
Exemples :
appeler("Capitaine Hadock", 54214110)
afficher(x,y)
initialiser(x=100)
f(x:12)
4
Messages de retour
Le récepteur d'un messagesynchrone rend la main l'émetteur

du message en lui envoyant un message de retour
Les messages de retour sont

optionnels : la f i n de la
période d'activité marque
é galement la fin de
l'exècution d'une méthode.
Ils sont utilisés pour spécifier le
résultat de la méthode invoquée.
Le retour desmessagesasynchrones s'effectue par l'envoi de

nouveaux messages asynchrones.
5
Syntaxe des messages de retour
La syntaxe des messages de retour est :

a t t r i b u t C i b l e = n o m O p e r a t i o n ( p a r a m s ): v a l e u r R e t o u r
La syntaxe des param tres est :

nomParam=valeurParam
ou
nomParam:valeurParam
Lesmessages de retour sont représentés en pointillés.
6
Fragment combiné
Unfragment combiné permet de décomposerune

interaction complexe enfragments suffisamment simples
pour ê t r e compris.
Recombiner les fragments restitue la complexit .
Syntaxe compl te avec UML2 : représentation complète de
processus avec un langage simple (ex : processus parallèles).
Un fragment combiné se représente de la même façon qu'une
interaction. Il est représenté un rectangle dont le coin supérieur
gauche contient un pentagone .
Dans le pentagone f i gure le type de la combinaison (appele
opérateur d'interaction ) .
342
Exemple de fragment avec l'opérateur conditionnel
8
Type d'opérateurs d'interaction
Opérateurs de branchement ( choix et boucles) :

alternative, option, break et loop ;
Opérateurs controlant l'envoi en parallèle de
messages :
parallele et critical region ;
Opérateurs controlant l'envoi de messages :
ignore, consider, assertion et negative ;
Opérateurs fixant l'ordre d'envoi des messages :
weak sequencing et strict sequencing.
9
Opérateur de boucle
DUT Informatique S2D 100 /

Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 9342
0
Syntaxe de l'opérateur loop
Syntaxe d'une boucle :

loop ( min Nb Iterations , max Nb I t e rat ions )
La boucle est répétée au moins minNbItérationsfois avant qu'une

éventuelle condition booléenne ne soit testée (la condition est placée
entre crochets dans le fragment) .
Tant que la condition est vraie, la boucle continue, au plus
maxNbItérations fois.
Notations :
loop(valeur) est quivalent loop(valeur,valeur) .
loop est quivalent loop(0,*) , o * signife <<
illimité>>.

1
Opérateur parallèle
L'opérateur par permet d'envoyer desmessages en parallèle.

Ce qui se passe de part et d'autre de la ligne pointillée est
indépendant.

2
Réutilisation d'une interaction
Réutiliser une interaction consiste à placer un fragment
portant la référence <<ref >> là ou l'interaction est utile.
On spécifie le nom de l'interaction dans le fragment.

3
Utilisation d'un DS pour modéliser un cas
d'utilisation
Chaque cas d'utilisation donne lieu un diagramme de

séquences
Lesinclusions et les extensions sont des cas typiques d'utilisation

de la réutilisation par référencement

4
Utilisation d'un DS pour spécifier une méthode
Uneinteraction peut être identifiée par un fragment sd (pour

pour
sequence diagram )précisant son nom
Un messagepeut partir du bord de l'interaction, specifiant le
comportement du système après réception du message,quel que
soit l'expéditeur

5
Exemple de diagramme de séquence système

6
Opérations système
Lesopérations système sont desopérations qui devront être

réalisées par l'une ou l'autre desclassesdu système.
Elles correspondent à tous les messages qui viennent des acteurs
vers le système dans les differents DSS.
7
Des séquences système aux interactions internes

8
Modèles de cycles de vie linéaire
Lesphasesdu développement sesuivent dansl'ordre et sansretour

enarrière.

9
Modèles de cycles de vie linéaire
Lesphasesdu développement sesuivent dansl'ordre et sansretour

enarrière.

00
Problèmes des cycles linéaires
Risques élevés et non contrôlés :

Identification tardive des problèmes ;
Preuve tardive de bon fonctionnement;
<< E f f e t tunnel.
Améliorations : construction itérative du système :
Chaque itération produit un nouvel incrément ;
Chaque nouvel incrément a pour objectif la maîtrise d'une partie des
risques et apporte une preuve tangible de faisabilité ou
d'adéquation :
Enrichissement d'une série de prototypes ;
Les versions livrées correspondent à des tapes de la
chaîne des
prototypes.

01

Modélisation UML-Cour PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Modélisation UML-Cour PDF

Transféré par

Droits d'auteur :

Formats disponibles

1

UML 2.0 guide de référence

Introduction UML 22 / 342

Analyse des besoins

Pierre G rard (P13 IUT Villetaneuse) Introduction UML 2 3 / 342

Un modèle est une représentation abstraite de la

Il permet de réduire la complexité d'un phénomène en

Pour visualiser le système comme il est ou comme il devrait être.

Début des années 1990

Les premiers processus de développement OO apparaissent

Entre 1990 et 1994 : Plus de 50 méthodes objet sont apparues:

UML devient une normede l’OMGen 1997

UML : norme qui définit les diagrammes et les conventionsà utiliser

L'UML(UnifiedModelingLanguageou Langage de modélisationunifiée en

L'UML1.0 a été adopté comme standardpar l'ObjectManagement

UML : norme qui définit les diagrammes et les conventionsà utiliser

EXEMPLE DE CARTE CONCEPTUELLE SUR LA PHOTOSYNTHÈSE EN UML RÉALISÉ AVEC LUCIDCHART

Un diagramme UML est une représentation graphique, qui

Pour visualiser le système comme il est ou comme il devrait être.

Aucun d'entreeux ne respecte strictement aucune des versions de UML,

Logiciels open-source:ArgoUML,Papyrus UML, StarUML,BOUML

Logiciels payants: RationalRose ,EDGEDiagrammer,Visual Paradigm

La Conception Orientée Objet (COO) est la méthode qui

C'est la structure du système lui donnesa forme.

On peut partir desobjets du domaine (briques debase) et

Attention, l'approche objet n'est passeulement ascendante.

« Fait t’il ce qui étais

demandé et le fait –il

Comprendre les besoins du client pour établir,

2.Définir l’ environnement du systèmes : qui va l’utiliser ou interagir avec

3.Définir les limites du systèmes : ou s’arrête sa responsabilité

Description textuelle des cas d’ utilisation

Diagramme de séquences des scénarios d’utilisation Comprendre

Avant de développer un système, il faut savoir précisement

Modéliser les besoins permet de :

Pierre G rard (P13 IUT Villetaneuse) DUT Informatique S2D 1 82 /0 342

Lesdiagrammes de cas d'utilisation modélisent à QUOI

Un cas d'utilisation est un service rendu l'utilisateur, il

Un acteurs est une entité extérieure au système modelisé

Uncasd'utilisation estl'expressiond'un service réalisé de bout en bout, avec un

Lesacteursimpliqu s dansuncasd'utilisation lui sont li s par une

Inclusion : le cas A inclut le cas B (B est une partie obligatoire

Extension : le cas B tend le cas A (A est une partie optionelle

Généralisation : le casA est unegénéralisation du cas B (B est

Les inclusions et les extensions sont représentées par

Les relations entre cas permettent la reutilisabilition

Quandun cas est trop complexe(faisant intervenir un trop grand

Un virement est est un cas

Un virement est une sorte de

La flèche pointe vers l' élément général.

Une seule relation possible : la généralisation.

Lesprincipaux acteurs sont les utilisateurs du syst me.

Une même personne physique peut être représentée par plusieurs

Lesacteurs secondaires sont sollicités par le système alors quele

Il n'y apasunemanière m canique et totalement objective derep rer

Le diagramme decasd' utilisation décrit les grandes fonctions

ambiguïté concernant son déroulement et ce qu‘ il recouvre précisément.

Uneinstance est la concrétisation d'un concept abstrait.

Uneclasse est la description d'un ensemble d'objets ayant une

Une classe est

Lesattributs et les opérations sont les propriétés d'une

Un attribut peut être initialisé et sa visibilité est définie

II existe huit type de base en java.