Chapitre 2-2020 PDF

Cours UML, Chapitre 2, Analyse statique
Chapitre 2 : Modélisation statique

Considérer par la plupart des méthodes comme la plus importante, la modélisation statique
aborde les principales difficultés liées à l’analyse et la modélisation orientée objet. Nous
apprendrons donc à identifier les classes, les objets, les attributs, les associations et les
opérations à partir de l’expression des besoins du système. Trois types de classes d’analyse
seront distingués : les classes de « dialogues » qui représentent les moyens d’interaction avec
le système, les classes de « contrôles » qui contiennent la logique applicative et les « entités »
qui sont les objets métier manipulés. Nous consignerons les résultats de la modélisation
statique dans un diagramme UML que nous appellerons diagramme de classes. Nous verrons
par la suite comment organiser les classes en packages. Un regard sera également porté sur la
façon donc le diagramme de classes peut être enrichi en utilisant le langage de contraintes
objet OCL (Object Constraint Language).
Mots clés : Classe, objet, Opération, Association, multiplicité, Attribut, attribut dérivé,
Agrégation, composition, Classe d’association, qualificatif, Contrainte, Package,
Généralisation, classe abstraite, Agrégation – composition, Généralisation– spécialisation,
Classe abstraite – classe concrète, Contrainte, Qualificatif, Pattern, Classe structurée –
participant – rôle – connecteur, Diagramme de structure composite
I. Objet
D’après Rumbaugh, un objet est une entité du monde réel dotée d’un identifiant unique ayant
une frontière bien circonscrite qui dispose d’un état et d’un comportement. L’état d’un objet
représente l’ensemble de ses données propres correspondant aux valeurs de ses attributs. Le
comportement d’un objet est une collection des moyens communément appelés opérations
qu’il utilise pour effectuer les tâches qui lui sont affectées. Les opérations sont généralement à
l’origine de la modification de l’état d’un objet.
Exemple 1 : Etats et comportements
Téléphone
Etat Comportement
Numéro de série Allumer()
Marque Eteindre()
allumé PrendrePhoto()
Produit
Etat Comportement
Numéro Enregistrer()
Quantité en stock augmenterStock(nbre)
Désignation afficherPrixTotalStock()
Prix unitaire afficherAlerte()
Exemple 2 : Objets ayant une existence propre
 Le capteur que Khadidja tient en main
 La station de base qui est située au quartier Aronn
 Le devis proposé par l’entreprise ITSoftExpert au mois de Juin
1
IUT de Ngaoundéré : Année académique 2017-2018
a) Notion UML des objets

UML préconise de souligner les noms des objets et de débuter chaque nom par un lettre
minuscule. Lorsqu’un nom est composé, la convention lowerCamelCase qui consiste dans le
cas d’espèce à commencer le début du mot suivant par une majuscule est recommandée. Pour
séparer le nom de l’instance (objet) de celui de sa classe, le caractère « : » est utilisé.
Concernant les objets anonymes, seule le caractère « : » suivi du nom de la classe est employé
pour les nommer.
Les différentes syntaxes utilisées sont : nomObjet:nomClasse ou : :nomClasse
Exemple : théVertMenthe :Produit, samsungS5Awa92cm :Téléphone, :Employé
Graphiquement, UML représente un objet comme suit :
samsungS5 Awa92cm : Téléphone
NuméroSérie : 2560NND7
Marque : Samsung
Allumé : 0
b) Liens entre objets
Le lien est le concept UML utilisé pour mettre en relations les objets. Il représente une
instance d’une association entre objets. Généralement, les liens entre objets sont
bidirectionnels pour signifier que les objets participants à la relation peuvent s’envoyer
mutuellement des messages. L’utilisation d’un lien unidirectionnel d’un objet A vers un objet
B illustre que l’envoie de message est uniquement de A vers B. Autrement dit l’objet A
connait l’objet B mais pas l’inverse.
Exemple :
Marque : Samsung
Allumé : 0 Possède
Awa : Employé
Est
Identifiant : 25692
Nom : Awa
dateNaissance : 02/02/1992
typeSamrtP022 : TypeTéléphone
Identifiant : 5465
libellé : Smartphone
2
c) Diagramme d’objets
Le diagramme d’objet est le concept UML utilisé pour représenter les objets et les relations
qui existent entre eux. Il est généralement employé pour mettre en évidence un exemple des
situations complexes entre concepts du domaine à l’étude. Ce diagramme est souvent
considéré comme facultatif car le diagramme de classe est souvent suffisant pour décrit le
système étudié.
Exemple :
Marque : Samsung
Allumé : 0 Possède
Awa : Employé
Est
Identifiant : 25692
Nom : Awa
dateNaissance : 02/02/1992
typeSamrtP022 : TypeTéléphone Chef

Identifiant : 5465 Travaille
libellé : Smartphone
serviceIT033 : Service
Identifiant : 336
Nom : Télécommunications
II. Classe
Selon Rumbaugh, une classe est un modèle abstrait regroupant les objets possédant les mêmes
caractéristiques à savoir les mêmes attributs, opérations et relations. A cet effet, la classe
décrit la structure d’un objet (aspect statique), son comportement (aspect dynamique) et ses
relations. Plus simplement, une classe est le type d’un objet.
Exemple : Awa, Aziza, khadidja sont des instances de la classe Employé
Exercice d’application : comment classifier les animaux suivants ? Poisson, chat, requin,
loup et mouton.
Réponse : Animal, AnimalTerrestre/AmimalMarin, AnimalDomestique/AminialSauvage,
AnimalComestible/AnimalNonComestible, Mamifère/Poison…).
3
a) Classe et objets
Comme signalé précédemment, un objet est une instance d’une classe. UML emploie dont la
relation de dépendance stéréotypée par le mot clef « instantiate » pour illustrer la relation
entre une classe et ses objets.
Exemple :
Service
Identifiant
« instantiate » Nom : « instantiate »
Télécommunications
serviceIT033 : Service serviceClient012 : Service

Identifiant : 336 Identifiant : 150
Nom : Télécommunications Nom : Service client
b) Nom d’une classe

Il est souhaitable d’utiliser la convention UpperCamelCase pour attribuer les noms aux
classes. Le nom d’une classe est en minuscule avec la première en majuscule. Lorsqu’un le
nom d’une classe est composé, chaque mot composant débute par une lettre majuscule.
Exemple : Service, TypeTéléphone
Il est conseillé d’éviter d’abréger les noms des classes comme LigneLV au profit de
LigneLivraison.
c) Notion de visibilité
La visibilité en UML définie le niveau d’encapsulation des attributs et des opérations dans les
classes. Les standards utilisés sont :
 Public (+) : Accès depuis la même classe et à l’extérieur de la classe ;
 Protégé(#) : Accès depuis la même classe et les classes descendantes ;
 Privé(-) : Accès depuis la même classe uniquement ;
 Paquetage(~) : Accès depuis la même classe et toutes les classes du même paquet.
Notons que, pendant la phase d’analyse, la visibilité n’est pas importante.
d) Attributs d’une classe
Les attributs permettent de caractériser les propriétés d’une classe ou d’une association. Un
attribut possède un domaine qui définit l’ensemble des valeurs possibles qu’il peut prendre
(entier, chaîne de caractères, booléen, tableau, liste, …). A ce titre, un attribut représente le
type d’information contenu dans une classe ou une association. Dans un objet ou un lien,
chaque attribut possède une valeur compatible avec son domaine. La syntaxe formelle des
attributs est : [-,#,+,~] nomAttribut : TypeAttribut [multiplicité] [=valeurInitiale].
4
Dans ce formalisme, la multiplicité décrit le nombre de valeurs dans une collection qui peut
être un tableau ou une liste. Quand elle est définie, la valeur initiale indique, la valeur que
prend une instance d’une classe à sa création.
Exemple: email: string [0..1], , point :float[2], droite: point[2..*], pays: String = Cameroun
Notons qu’il peut arriver qu’un attribut appartienne à une classe et non à une instance
singulière de la classe. Dans ce cas, il est dit statique et est souligné lors de sa représentation.
e) Opération dans une classe
Comme précisé précédemment, une opération est un service contenu dans une classe. La
syntaxe formelle des opérations est :
[-,#,+,~] nomOpération (direction nomParamètre1 :Type=valeur,…) : typeRetour.
Les noms des opérations obéissent également la convention lowerCamelCase. Il est conseillé
d’utiliser une expression verbale pour les nommer. La direction indique si le paramètre sur la
signature de l’opération est une variable d’entrée (in param), d’entrée/sortie (inout param),
de sortie (out param) et de retour (return param).
Exemple: chercherServiceParNom(nom:string):void, calculePrixTotalProduitStock():float.
Notons également qu’à l’instar des attributs statiques, les opérations statiques sont notées en
souligné.
f) Notation UML d’une classe
La notation plus généralisée d’une classe en UML est :
« nom stéréotype » « entity »
nomClasse Service
Visibilité Attribut1 : type1 - identifiant : int
Visibilité Attribut2 : type2 - nom : string
… …
Visibilité nomOpération1() : type1 +chercherServiceParNom(nom:string):void
Visibilité nomOpération2() : type2 - ajouterUnService(nom:string) : void
… +nombreService():int
tags (métadonnées) tags
auteur auteur=khadidja
date,… date=23/09/2016
Malgré la généralité de cette notation, il est communément utilisé en analyse la notation :

nomClasse Service
Visibilité Attribut1 : type1 - identifiant : int

Visibilité Attribut2 : type2 - nom : string
… …
Visibilité nomOpération1() : type1 +chercherServiceParNom(nom:string):void
Visibilité nomOpération2() : type2 - ajouterUnService(nom:string) : void
… +nombreService():int
Ou
5
nomClasse Service
Attribut1 identifiant
Attribut2 … nom
…
nomOpération1() chercherServiceParNom()
nomOpération2() ajouterUnService()
nombreService()
…
III. Association
Une association illustre une relation sémantiquement durable entre deux classes. L’instance d’une
association est un lien qui met en relation les objets des classes qui interviennent dans ladite
association.
Exemple 1: un employé travaille dans un service. Ici, l’association travailler met en relation
les objets de la classe service et ceux de la classe employé.
Exemple 2 : Représentation graphique associations
Le nom d’une association (voir exemple 2 section III) doit être une phrase verbale explicite
permettant de lire l’association dans les deux sens quoique privilégiant implicitement un seul
sens de lecture.
6
a) Multiplicité
La multiplicité détermine le nombre d’objets (min..max) qui peuvent participer à une relation
avec un autre objet dans le cadre d’une association. Les multiplicités permettent de
contraindre le nombre d’objets intervenant dans les instanciations des associations. Les
multiplicités couramment utilisés sont :
 0..1 = optionnel (mais pas multiple)
 1 = exactement 1, 7=exactement 7
 0..* = * = quelconque
 1..* = au moins 1
 2..8= 2 à 8, 4..*=au mois 4
Exemples :
7
b) Rôle
En UML, chaque extrémité d’une association peut être nommée c'est à dire enrichie d’un rôle.
Le rôle décrit la façon dont les instances d’une classe voient les instances d’une autre classe
au travers d’une association.
Un rôle a la même nature qu'un attribut dont le type serait la classe situé à l'autre extrémité.
Par conséquent, le rôle peut être public, privée, protégé etc.
Un rôle est généralement désigné par une forme nominale ou verbale. Le rôle est placé à une
extrémité du lien d’association, il se distingue ainsi du nom de l’association situé au centre du
lien.
Sur l’exemple exemple 2 de la section III, les objets de la classe société perçoit ceux de la
classe personne comme des employés. Un autre exemple est le suivant :
8
c) Navigabilité
La direction (voir exemple 2 section III) indique que chaque objet employé contient une liste
de modules qu’il enseigne mais, les objets de la classe module ne peuvent stocker la liste des
employés.
Par défaut, les associations ont une navigation bidirectionnelle. Cependant, une navigation
bidirectionnelle est complexe à réaliser par les développeurs. Il convient de les éviter dans la
mesure du possible. Un autre exemple d’une association unidirectionnelle entre la commande
et le produit est donné par :
Sur cet exemple, la terminaison du côté de la classe Commande n’est pas navigable : cela
signifie que les instances de la classe Produit ne stockent pas de liste d’objets du type
Commande. Inversement, la terminaison du côté de la classe Produit est navigable : chaque
objet commande contient une liste de produits.
d) Associations et attributs
Une technique utilisée pour représenter les associations sont les attributs. Elle est plus visible
pendant la phase de développement où les associations sont générées en tant qu’attributs. Par
exemple, les associations à multiplicité multiple sont souvent représenter par les tableaux ou
les collections (liste,…).
Exemple :
e) Classes d’association
Pour faire porter des informations par une association, on UML emploie une classe-
association. Une classe d’association comporte au même titre que les classes ordinaires les
attributs et les opérations. Graphiquement, on la relie à l’association avec des pointillés.
9
Exemples
f) Héritage
L’héritage lie une classe générale (Super-classe) et les classes plus spécifiques (sous-classes)
par une relation de généralisation. Les sous-classes « héritent » des propriétés de leur super-
classe et peuvent comporter des propriétés spécifiques supplémentaires.
L’héritage est un concept qui est à l’origine du polymorphisme. Une opération polymorphique
est une opération qui possède plusieurs implémentations. Un exemple est donné est :
10
g) Associations d’agrégation et composition

Une agrégation est un cas particulier d’association non symétrique exprimant une relation de
contenance. Les agrégations n’ont pas besoin d’être nommées. Implicitement, elles signifient
« contient », « est composé de ».
La relation d’agrégat est représentée par un losange clair du côté du rôle de la classe
composite appelée « agrégat ». L’agrégation exprime mais pas forcement que:
 un objet (élément) appartient simultanément à différentes compositions d’objets ;
 Une instance d'élément agrégé peut exister sans agrégat (et inversement). Ainsi, les
cycles de vies de l'agrégat et de ses éléments agrégés peuvent être indépendants.
L'agrégation est généralement utilisée pour souligner le fait que l'instance de la classe
composite n'est pas le conteneur exclusif de l'instance de la classe des éléments.
Une relation de composition est une agrégation plus forte impliquant que :
 un élément ne peut appartenir qu’à un seul agrégat composite (agrégation non
partagée) ;
 la destruction de l’agrégat composite entraîne la destruction de tous ses éléments (le
composite est responsable du cycle de vie des parties).
Ces deux relations sont représentées comme suit :
Pour identifier si une relation est une composition, elle doit remplir les deux critères suivants :
 la multiplicité ne doit pas être supérieure à un du côté du composite.
 le cycle de vie des parties doit dépendre de celui du composite.
11
h) Association dérivée
Une association dérivée est conditionnée ou peut être déduite à partir d’une autre association.
Souvent un ensemble de contraintes, exprimées en OCL, est ajouté à une association dérivée
pour définir les conditions de dérivation. Graphiquement, une association dérivée est
symbolisée par l’ajout d’un slash avant le nom de l’association. Dans l’exemple de la figure
ci-dessous, l’association dérivée /emploi indique que la personne qui travaille pour une
entreprise est la même que celle qui est associée à l’un de ses départements.
i) Qualification
En cas de cardinalité non finie à une extrémité d'une association, si les instances situées à
cette extrémité sont qualifiable, il est possible d'utiliser cette qualification pour passer de la
cardinalité maximale non finie à une cardinalité maximale finie.
La qualification d'une instance est une valeur ou ensemble de valeurs qui permettent de
retrouver cette instance. Une qualification est souvent un index, par exemple pour retrouver
un élément dans un tableau, ou une clef, par exemple pour retrouver une ligne dans une base
de données relationnelle.
IV. Expression de contraintes : OCL

Une contrainte est une condition entre éléments du modèle qui doit être vérifiée par les
éléments concernés. Elle est notée entre accolades { } et peut être insérée au besoin dans une
note graphique.
Nous avons déjà eu à exprimer les contraintes d’ordre structurel (attributs dans les classes,
relations entre classes, multiplicités, navigabilité, etc.), de type (typage des attributs, etc.) et
12
diverses (visibilités, etc.). Ces contraintes sont utiles mais se révèlent insuffisantes. Il y a
donc nécessité de les compléter par un outil plus évolué permettant de prendre en compte les
spécificités des éléments du modèle.
OCL est un langage formel proposé par IBM à UML 1.1 pour l’expression des contraintes. Il
se situe entre le langage naturel et le langage mathématique et se veut être simple et non
ambigu.
Exercice d’application : modéliser la phrase un compte bancaire peut appartenir à une

personne physique ou morale.
13
V. Les packages
Un package (paquetage) ou namespace en anglais est un mécanisme d’organisation
permettant de regrouper les éléments UML tels que classes, interfaces, acteurs, cas
d’utilisation, etc. et éventuellement d’autres paquets en établissant des frontières
sémantiques du modèle où les noms des éléments au sein d’un même package sont uniques.
La relation de dépendance entre packages rend visibles les éléments publics de l’un package
au sein d’un autre. Elle met en évidence le fait qu’un élément d’un package utilise un élément
d’un autre package. Lorsque les éléments des packages différents portent le même, UML
propose la notation nomPackage::nomÉlément pour les distinguer. C’est d’ailleurs
cette technique qu’utilise le langage java pour lever l’ambiguïté sur les namespace.
Package::SousPackage::NomClasse. Exemple : java.lang.String.
VI. Les classes d’analyse

Les classes d’analyse proposée par I. Jacobson sont les classes identifiées au cours de
l’activité d’analyse qui correspondent aux concepts réels du domaine. L’analyse met en
exergue le nom, les attributs importants, les opérations importantes et éventuellement les
stéréotypes non techniques d’une classe. Les éléments tels que les métadonnées, les
paramètres des opérations et les types de retour, la visibilité sont généralement omises
pendant cette phase. Par ailleurs, mis à part la visibilité, ces éléments peuvent être incorporés
pour faciliter la compréhension du modèle. Les classes d’analyses sont consignées dans un
diagramme des classes qui constitue la pièce angulaire d’un développement orienté objet.
Service
identifiant
nom
chercherServiceParNom()
ajouterUnService()
14
a) Sources de recensement des classes d’analyse

Les classes d’analyses peuvent être identifiées à partir :
 du modèle de spécifications du système ;
 du modèle des cas d’utilisation ;
 de toute source d’information relative au domaine.
b) Techniques de recensement des classes d’analyse
Classiquement, deux approches sont utilisées pour identifier les classes d’analyse :
La technique basée sur les noms et les verbes qui consiste à analyser le texte dans le but de
détecter les opérations (verbes et phrases verbales), les classes et les attributs (noms et phrases
nominales). La complexité de cette approche réside entre autres dans la difficulté de retrouver
les classes cachées, la compréhension des certains qui nécessite la consultation de l’expert du
domaine.
La technique basée sur les stéréotypes qui cherche à trouver :

 les classes de dialogue qui définissent la limite du système (« boundary ») à travers les
interfaces utilisateur (formulaires de saisie, résultats de recherche, fenêtres de
notification, etc.), les interfaces avec d’autres systèmes et les interfaces avec un
dispositif externe (périphériques, etc.). Ces classes posséderont des attributs (champs
de saisie ou des résultats) et des opérations (actions de l’utilisateur sur l’IHM).
 les classes de contrôle (« control ») qui décrivent les règles applicatives et qui sont
chargées de faire le lien entre les dialogues et les concepts métier. Ces classes
posséderont uniquement des opérations qui montrent la logique de l’application ou tut
simplement les comportements du système informatique ;
 les classes entités (« entity ») très souvent persistantes et qui permettent à des données
et des relations d’être stockées dans des fichiers ou des bases de données. Ces classes
15
posséderont uniquement des attributs qui représentent les informations persistantes de

l’application.
VII. Diagramme de classes participantes (DCP)

Les diagrammes de classes UML qui décrivent, cas d’utilisation par cas d’utilisation, les
trois principales classes d’analyse et leurs relations. Il sont particulièrement importants car
faisant la jonction entre les cas d’utilisation, la maquette et les diagrammes de conception
logicielle (diagrammes d’interaction et diagrammes de classes).
Exemple : DCP de Chercher des ouvrages
16
VIII. Implémentation en Java

public class A {
public A() { }
}
public class A {}
public class B extends A {}
public class A {
private ArrayList rb;
public A() {rb = new ArrayList();}
public ArrayList getArray()
{return(rb);}
public void addB(B b){ }
}
public class B {
private A ra;
public B() {}
public A getA() { return (ra); }
public void setA(A a){ this.ra=a; }
public void addA(A a){ }
}
public class A {
private ArrayList rb;
public A(){ rb = new ArrayList();}
}
public class B {
...//B ne connaît pas l'existence de A
}
class A {
private B b;
}
class A {
private B b;
private X x;
(getter et setter publics)
}
class A {
private List<C> c;
}
class C {
private B b;
private X x;
}
Transformé en :
public interface Ia {...}

public class A implements Ia {...}
17
IX. Implémentation en SQL

create table relation_A (
id_A integer primary key,
attA1 text,
attA2 integer);
create table relation_B (
id_B integer primary key,
num_A integer references relation_A,
attB1 text,
attB2 integer);
num_B integer references relation_B,
attA1 text,
attA2 integer);
attB1 text,
attB2 integer);
attA1 text,
attA2 integer);
attB1 text,
attB2 integer);
create table relation_A_B (
primary key (num_A, num_B));
attA1 text,
attA2 integer);
attB1 text,
attB2 integer);
create table relation_C (
attC1 text,
attC2 integer,
primary key (num_A, num_B));
create table relation_C (

id_C integer primary key,
attC1 text,
attC2 integer,
type text);

id_A references relation_C,
attA1 text,
attA2 integer,
primary key (id_A));

id_B references relation_C,
attB1 text,
attB2 integer,
primary key (id_B));
18

Chapitre 2-2020 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

Chapitre 2-2020 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Cours UML, Chapitre 2, Analyse statique

Chapitre 2 : Modélisation statique

a) Notion UML des objets

typeSamrtP022 : TypeTéléphone Chef

serviceIT033 : Service serviceClient012 : Service

b) Nom d’une classe

Malgré la généralité de cette notation, il est communément utilisé en analyse la notation :

Visibilité Attribut1 : type1 - identifiant : int

g) Associations d’agrégation et composition

IV. Expression de contraintes : OCL

Exercice d’application : modéliser la phrase un compte bancaire peut appartenir à une

VI. Les classes d’analyse

a) Sources de recensement des classes d’analyse

La technique basée sur les stéréotypes qui cherche à trouver :

posséderont uniquement des attributs qui représentent les informations persistantes de

VII. Diagramme de classes participantes (DCP)

Exemple : DCP de Chercher des ouvrages

VIII. Implémentation en Java

public interface Ia {...}

IX. Implémentation en SQL

create table relation_C (

create table relation_A (

create table relation_B (

Vous aimerez peut-être aussi