CHAPITRE II : PRESENTATION DU LANGAGE DE MODELISATION UML

II.1 Introduction

L'UML (pour Unified Modeling Language, ou "langage de modélisation unifié" en français) est un langage permettant de modéliser nos classes et leurs interactions. Autrement c’est un ensemble de notations graphiques s’appuyant sur des diagrammes et permettant de spécifier, visualiser et de documenter les systèmes logiciels orientés-objet.

 Concrètement, cela s'effectue par le biais d'un diagramme : vous dessinerez vos classes et les lierez suivant des conventions bien précises. Cela vous permettra ainsi de mieux visualiser votre application et de mieux la penser [1].

UML s'impose aujourd'hui comme  langage de modélisation objet standardisé pour la conception des logiciels. La version finalisée, largement enrichie et corrigée de cette première ébauche de cours est parue, dans la collection Info+ chez les éditions Ellipses, sous le titre UML 2 - de l'apprentissage à la pratique (cours et exercices). Voici ce que la version publiée apporte par rapport à la première version :

  • de nombreuses améliorations (corrections, illustrations, exemples…). En fait, seulement 20 % de la version UML 2 se retrouve à l'identique dans la version de UML 1 ;

  • de nouvelles notions (Design Patterns, introduction aux principales méthodes de développement, diagramme de structures composites…). La version éditée est pratiquement deux fois plus volumineuse que la version en ligne ;

  • des séances de travaux dirigés et de travaux pratiques accompagnées de corrigés complets et détaillés ;

  • une présentation bien plus agréable sous la forme d'un vrai livre. « UML (en anglais Unified Modeling Language ou « langage de modélisation unifié ») est un langage de modélisation graphique à base de diagrammes. Il est apparu dans le monde du génie logiciel, dans le cadre de la « conception orientée objet ».

Couramment utilisé dans les projets logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au domaine informatique.

UML est l’accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT[1], OOSE[2]. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard défini par l’Object Management Group (OMG). La dernière version diffusée par l’OMG[3] est UML 2.4.1 depuis aout 20112 [2].

Comme UML est un langage de modélisation objet, nous allons pour la suite dire ce que c’est l’approche orienté objet et à quoi il  sert.

 

II.2 Notion sur l’orienté objet

II.2. 1  Introduction

 

Aujourd’hui, il existe  deux principaux modèles de représentations des systèmes. Le modèle fonctionnel et le modèle objet (ou de « l’orienté-objet », l’OO).Dans l’approche fonctionnelle les programmes sont composés d’une série de fonctions qui assurent certaines services .Il s’agit d’une approche logique, cohérente et intuitive de la programmation. Cette approche a un avantage que certain appelle factorisation des comportements (c’est-à-dire que pour créer une fonction d’une application, rien ne vous empêche d’utiliser un autre ensemble de fonctions déjà écrites).

Mais cette approche a ses défauts comme par exemple une maintenance complexe en cas d’évolution d’une application (une simple mise à jour de l’application à un point donné peut impacter en cascade sur d’autres fonctions de l’application).Donc la mise à jour sera alors retouchée l’application dans sa globalité [3].

L’approche fonctionnelle n’est pas adaptée au développement d’applications qui évoluent sans cesse et dont la complexité croit continuellement. Donc nous allons voir l'approche objet qui a été inventée pour faciliter l'évolution d'applications complexes.

 

II.2 .2  Les concepts de base de l'approche objet

a) Objet

 

Un objet est une abstraction d’un élément du monde réel. Il possède des informations, par exemple nom, prénom, adresse etc., et se comporte suivant un ensemble d’opérations qui lui sont applicables.

De plus, un ensemble d'attributs caractérisent l'état d'un objet, et l'on dispose d'un ensemble d'opérations (les méthodes) qui permettent  d’agir sur le comportement de l’objet. Ce dernier  est le cœur de  cette approche. Tout objet donné possède deux caractéristiques : Son état courant (attributs) et Son comportement (méthodes) [4].

b) Classe

 

On appelle classe la structure d’un objet, c’est-à-dire la déclaration de l’ensemble des entités qui composeront un objet. Les objets de même nature ont en général la même structure et le même comportement. La classe factorise les caractéristiques communes de ses objets et permet de les classifier. Un objet est l’instance d’une classe, et une classe est un type de données abstrait, caractérisé par des propriétés (ses attributs et ses méthodes) communes à ses objets et un mécanisme permettant de créer des objets ayant ces propriétés. Le concept de classe permet donc  de regrouper des objets de même nature [5].

                         c) Héritage

 

L’héritage  est un principe propre à la programmation orientée objet, permettant de créer une nouvelle classe à partir d’une classe existante. Le nom d’"héritage" (ou parfois dérivation de classe) provient du fait que la classe dérivée (la classe nouvellement créée) contient les attributs et les méthodes de sa superclasse (la classe dont elle dérive).

L’intérêt majeur de l’héritage est de pouvoir définir de nouveaux attributs et de nouvelles méthodes pour la classe dérivée, qui viennent s’ajouter à ceux et celles héritées. Par ce moyen on crée une hiérarchie de classes de plus en plus spécialisées [6].

 

 

 

II.2 .3  Les avantages de l’approche objet

 

En fait, on peut dire que la POO est une façon de développer une application qui consiste à représenter (on dit également « modéliser ») une application informatique sous la forme d’objets, ayant des propriétés et pouvant interagir entre eux. La modélisation orientée objet est proche de la réalité ce qui fait qu’il sera relativement facile de modéliser une application de cette façon. De plus, les personnes non-techniques pourront comprendre et éventuellement participer à cette modélisation.

Cette façon de modéliser les choses permet également de découper une grosse application, généralement floue, en une multitude d’objets interagissant entre eux. Cela permet de découper un gros problème en plus petits afin de le résoudre plus facilement.

Utiliser une approche orientée objet facilite également de faire la maintenance du logiciel. Plus le temps passe et plus une application est difficile à maintenir. Il devient difficile de corriger un code sans tout casser ou d’ajouter des fonctionnalités sans provoquer une régression par ailleurs. L’orienté objet nous aide ici à limiter la casse en proposant une approche où les modifications internes à un objet n’affectent pas tout le reste du code, grâce notamment à l’encapsulation[4].

Un autre avantage de la POO est la réutilisabilité. Des objets peuvent être réutilisés ou même étendus grâce à l’héritage. C’est le cas par exemple de la bibliothèque de classes du Framework .NET. Cette bibliothèque nous fournit par exemple tous les objets permettant de construire des applications graphiques. Pas besoin de réinventer toute la mécanique pour gérer des fenêtres dans une application, le Framework .NET sait déjà faire tout ça. Nous avons juste besoin d’utiliser un objet « fenêtre », dans lequel nous pourrons mettre un objet « bouton » et un objet « zone de texte ». Ces objets héritent tous des mêmes comportements, comme le fait d’être cliquable ou sélectionnable, etc  [7].

 

Conclusion

 

·         L’approche orientée objet permet de modéliser une  application sous la forme d’interactions entre objets.

·         Les objets ont des propriétés et peuvent faire des actions.

·         Ils masquent la complexité d'une implémentation grâce à l'encapsulation.

·         Les objets peuvent hériter de fonctionnalités d'autres objets s'il y a une relation d'héritage entre eux.

II.3 Les diagrammes UML

UML dans sa 2ème version propose treize diagrammes qui peuvent être utilisés pour la description d’un système. Ces diagrammes sont regroupés dans deux grands ensembles qui sont :

A .Les diagrammes structurels  qui  ont comme  vocation de représenter l’aspect statique d’un système. Ils permettent d’identifier les objets constituant le programme, leurs attributs, leurs opérations et les méthodes qui leurs sont associés. Ils sont au nombre de six à savoir :

·                     Diagramme de Classe ;

·                     Diagramme d’objet ;

·                     Diagramme de composant ;

·                     Diagramme de déploiement ;

·                     Diagramme de Paquetage ;

·                     Diagramme de structure composite [8].

 

B. Les diagrammes de comportement : Ces diagrammes représentent la partie dynamique d’un système réagissant aux événements et permettant de produire les résultats attendus par les utilisateurs. Sept diagrammes sont proposés par UML 2 :

·                     Diagramme des cas d’utilisation ;

·                     Diagramme d’état-transition ;

·                     Diagramme d’activités ;

·                     Diagramme de séquence ;

·                     Diagramme de communication ;

·                     Diagramme global d’interaction ;

·                     Diagramme de temps [9].

 

 

 

 

 

II.3.1 Les diagrammes structurels

II.3.1 .1 Diagramme de classe

Le diagramme de classe constitue l’un des pivots essentiels de la modélisation avec UML. En effet, ce diagramme permet de donner la représentation statique du système à développer. Cette représentation est centrée sur les concepts de classe et d’association. Chaque classe se décrit par les données et les traitements dont elle est responsable pour elle-même et vis-à-vis des autres classes. Les traitements sont matérialisés par des opérations. Le détail des traitements n’est pas représenté directement dans le diagramme de classe ; seul l’algorithme général et le pseudo-code correspondant peuvent être associés à la modélisation.

La description du diagramme de classe est fondée sur :

·         le concept d’objet ;

·         le concept de classe comprenant les attributs et les opérations ;

·         les différents types d’association entre classes.

*      Le concept d’objet

Un objet est un concept, une abstraction ou une chose qui a un sens dans le contexte du système à modéliser. Chaque objet a une identité et peut être distingué des autres sans considérer a priori les valeurs de ses propriétés.

Un objet est caractérisé par les valeurs de ses propriétés qui lui confèrent des états significatifs suivant les instants considérés.

*      Concept de classe

Une classe décrit un groupe d’objets ayant les mêmes propriétés (attributs), un même comportement (opérations), et une sémantique commune (domaine de définition).

Un objet est une instance d’une classe. La classe représente l’abstraction de ses objets. Au niveau de l’implémentation, c’est-à-dire au cours de l’exécution d’un programme, l’identificateur d’un objet correspond une adresse mémoire [10].

Une classe se représente à l’aide d’un rectangle comportant plusieurs compartiments.

Les trois compartiments de base sont :

·         la désignation de la classe ;

·         la description des attributs ;

·         la description des opérations.

Deux autres compartiments peuvent être aussi indiqués :

·         la description des responsabilités de la classe ;

·         la description des exceptions traitées par la classe.

Cependant Il est possible de manipuler les classes en limitant le niveau de description à un nombre réduit de compartiments selon les objectifs poursuivis par le modélisateur.

Ainsi les situations suivantes sont possibles pour la manipulation d’une description restreinte de classe :

·         description uniquement du nom et des caractéristiques générales de la classe ;

·         description du nom de la classe et de la liste d’attributs.

La figure suivante  montre le formalisme général des compartiments d’une classe:

Attributs

 

    Nom de la classe

 

Opérations

 

Responsabilités et/ou exception

 

 

Figure_02.JPG

 

 

§  Attributs

Un attribut est une propriété élémentaire d’une classe. Pour chaque objet d’une classe, l’attribut prend une valeur (sauf cas d’attributs multivalués).

La description complète des attributs d’une classe comporte un certain nombre de caractéristiques qui doivent respecter le formalisme suivant :

Visibilité/Nom attribut : type [= valeur initiale {propriétés}]

-           Visibilité : Chaque attribut  d’une classe peut être de type   public, protégé, privé ou    paquetage ;

-          Nom d’attribut : nom unique dans sa classe ;

-           Type : type primitif (entier, chaîne de caractères…) dépendant des types    disponibles dans le langage d’implémentation ou type classe matérialisant un lien    avec une autre classe.

-          Valeur initiale : valeur facultative donnée à l’initialisation d’un objet de la classe.

-          {propriétés} : valeurs marquées facultatives (ex. : « interdit » pour mise à jour interdite).

 

 

§  Opération

Une opération est une fonction applicable aux objets d’une classe. Une opération permet de décrire le comportement d’un objet. Une méthode est l’implémentation d’une opération.

Caractéristiques d’une opération :

-          Visibilité : Chaque  opération d’une classe peut être de type   public, protégé, privé ou    paquetage.

-          Nom d’opération : utiliser un verbe représentant l’action à réaliser.

-          Paramètres : liste de paramètres (chaque paramètre peut être décrit, en plus de son nom, par son type et sa valeur par défaut). L’absence de paramètre est indiquée par ( ).

-          Type résultat : type de (s) valeur(s) retourné(s) dépendant des types disponibles dans le langage d’implémentation.

-          {propriétés} : valeurs facultatives applicables (ex. : {query} pour un comportement sans influence sur l’état du système).

 

§  Visibilité des attributs et opérations

-          Nous avons vu que chaque attribut ou opération d’une classe peut être de type public, protégé, privé ou paquetage.

-          Les symboles + (public), # (protégé), - (privé) et ~ (paquetage) sont indiqués devant chaque attribut ou opération pour signifier le type de visibilité autorisé pour les autres classes.

-          Les droits associés à chaque niveau de confidentialité sont :

·         Public (+) – Attribut ou opération visible par tous.

·         Protégé (#) – Attribut ou opération visible seulement à l’intérieur de la classe et pour toutes les sous-classes de la classe.

·         Privé (-) – Attribut ou opération seulement visible à l’intérieur de la classe.

·         Paquetage (~) – Attribut ou opération ou classe seulement visible à l’intérieur du paquetage où se trouve la classe [11].

 

On peut montrer  quelques  notions évoquées ci-haut avec la classe ci-dessus :

 

Personne

-IdPersonne : int

-NomPersonne : String

-PrenomPersonne :String

-DateNaissance : Date

+ Enregistrer() :void

+Modifier() : void

+Supprimer() : void

 

Figure_03.JPG

 

 

*      Relation entre les classes

Les classes ne valent que par les relations qu'elles tissent entres elles. Ces relations ne sont pas exclusives au diagramme de classe, elles peuvent également s'appliquer à l'ensemble des diagrammes statiques.

1.      Association  ou relation structurelle

·         une association exprime une connexion sémantique bidirectionnelle entre classes.

·         Une association est une abstraction des liens qui existent entre les objets instances des classes associées

·         Une association  est représentée par un trait plein, pouvant être orienté. La multiplicité est notée du côté du rôle cible de l'association.

Elle spécifie le nombre d'instances pouvant être associées (liées) avec une seule instance source de la relation [12]. Exemple : Une personne peut posséder plusieurs voitures (entre zéro et un nombre quelconque) ; une voiture est possédée par une seule personne.      

Figure 4: Formalisme d’une relation en générale

 Les associations comportent des cardinalités.

Cette notion est identique à celle contenue dans Merise. Dans UML, on parle de valeurs de multiplicité.

Exemple                                                                           

 

 

Figure_05.JPG

Interprétation :
Une revue est disponible dans un ou plusieurs points de vente.
Un point de vente distribue de une à plusieurs revues.

Commentaire: Le nombre de classes participant à l'association définissent l'arité de l'association. L’exemple  précédent montre une association d'arité 2. 
Ceci sera le plus fréquent.

             

  Valeurs de multiplicité.

1..1

Un et un seul

1

Un et un seul

0..1

Zéro ou un

m..n

De m à n

*

De zéro à plusieurs

0..*

De zéro à plusieurs

1..*

De un à plusieurs

   Tableau 1: valeurs de multiplicité

      

 

 

 

2.      Relation de spécialisation/généralisation

 

 

Relation d'héritage, dans laquelle les objets de l'élément spécialisé (classe enfant) peuvent remplacer les objets de l'élément général (classe parent) [13].

Exemple : Un client professionnel est une sorte de client.

Notation UML : Un trait plein, orienté de la classe spécialisée (enfant) vers son modèle (parent) et se terminant par une flèche fermée.

 

 

Figure_06.JPG

 

 

3.      Relation de dépendance

 

 

Cette relation est simple à comprendre : elle présente l'utilisation que fait une classe d'une autre. Une classe dépend d'une autre si ses méthodes manipulent l'objet de cette classe. En UML, une dépendance est représentée par une ligne en tirets, terminée par une simple flèche [14].

Autrement dit, une dépendance est une relation entre deux éléments dans laquelle une modification à un élément (l'élément indépendant : par exemple  fournisseur) provoque des modifications sur l'autre élément (l'élément dépendant : exemple  client).

Une dépendance est représentée graphiquement sous la forme d'une ligne dirigée de pointillés, dirigée vers l'élément indépendant (fournisseur):

 

 

 

 

 

 

 

Figure_07.JPG

4.       Agrégation

Une relation d'agrégation indique un principe de subordination entre l'agrégat (classe qui regroupe les classes agrégées) et les agrégées. Concrètement, elle indique une "possession" : l'agrégat peut contenir plusieurs objets d'un type. Réservation Par exemple, une classe peut contenir un ou plusieurs objets de type        Place   de            Cinéma.
En UML, une agrégation est représentée par une ligne entre deux classes, terminée par un losange vide  du côté de l'agrégat [15].

Exemple : La relation entre une Personne est son adresse peut être vue comme une agrégation : la classe Personne possède une adresse, mais l'Adresse ne meurt pas forcément quand la Personne déménage, ou "décède".

5.      Composition

Aussi appelée "agrégation forte" ou "agrégation par valeur", il s'agit en fait d'une agrégation à laquelle on impose des contraintes internes : un seul objet peut faire partie d'un composite (l'agrégat de la composition), et celui-ci doit gérer toutes ses parties. En clair, les composants sont totalement dépendants du      composite.
En UML, la composition est représentée de la même manière que l'agrégation, mais le losange est plein [15].

Exemple : Relation entre Hôtel et ses chambre ; quand l’hôtel meurt ses chambre aussi.

 

 

 

 

 

 

 

II.3.1 .2 Diagramme de déploiement

Le diagramme de déploiement permet de représenter l’architecture physique supportant l’exploitation du système. Cette architecture comprend des nœuds correspondant aux supports physiques (serveurs, routeurs…) ainsi que la répartition des artefacts logiciels (bibliothèques, exécutables…) sur ces nœuds. C’est un véritable réseau constitué de nœuds et de connexions entre les nœuds qui modélise cette architecture [16].

 

1. Nœud

Un nœud correspond à une ressource matérielle de traitement sur laquelle des artefacts seront mis en œuvre pour l’exploitation du système. Les nœuds peuvent être interconnectés pour former un réseau d’éléments physiques [17].

Formalisme d’un nœud : Un nœud se représente par un cube ou parallélépipède.

Nœud

 

 

 

 

 

Figure_08.JPG

 

2. Artefact

Un artefact est la spécification d’un élément physique qui est utilisé ou produit par le processus de développement du logiciel ou par le déploiement du système. C’est donc un élément concret comme par exemple : un fichier, un exécutable ou une  table d’une base de données. Un artefact peut être relié à d’autres artefacts par notamment des liens de dépendance  [18].

Formalisme : Un artefact se représente par un rectangle caractérisé par le mot-clé « artifact » et/ou une icône particulière dans le coin droit du rectangle.

 

 

 

 

Figure_09.JPG

 

 

 

 

 

Il existe deux manières de représenter le lien entre un artefact et son nœud d’appartenance :

• Représentation inclusive : Dans cette représentation, un artefact est représenté à l’intérieur du nœud auquel il se situe physiquement.

<<artifact>>

 

<<artifact>>

 

 

 

 

 

 

 

 

 

Figure_10.JPG

·         Représentation avec un lien de dépendance typé « deploy » : Dans ce cas l’artefact est représenté à l’extérieur du nœud auquel il appartient avec un lien de dépendance entre l’artefact et le nœud typé avec le mot-clé « deploy »

 

Nœud

 

 

 

 

 

                                                           

       <<deploy>>                                              <<deploy>>

 

<<artifact>>

 

 

<<artifact>>

 

 

 

 

 

 

Figure_11.JPG

 

1.      Représentation du diagramme de déploiement

 

Le diagramme de déploiement représente les nœuds de l’architecture physique ainsi que l’affectation des artefacts sur les nœuds conformément aux règles de déploiement définies [19]. 

 

 

 

Figure_12.JPG

 

II.3 .2  Les diagrammes de comportement 

 

 

II.3 .2  .1 Diagramme de cas d’utilisation

1.1     Présentation générale et concepts de base

Les cas d’utilisation ont été définis initialement par Ivar Jacobson en 1992 dans sa méthode OOSE. Les cas d’utilisation constituent un moyen de recueillir et de décrire les besoins des acteurs du système. Ils peuvent être aussi utilisés ensuite comme moyen d’organisation du développement du logiciel, notamment pour la structuration et le déroulement des tests du logiciel.

Un cas d’utilisation permet de décrire l’interaction entre les acteurs (utilisateurs du cas) et le système. La description de l’interaction est réalisée suivant le point de vue de l’utilisateur [20].

La représentation d’un cas d’utilisation met en jeu trois concepts : l’acteur, le cas d’utilisation et l’interaction entre l’acteur et le cas d’utilisation.

¨      Acteur

Un acteur est un utilisateur type qui a toujours le même comportement vis-à-vis d’un cas d’utilisation. Ainsi les utilisateurs d’un système appartiennent à une ou plusieurs classes d’acteurs selon les rôles qu’ils tiennent par rapport au système. Une même personne physique peut se comporter en autant d’acteurs différents que le nombre de rôles qu’elle joue vis-à-vis du système.

Ainsi par exemple, l’administrateur d’un système de messagerie peut être aussi utilisateur de cette même messagerie. Il sera considéré, en tant qu’acteur du système, dans le rôle d’administrateur d’une part et dans celui d’utilisateur d’autre part. Un acteur peut aussi être un système externe avec lequel le cas d’utilisation va interagir.

 

¨      Cas d’utilisation et interaction

Un cas d’utilisation correspond à un certain nombre d’actions que le système devra exécuter en réponse à un besoin d’un acteur. Un cas d’utilisation doit produire un résultat observable pour un ou plusieurs acteurs ou parties prenantes du système.

Une interaction permet de décrire les échanges entre un acteur et un cas d’utilisation.

Formalisme : Un cas d’utilisation se représente par un ovale dans lequel figure son intitulé.  L’interaction entre un acteur et un cas d’utilisation se représente comme une association.

Le formalisme de base de représentation d’un cas d’utilisation est donné à la figure ci-dessous :

 

 

                                               

Nom du cas d’utilisation

                                                            Interaction

 

 

Nom de l’acteur

 

Figure_13.JPG

1.2    Représentation du diagramme des cas d’utilisation

Tout système peut être décrit par un certain nombre de cas d’utilisation correspondant aux besoins exprimés par l’ensemble des utilisateurs. À chaque utilisateur, vu comme acteur, correspondra un certain nombre de cas d’utilisation du système.

L’ensemble de ces cas d’utilisation se représente sous forme d’un diagramme. La figure ci-dessous montre un extrait d’un diagramme de cas d’utilisation.

 

 

 

Figure_14.JPG

1.3    Relations entre cas d’utilisation

UML définit trois types de relations standardisées entre cas d’utilisation:

-          Une relation d’inclusion: le cas de base en incorpore explicitement un autre, à un endroit spécifié dans ses enchaînements. Le cas d’utilisation inclus n’est jamais exécuté seul, mais seulement en tant que partie d’un cas de base plus vaste. Elle est  formalisée par un mot-clé <<include>> ;

Exemple : Avant de créer une commande, il faut d’abord s’authentifier.

-          Une relation d’extension : formalisée par un mot-clé <<extend>>, une relation d’extension d’un cas d’utilisation A par un cas d’utilisation B signifie qu’une instance de A peut être étendue par le comportement décrit dans B ;

Exemple : Après la création d’une commande, on peut  payer ou ne pas payer avant la finition.

-          Relation de généralisation/spécialisation: consiste à hiérarchiser les cas d’utilisations [21].

Exemple : Pour la gestion de la commande on peut spécifier la création, la modification, ….

 

1.4     Description textuelle des cas d’utilisation

À chaque cas d’utilisation doit être associée une description textuelle des interactions entre l’acteur et le système et les actions que le système doit réaliser en vue de produire les résultats attendus par les acteurs. La description textuelle d’un cas d’utilisation est articulée en six points :

·         Objectif : décrire succinctement le contexte et les résultats attendus du cas d’utilisation.

·         Acteurs concernés : le ou les acteurs concernés par le cas doivent être identifiés en précisant globalement leur rôle.

·         Pré conditions : si certaines conditions particulières sont requises avant l’exécution du cas, elles sont à exprimer à ce niveau.

·         Post conditions : par symétrie, si certaines conditions particulières doivent être réunies après l’exécution du cas, elles sont à exprimer à ce niveau.

·         Scénario nominal : il s’agit là du scénario principal qui doit se dérouler sans incident et qui permet d’aboutir au résultat souhaité.

·         Scénarios alternatifs : les autres scénarios, secondaires ou correspondants à la résolution d’anomalies, sont à décrire à ce niveau. Le lien avec le scénario principal se fait à l’aide d’une numérotation hiérarchisée (1.1a, 1.1b…) rappelant le numéro de l’action concernée [22].

 

II.3 .2  .2   Diagramme d’état-transition

 

2.1   Présentation générale

Les diagrammes d'états-transitions d'UML décrivent le comportement interne d'un objet à l'aide d'un automate à états finis. Ils présentent les séquences possibles d'états et d'actions qu'une instance de classe peut traiter au cours de son cycle de vie en réaction à des événements discrets.

Ils spécifient habituellement le comportement d'une instance de classeur (classe ou composant), mais parfois aussi le comportement interne d'autres éléments tels que les cas d'utilisation, les sous-systèmes, les méthodes.

Le diagramme d'états-transitions est le seul diagramme, de la norme UML, à offrir une vision complète et non ambiguë de l'ensemble des comportements de l'élément auquel il est attaché. En effet, un diagramme d'interaction n'offre qu'une vue partielle correspondant à un scénario sans spécifier comment les différents scénarii interagissent entre eux.

La vision globale du système n'apparaît pas sur ce type de diagrammes puisqu'ils ne s'intéressent qu'à un seul élément du système indépendamment de son environnement.

Concrètement, un diagramme d'états-transitions est un graphe qui représente un automate à états finis, c'est-à-dire une machine dont le comportement des sorties ne dépend pas seulement de l'état de ses entrées, mais aussi d'un historique des sollicitations passées  [23].

L’objectif du diagramme d’état-transition est donc de décrire le comportement dynamique d'une entité (logiciel, composant, objet...).

 

 

 

 

2.1    Notion d’état

Un état est égal à une étape dans le cycle de vie d’un objet.  Chaque objet possède à un instant donné un état particulier et Chaque état est identifié par un nom. Chaque diagramme d’états-transitions comprend un état final. Cependant, Il est possible de n’avoir aucun état final pour un système qui ne s’arrête  jamais.   

 

Formalisme :

Etat intermédiaire

Etat initial                                 Etat final        

 

 

Figure_15.JPG

                                   d’état-transition.

 

2.2    Notion de transition

 

Les états sont reliés par des connexions unidirectionnelles appelées transitions

 

 

Etat B

 

Etat A

                                                

 

Figure_16.JPG

 

 

2.4  Notion d’événement

Un événement correspond à l’occurrence d’une situation donnée dans le domaine étudié. Un événement est une information instantanée qui doit être traitée à l’instant où il se produit [24].

 

Etat B

 

Etat A

                              Evénement                                          

 

Figure_17.JPG

 

En Résume

- Etat d’un objet : Situation d’un objet que l’on désire connaître et gérer.

 -Transition : Passage d’un objet d’un état à un autre. Elle est déclenchée par un événement.

- Evénement : Stimulus qui provoque une (ou plusieurs) transition(s). A chaque stimulus  peut correspondre une action responsable des modifications.

 

II.3 .2 .3   Diagramme d’activité

 

 

3.1    Présentation générale

Les diagrammes d'activités permettent de mettre l'accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du cheminement de flots[5] de contrôle et de flots de données. Ils permettent ainsi de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation.

Les diagrammes d'activités sont relativement proches des diagrammes d'états-transitions dans leur présentation, mais leur interprétation est sensiblement différente. Les diagrammes d'états-transitions sont orientés vers des systèmes réactifs, mais ils ne donnent pas une vision satisfaisante d'un traitement faisant intervenir plusieurs classeurs et doivent être complétés, par exemple, par des diagrammes de séquence. Au contraire, les diagrammes d'activités ne sont pas spécifiquement rattachés à un classeur particulier. On peut attacher un diagramme d'activités à n'importe quel élément de modélisation afin de visualiser, spécifier, construire ou documenter le comportement de cet élément.

La différence principale entre les diagrammes d'interaction et les diagrammes d'activités est que les premiers mettent l'accent sur le flot de contrôle d'un objet à l'autre, tandis que les seconds insistent sur le flot de contrôle d'une activité à l'autre [25].

Les concepts communs ou très proches entre le diagramme d’activité et le diagramme d’état-transition sont :

·         transition ;

·         nœud initial (état initial) ;

·         nœud final (état final) ;

·         ⊗ nœud de fin flot (état de sortie) ;

·         ◊ nœud de décision (choix) ;

Le formalisme reste identique pour ces nœuds de contrôle.

Les concepts spécifiques au diagramme d’activité sont :

·         nœud de bifurcation qui  permet à partir d’un flot unique entrant de créer plusieurs flots concurrents en sortie de la barre de synchronisation ;

·         nœud de jonction qui permet, à partir de plusieurs flots concurrents en entrée de la synchronisation, de produire un flot unique sortant. Le nœud de jonction est le symétrique du nœud de bifurcation ;

·         Un nœud de fusion-test permet d’avoir plusieurs flots entrants possibles et un seul flot sortant. Le flot sortant est donc exécuté dès qu’un des flots entrants est activé ;

·         Un  pin d’entrée et de sortie représente un paramètre que l’on peut spécifier en entrée ou en sortie d’une action. Un nom de donnée et un type de donnée peuvent être associés au pin. Un paramètre peut être de type objet ;

·         Un nœud d’objet permet de représenter le flot de données véhiculé entre les actions. Les objets peuvent se représenter de deux manières différentes : soit en utilisant le pin d’objet soit en représentant explicitement un objet ;

·         partition : UML permet aussi d’organiser la présentation du diagramme d’activité en couloir d’activités. Chaque couloir correspond à un domaine de responsabilité d’un certain nombre d’actions [26].

 

3.2    Concepts d’action et d’activités

Ces concepts sont au cœur du diagramme d’activité.

Action :

Une action est le plus petit traitement qui puisse être exprimé en UML. Une action a une incidence sur l'état du système ou en extrait une information. Les actions sont des étapes discrètes à partir desquelles se construisent les comportements. La notion d'action est à rapprocher de la notion d'instruction élémentaire d'un langage de programmation (comme C++ ou Java). Une action peut être, par exemple :

  • une affectation de valeur à des attributs ;

  • un accès à la valeur d'une propriété structurelle (attribut ou terminaison d'association) ;

  • la création d'un nouvel objet ou lien ;

  • un calcul arithmétique simple ;

  • l'émission d'un signal ;

  • la réception d'un signal.

Activité :

Une activité définit un comportement décrit par un séquencèrent organisé d'unités dont les éléments simples sont les actions. Le flot d'exécution est modélisé par des nœuds reliés par des arcs (transitions). Le flot de contrôle reste dans l'activité jusqu'à ce que les traitements soient terminés. Une activité est composée de trois types de nœuds :

·         nœud d’exécution (action, transition) ;

·         nœud de contrôle (nœud initial, nœud final, flux de sortie, nœud de bifurcation, nœud de jonction, nœud de fusion-test, nœud de test-décision, pin d’entrée et de sortie) ;

·         nœud d’objet.

3.3     Exemple de représentation d’un diagramme d’activité

 

 

Figure_18.JPG

 

II.3 .2 . 4   Diagramme de séquence

Le diagramme de séquence (DSE), en anglais «sequence diagram» ou « interaction diagram», est parmi les nouveautés des vues dynamiques de l’UML 2 qui permet d'examiner le comportement des objets et les modifications d'états des objets suite aux réceptions de messages.

L’objectif du DSE est de représenter les interactions entre objets en indiquant la chronologie des échanges. Dans son ouvrage « Merise et UML », Gabay Joseph définit le diagramme de séquence comme étant un ensemble d’acteurs qui interagissent les uns les autres pendant la séquence.

En effet, le diagramme de séquence est une représentation intuitive lorsque l'on souhaite concrétiser des interactions entre deux entités (deux sous-systèmes ou deux classes.). Un diagramme de séquence se représente globalement dans un grand rectangle avec indication du nom du diagramme en haut à gauche.

La plupart des éléments utilisés par les digrammes étant communs, seuls les éléments nouveaux seront précisés :

 

1.      Interaction

Dans un diagramme de séquence, les objets communiquent en échangeant des messages représentés au moyen de flèches horizontales, orientés de l’émetteur de message vers le destinataire. Cet échange de message caractérise toute interaction.

Par définition, « une interaction modélise un comportement dynamique entre objets. Elle se traduit par un envoi de message entre objets » [27].

2.      Ligne de vie

Une ligne de vie représente l’ensemble des opérations exécutées par un objet. Un message reçu par un objet déclenche l’exécution d’une opération. Le retour d’information peut être implicite (cas général) ou explicite à l’aide d’un message de retour [28].

3.      Type de messages

Le message définit une communication particulière entre les lignes de vie ; dès sa réception par un objet, il déclenche l’exécution d’une opération. Plusieurs types de messages existent, mais les plus communs sont message synchrone et asynchrone.

• Message synchrone : Dans ce cas l’émetteur reste en attente de la réponse à son message avant de poursuivre ses actions. La flèche avec extrémité pleine symbolise ce type de message. Le message retour peut ne pas être représenté car il est inclus dans la fin d’exécution de l’opération de l’objet destinataire du message.

 

 

 

Figure_19.JPG

• Message asynchrone : Dans ce cas, l’émetteur n’attend pas la réponse à son message, il poursuit l’exécution de ses opérations. C’est une flèche avec une extrémité non pleine qui symbolise ce type de message.

 

 

Figure_20.JPG

 

                  4. Création et destruction d’objet

Si un objet est créé par une opération, celui-ci n’apparaît qu’au moment où il est créé. Si l’objet est détruit par une opération, la destruction se représente par « X ».

 

 

Figure_21.JPG

 

 

 


[1] OMT : Méthode de spécification par modélisation des besoins à la mode en 1995.

[2] OOSE : Méthode d’analyse et de conception orienté objet.

[3] OMG : Association de professionnels de l’informatique orienté objet.

[4] Encapsulation : Le fait d’interdire l’accès à la structure interne d’un objet.

[5] Flot : flux de données.

Ajouter un commentaire

Restricted HTML

  • Vous pouvez aligner les images (data-align="center"), mais également les vidéos, citations, etc.
  • Vous pouvez légender les images (data-align="center"), mais également les vidéos, citations, etc.