Vous êtes ici : Accueil Diagrammes Diagramme UML Structurel ou Statique

Structurel ou Statique

Diagrammes Structurels ou Diagrammes statiques (cf. Structural Diagrams)

Diagrammes de classes (cf. Class diagram)

Il représente les classes intervenant dans le système. Le diagramme de classe est une représentation statique des éléments qui composent un système et de leurs relations.

Chaque application qui va mettre en œuvre le système sera une instance des différentes classes qui le compose.

A ce titre il faudra bien garder à l'esprit qu'une classe est un modèle et l'objet sa réalisation.

L'exemple le plus classique est de considérer la classe « EtreHumain » qui sert à instancier les objets « pierre:EtreHumain », « georgette:EtreHumain », etc...

Enfin, l'erreur la plus courante est de créer une classe pour chaque cas d'utilisation d'un système alors que se seront des ensembles de classes qui vont permettre la réalisation d'un cas d'utilisation.

Le fonctionnement dynamique d'une classe pourra être modélisé à travers des diagrammes d'état ou d'activité.

Important : Les classes et les associations utilisées dans le diagramme de classe pouvant servir de base à la génération du code de l'application, il faut respecter au maximum les chartes de nommage ainsi que les bases de syntaxe des langages informatiques.

Le concept de classe

La classe est un concept abstrait qui permet de représenter toutes les entités d'un système. Une classe peut donc représenter une voiture, un bouton cliquable,  un devis, un utilisateur connecté, une structure de donnée ou tout autre élément devant être modélisé et donnant généralement lieu à la génération d'un code informatique.

La classe est définie par son nom, ses attributs et ses opérations comme ci-dessous.
Étant donné que les classes vont être utilisées pour générer le code il est souhaitable d'utiliser une règle de nommage qui respecte les syntaxes des langages informatiques comme par exemple celle proposée par Java qui consiste à :

  • Commencer les noms des classes par des majuscules et tous les autres éléments par des minuscules.
  • Séparer les mots composés par des majuscules.
  • Ne pas utiliser de caractères spéciaux ou accentués qui pourraient ne pas être acceptés dans les langages informatiques.
ConceptDeClasse.png

 

Les attributs de la classe

Nous verrons plus bas que les associations entre classes sont aussi des attributs.

La syntaxe d'un attribut est la suivante :

<visibilite> [/] <nomAttribut> : <type> [ '['<multiplicite>']' [{<contrainte>}] ] [ = <valeurParDefaut> ]

  • visibilite : + public / # protected / - private
  • / : signal un attribut dérivé. C'est à dire calculé à partir d'autres attributs.
  • nomAttribut : nom de l'attribut
  • type : type de l'attribut
  • [multiplicite] : multiplicité pour définir des tableaux, des listes de valeurs
  • {<contrainte>} : pour donner des contraintes OCL quand la multiplicité est supérieure à 1
  • valeurParDefaut : valeur d'initialisation

Les opérations de la classe

La syntaxe des opérations est la suivante :

  • <visibilite> <nomOperation> ([<param1>, ... , <paramN>]) : [<typeRetour>] [{<proprietes>}]
  • visibilite : + public / # protected / - private
  • nomOperataion : nom de l'opération
  • [<param1>, ... , <paramN>] : liste des paramètres respectant la syntaxe ci-dessous.
  • typeRetour : type de retour de l'opération
  • {<propriete>} : contraintes OCL, indications ou mots clé comme « abstract »

La syntaxe des paramètres (<paramX>) est la même que celle d'un attribut à la « direction » près  :

[<direction>] <nomParam> : <type> [ '[' <multiplicite> ']' ] [ = <valeurParDefaut> ]

  • direction  <in> : Valeur par défaut qui définit que l'appelant fournit une valeur et n'accède pas aux modifications de cette dernière.
  • direction <out> : Paramètre utilisé uniquement pour fournir une valeur en lecture à l'appelant.
  • direction <inout> : Paramètre utilisé par l'appelant pour fournir une valeur qu'il peut aussi lire après modification.

Nous considérons aussi souvent qu'il existe des opérations implicites qui sont les opérations d'accès aux attributs appelées « Accessor » et « Mutator » puisque le concept de base des langages objets consiste à encapsuler les attributs dans les classes en les rendant privées ou protégées et à ne permettre leur accès qu'à travers des méthodes publiques.

Classes actives et passives

UML définit les classes par défaut comme passives.

C'est à dire qu'elle fournissent des structures de données et des comportements.

Les classes définies comme actives sont les classes qui contrôlent le système aussi appelé « main ».

Elles sont représentées par une double barre sur le coté.

L'association

L'association est le premier niveau de relation entre 2 classes.

Elle spécifie tout simplement qu'une classe peut en utiliser une autre.

L'association est habituellement traduite dans le code par un pointeur ou un tableau de pointeurs.

Dans l'exemple ci-dessous nous avons en haut la représentation graphique et en bas la représentation sous forme d'attributs de la même association.

Cet exemple montre bien que l'association utilisée graphiquement se matérialisera réellement comme un attribut avec la multiplicité et le rôle défini sur l'association.

Une association est donc définie par ses 2 terminaisons qui ont chacune :

  • Un rôle : C'est le nom que prendra l'attribut de la classe.
  • Une multiplicité : Comme pour les attributs
  • Une navigabilité : Pour rendre l'association bidirectionnelle ou monodirectionnelle.
  • Une visibilité : Comme tous les attributs.
AssociationClasse.png

 

 

Multiplicité d'une terminaison.

Chaque terminaison d'association peut définir les multiplicités suivantes :

  • 1 : C'est la valeur par défaut de toute terminaison qui précise qu'il y a un et un seul élément.
  • 0..1 : Possibilité d'avoir 0 ou 1 élément.
  • 1..*  : Possibilité d'avoir 1 à n éléments. Cette structure de dimension inconnue devra être gérée par une structure de de dimension variable (listes chainées, etc...)
  • 0..* : Possibilité d'avoir 0 à n éléments. Cette structure de dimension inconnue devra être gérée par une structure de dimension variable (listes chainées, etc...)
  • n : Définit un nombre précis d'éléments.
  • n..m : Définit une fourchette précise d'éléments.
  • * : équivalent de 0..*

Les agrégations

 

Contrairement à l'association

l'agrégation représente un objet instancié et pas simplement un pointeur.

Les compositions

 

Tout comme l'agrégation la composition représente un objet instancié et pas simplement un pointeur.

En plus cet objet ne peut être créé et détruit que par l'objet qui le compose.

On dit que la durée de vie de l'objet composé est le même que celui de l'objet qui le compose.

L'héritage

 

Le concept d'héritage tel qu'il est définit dans tous les langages objets est représenté en UML par une flèche d'héritage comme ci-dessous.

Heritage.png

Diagramme d'objets (cf. Object diagram)

Il sert à représenter les instances de classes (objets) utilisées dans le système.

Voir le cours de Laurent Audibert  : http://laurent-audibert.developpez.com/Cours-UML/html/index.html

Diagramme de composants (cf. Component diagram)

Il permet de montrer les composants du système d'un point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de données...)

Voir le cours de Laurent Audibert  : http://laurent-audibert.developpez.com/Cours-UML/html/index.html

Diagramme de déploiement (cf. Deployment diagram)

Il sert à représenter les éléments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage...) et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent avec eux.

Voir le cours de Laurent Audibert  : http://laurent-audibert.developpez.com/Cours-UML/html/index.html

Diagramme des paquetages (cf. Package Diagram)

Un paquetage étant un conteneur logique permettant de regrouper et d'organiser les éléments dans le modèle UML, le Diagramme de paquetage sert à représenter les dépendances entre paquetages, c’est-à-dire les dépendances entre ensembles de définitions.

Voir le cours de Laurent Audibert  : http://laurent-audibert.developpez.com/Cours-UML/html/index.html

Diagramme de structure composite (depuis UML 2.x, cf. Composite Structure Diagram)

Permet de décrire sous forme de boîte blanche les relations entre composants d'une classe.

Voir le cours de Laurent Audibert  : http://laurent-audibert.developpez.com/Cours-UML/html/index.html

 

 

Actions sur le document
Références
 
Site réalisé et hébergé par www.optragroup.fr