UML (1)

UML est un langage standard pour spécifier, visualiser, construire et documenter

artefacts des systèmes logiciels.
UML a été créé par l'Object Management Group (OMG) et le projet de spécification
UML 1.0 a été proposé à l'OMG en janvier 1997.
OMG fait continuellement des efforts pour créer une véritable norme de l'industrie.

UML signifie Langue de Modélisation Unifiée.

UML est différent des autres langages de programmation courants tels que C++,
Java, COBOL, etc.

UML est un langage pictural utilisé pour faire des plans logiciels.

UML peut être décrit comme un langage de modélisation visuelle à usage

général pour visualiser, spécifier, construire et documenter un système logiciel.

Bien que UML soit généralement utilisé pour modéliser des systèmes logiciels, il
n'est pas limité dans cette limite. Il est également utilisé pour modéliser des
systèmes non logiciels. Par example, le flux de processus dans une unité de
fabrication, etc.

Basics

Objets − Les objets représentent une entité et le bloc de construction de base.

Classe − Class est l'empreinte bleue d'un objet.

Abstraction − Abstraction représente le comportement d'une entité du monde

réel.

Encapsulation − Encapsulation est le mécanisme de liaison des données

ensemble et les cacher du monde extérieur.

Héritage − L'héritage est le mécanisme de création de nouvelles classes à partir

de classes existantes.

Polymorphisme − Il définit le mécanisme d'exister sous différentes formes.

UML (1) 1
UML (1) 2
UML (1) 3
UML (1) 4
UML (1) 5
UML (1) 6
UML (1) 7
UML (1) 8
UML (1) 9
UML (1) 10
UML (1) 11
 Diagramme de classe
Les diagrammes de classe sont les diagrammes les plus courants utilisés dans UML.
Le diagramme de classe comprend des classes, des interfaces, des associations et
des collaborations. Les diagrammes de classe représentent essentiellement la vue
orientée objet d'un système, qui est de nature statique.

La classe active est utilisée dans un diagramme de classe pour représenter la

concurrence du système.
Le diagramme de classe représente l'orientation objet d'un système. Par
conséquent, il est généralement utilisé à des fins de développement. Il s'agit du
diagramme le plus utilisé au moment de la construction du système.

Diagramme d'objet

UML (1) 12
 Les diagrammes d'objets peuvent être décrits comme une instance du diagramme
de classes. Ainsi, ces diagrammes sont plus proches des scénarios réels où nous
implémentons un système.
Les diagrammes d'objets sont un ensemble d'objets et leur relation est comme des
diagrammes de classe. Ils représentent également la vue statique du système.
L'utilisation de diagrammes d'objets est similaire aux diagrammes de classes, mais
ils sont utilisés pour construire le prototype d'un système dans une perspective
pratique.

Diagramme des composants

Les diagrammes de composants représentent un ensemble de composants et leurs
relations. Ces composants sont constitués de classes, d'interfaces ou de
collaborations. Les diagrammes de composants représentent la vue de mise en
œuvre d'un système.
Pendant la phase de conception, les artefacts logiciels ( classes, interfaces, etc. )
d'un système sont disposés en différents groupes en fonction de leur relation.
Maintenant, ces groupes sont connus comme des composants.

Enfin, on peut dire que les diagrammes de composants sont utilisés pour visualiser
la mise en œuvre.

Diagramme de déploiement
Les diagrammes de déploiement sont un ensemble de nœuds et leurs relations. Ces
nœuds sont des entités physiques où les composants sont déployés.
Les diagrammes de déploiement sont utilisés pour visualiser la vue de déploiement
d'un système. Ceci est généralement utilisé par l'équipe de déploiement.

Diagrammes comportementaux
Tout système peut avoir deux aspects, statique et dynamique. Un modèle est
considéré comme complet lorsque les deux aspects sont entièrement couverts.

Les diagrammes comportementaux capturent essentiellement l'aspect dynamique

d'un système. L'aspect dynamique peut être décrit comme les parties
changeantes/mobiles d'un système.
UML a les cinq types suivants de diagrammes comportementaux −

Utilisez le diagramme de cas

UML (1) 13
 Séquence diagramme

Diagramme de collaboration

Diagramme d'état

Diagramme d'activité

Utilisez Case Diagram

Les diagrammes de cas d'utilisation sont un ensemble de cas d'utilisation, d'acteurs
et de leurs relations. Ils représentent la vue de cas d'utilisation d'un système.
Un cas d'utilisation représente une fonctionnalité particulière d'un système. Par
conséquent, le diagramme de cas d'utilisation est utilisé pour décrire les relations
entre les fonctionnalités et leurs contrôleurs internes/externes. Ces contrôleurs sont
connus comme acteurs.

Séquence Diagramme
Un diagramme de séquence est un diagramme d'interaction. D'après le nom, il est
clair que le diagramme traite de certaines séquences, qui sont la séquence de
messages circulant d'un objet à un autre.
L'interaction entre les composantes d'un système est très importante du point de vue
de la mise en œuvre et de l'exécution. Le diagramme de séquence est utilisé pour
visualiser la séquence d'appels dans un système pour effectuer une fonctionnalité
spécifique.

Diagramme de collaboration
Le diagramme de collaboration est une autre forme de diagramme d'interaction. Il
représente la structure organisation d'un système et des messages envoyés / reçus.
L'organisation structurelle se compose d'objets et de liens.

Le but du diagramme de collaboration est similaire au diagramme de séquence.

Cependant, le but spécifique du diagramme de collaboration est de visualiser
l'organisation des objets et leur interaction.

Diagramme d'activité
Le diagramme d'activité décrit le flux de contrôle dans un système. Il se compose
d'activités et de liens. Le flux peut être séquentiel, simultané ou ramifié.
Les activités ne sont que les fonctions d'un système. Des nombres de diagrammes
d'activité sont préparés pour capturer l'ensemble du flux dans un système.

UML (1) 14
 Les diagrammes d'activité sont utilisés pour visualiser le flux de commandes dans un
système. Ceci est prêt à avoir une idée du fonctionnement du système une fois
exécuté.

Objectif des Diagrammes de Classe

Le diagramme de classe a pour but de modéliser la vue statique d'une application.
Les diagrammes de classe sont les seuls diagrammes qui peuvent être directement
cartographiés avec des langages orientés objet et donc largement utilisés au
moment de la construction.

Les diagrammes UML comme le diagramme d'activité, le diagramme de séquence

ne peuvent donner que le flux de séquence de l'application, mais le diagramme de
classe est un peu différent. Il s'agit du diagramme UML le plus populaire de la
communauté des codeurs.
Le but du diagramme de classe peut être résumé comme −

Analyse et conception de la vue statique d'une application.

Décrivez les responsabilités d'un système.

Base pour les diagrammes de composants et de déploiement.

Ingénierie avant et arrière.

Comment dessiner un diagramme de classe?

Les diagrammes de classe sont les diagrammes UML les plus populaires utilisés
pour la construction de logiciels applications. Il est très important d'apprendre la
procédure de dessin du diagramme de classe.
Les diagrammes de classe ont beaucoup de propriétés à considérer lors du dessin,
mais ici, le diagramme sera considéré à partir d'une vue de haut niveau.

Le diagramme de classes est essentiellement une représentation graphique de la

vue statique du système et représente différents aspects de l'application. Une
collection de diagrammes de classes représente l'ensemble du système.
Les points suivants doivent être mémorisés lors du dessin d'un diagramme de
classes −

Le nom du diagramme de classes doit être significatif pour décrire l'aspect du

système.

Chaque élément et ses relations doivent être identifiés à l'avance.

UML (1) 15
 La responsabilité (attributs et méthodes) de chaque classe doit être clairement
identifiée

Pour chaque classe, le nombre minimum de propriétés doit être spécifié, car les
propriétés inutiles rendront le diagramme compliqué.

Utilisez des notes chaque fois que nécessaire pour décrire certains aspects du
diagramme. À la fin du dessin, il devrait être compréhensible pour le
développeur/codeur.

Enfin, avant de faire la version finale, le diagramme doit être dessiné sur du
papier ordinaire et retravaillé autant de fois que possible pour le corriger.

Le diagramme suivant est un exemple de Système d'Ordre d'une application. Il décrit

un aspect particulier de l'ensemble de l'application.

Tout d'abord, la Commande et le Client sont identifiés comme les deux éléments
du système. Ils ont une relation un-à-plusieurs car un client peut avoir plusieurs
commandes.

La classe Order est une classe abstraite et elle a deux classes concrètes
(relation d'héritage) SpecialOrder et NormalOrder.

Les deux classes héritées ont toutes les propriétés comme classe Order. En
outre, ils ont des fonctions supplémentaires comme dispatch () et receive ().

Où Utiliser les Diagrammes de Classe?

Le diagramme de classe est un diagramme statique et il est utilisé pour modéliser la
vue statique d'un système. La vue statique décrit le vocabulaire du système.

UML (1) 16
 Le diagramme de classes est également considéré comme la base des diagrammes
de composants et de déploiement. Les diagrammes de classe ne sont pas
seulement utilisés pour visualiser la vue statique du système, mais ils sont
également utilisés pour construire le code exécutable pour l'ingénierie directe et
inverse de tout système.
Généralement, les diagrammes UML ne sont pas directement mappés avec des
langages de programmation orientés objet, mais le diagramme de classe est une
exception.
Le diagramme de classe montre clairement le mappage avec des langages orientés
objet tels que Java, C++, etc. De l'expérience pratique, diagramme de classe est
généralement utilisé à des fins de construction.
En un mot, on peut dire que les diagrammes de classes sont utilisés pour −

Décrire la vue statique du système.

Affichage de la collaboration entre les éléments de la vue statique.

Décrire les fonctionnalités réalisées par le système.

Construction d'applications logicielles utilisant des langages orientés objet.

Objectif des Diagrammes d'Objets

Le but d'un diagramme doit être compris clairement pour le mettre en œuvre
pratiquement. Les objectifs des diagrammes d'objets sont similaires aux diagrammes
de classes.
La différence est qu'un diagramme de classes représente un modèle abstrait
composé de classes et de leurs relations. Cependant, un diagramme d'objet
représente une instance à un moment particulier, qui est de nature concrète.
Cela signifie que le diagramme d'objet est plus proche du comportement réel du
système. Le but est de capturer la vue statique d'un système à un moment donné.
Le but du diagramme d'objet peut être résumé comme −

Ingénierie avant et arrière.

Relations d'objet d'un système

Vue statique d'une interaction.

Comprendre le comportement des objets et leur relation d'un point de vue

pratique

UML (1) 17
 Comment dessiner un Diagramme d'Objet?
Nous avons déjà discuté du fait qu'un diagramme d'objets est une instance d'un
diagramme de classes. Cela implique qu'un diagramme d'objet se compose
d'instances de choses utilisées dans un diagramme de classes.
Ainsi, les deux diagrammes sont faits des mêmes éléments de base, mais sous une
forme différente. Dans le diagramme de classe, les éléments sont sous forme
abstraite pour représenter l'impression bleue et dans le diagramme d'objet, les
éléments sont sous forme concrète pour représenter l'objet du monde réel.
Pour capturer un système particulier, le nombre de diagrammes de classes est limité.
Cependant, si nous considérons les diagrammes d'objets, nous pouvons avoir un
nombre illimité d'instances, qui sont uniques par nature. Seuls les cas sont pris en
compte, qui ont un impact sur la système.
De la discussion ci-dessus, il est clair qu'un seul diagramme d'objet ne peut pas
capturer tout le les instances nécessaires ou plutôt ne peuvent pas spécifier tous les
objets d'un système. Par conséquent, la solution est −

Tout d'abord, analysez le système et décidez quelles instances ont des données
et des associations importantes.

Deuxièmement, ne considérez que les instances qui couvriront la fonctionnalité.

Troisièmement, faites une certaine optimisation car le nombre d'instances est

illimité.

Avant de dessiner un diagramme d'objet, les choses suivantes doivent être

mémorisées et comprises clairement −

Les diagrammes d'objets sont constitués d'objets.

Le lien dans le diagramme d'objets est utilisé pour connecter des objets.

Les objets et les liens sont les deux éléments utilisés pour construire un
diagramme d'objet.

Après cela, les choses suivantes doivent être décidées avant de commencer la
construction du diagramme −

Le diagramme d'objet doit avoir un nom significatif pour indiquer sa finalité.

Les éléments les plus importants doivent être identifiés.

L'association entre les objets doit être clarifiée.

UML (1) 18
 Les valeurs des différents éléments doivent être capturées pour être incluses
dans le diagramme d'objet.

Ajoutez des notes appropriées aux points où plus de clarté est requise.

Le diagramme suivant est un exemple de diagramme d'objet. Il représente le

système de gestion des commandes dont nous avons discuté dans le chapitre
Diagramme de classe. Le diagramme suivant est une instance du système à un
moment particulier de l'achat. Il a ce qui suit objets.

Client

Ordre

Commande spéciale

Ordre normal

Maintenant, l'objet client ( C ) est associé à trois objets de commande ( O1, O2 et O3

). Ces objets de commande sont associés à des objets de commande spéciale et de
commande normale ( S1, S2 et N1 ). Le client a les trois commandes suivantes avec
des nombres différents ( 12, 32 et 40 ) pour le temps particulier considéré.
Le client peut augmenter le nombre de commandes à l'avenir et dans ce scénario, le
diagramme d'objets reflétera cela. Si l'ordre, l'ordre spécial et les objets d'ordre
normal sont observés, vous constaterez qu'ils ont certaines valeurs.
Pour les ordres, les valeurs sont 12, 32, et 40 ce qui implique que les objets ont ces
valeurs pour un moment particulier (ici le moment particulier où l'achat est effectué
est considéré comme le moment) où l'instance est capturée
Il en va de même pour les objets d'ordre spécial et d'ordre normal qui ont un nombre
d'ordres de 20, 30 et 60. Si un autre moment d'achat est considéré, ces valeurs
changeront en conséquence.

Où Utiliser les Diagrammes d'Objets?

UML (1) 19
 Les diagrammes d'objets peuvent être imaginés comme l'instantané d'un système en
cours d'exécution à un moment donné. Prenons un exemple de train en marche
Maintenant, si vous prenez un cliché du train en marche, vous trouverez une image
statique de celui-ci ayant le − suivant

Un état particulier qui est en cours d'exécution.

Un nombre particulier de passagers. qui changera si le snap est pris dans un

temps différent

Ici, on peut imaginer que le claquement du train en marche est un objet ayant les
valeurs ci-dessus. Et cela est vrai pour tout système simple ou complexe de la vie
réelle.
En un mot, on peut dire que les diagrammes d'objets sont utilisés pour −

Réaliser le prototype d'un système.

Inverse ingénierie.

Modélisation de structures de données complexes.

Comprendre le système d'un point de vue pratique.

Objectif des Diagrammes de Composantes

Le diagramme de composants est un type particulier de diagramme en UML. Le but
est également différent de tous les autres diagrammes discutés jusqu'à présent. Il ne
décrit pas la fonctionnalité du système, mais il décrit les composants utilisés pour
réaliser ces fonctionnalités.
Ainsi, de ce point de vue, les diagrammes de composants sont utilisés pour
visualiser les composants physiques dans un système. Ces composants sont des
bibliothèques, des paquets, des fichiers, etc.

Les diagrammes de composants peuvent également être décrits comme une vue
d'implémentation statique d'un système. L'implémentation statique représente
l'organisation des composants à un moment particulier.
Un diagramme à composant unique ne peut pas représenter l'ensemble du système,
mais une collection de les diagrammes sont utilisés pour représenter l'ensemble.
Le but du diagramme de composant peut être résumé comme −

Visualiser les composants d'un système.

Construire des exécutables en utilisant l'ingénierie avant et arrière.

UML (1) 20
 Décrire l'organisation et les relations des composants.

Comment dessiner un Diagramme de Composant?

Les diagrammes de composants sont utilisés pour décrire les artefacts physiques
d'un système. Cet artefact inclut les fichiers, exécutables, bibliothèques, etc
Le but de ce diagramme est différent. Les diagrammes de composants sont utilisés
pendant la phase de mise en œuvre d'une application. Cependant, il est préparé
bien à l'avance pour visualiser les détails de l'implémentation.

Initialement, le système est conçu en utilisant différents diagrammes UML, puis

lorsque les artefacts sont prêts, les diagrammes de composants sont utilisés pour
avoir une idée de l'implémentation.
Ce diagramme est très important car sans lui, l'application ne peut pas être
implémentée efficacement. Un diagramme de composants bien préparé est
également important pour d'autres aspects tels que la performance de l'application,
la maintenance, etc.

Avant de dessiner un diagramme de composants, les artefacts suivants doivent être

clairement identifiés −

Fichiers utilisés dans le système.

Bibliothèques et autres artefacts pertinents pour l'application.

Relations entre les artefacts.

Après avoir identifié les artefacts, les points suivants doivent être gardés à l'esprit.

Utilisez un nom significatif pour identifier le composant pour lequel le diagramme

doit être dessiné.

Préparer une mise en page mentale avant de produire les outils d'utilisation.

Utilisez des notes pour clarifier les points importants.

Voici un diagramme de composants pour le système de gestion des commandes. Ici,

les artefacts sont des fichiers. Le diagramme montre les fichiers dans l'application et
leurs relations. En réalité, le diagramme de composants contient également dlls,
bibliothèques, dossiers, etc.
Dans le diagramme suivant, quatre fichiers sont identifiés et leurs relations sont
produites. Le diagramme de composants ne peut pas être directement mis en
correspondance avec d'autres diagrammes UML discutés dans la mesure où il est
dessiné à des fins complètement différentes.

UML (1) 21
 Où Utiliser les Diagrammes de Composantes?
Nous avons déjà décrit que les diagrammes de composants sont utilisés pour
visualiser la vue d'implémentation statique d'un système. Les diagrammes de
composants sont des types spéciaux de diagrammes UML utilisés à des fins
différentes.
Ces diagrammes montrent les composants physiques d'un système. Pour le clarifier,
on peut dire que les diagrammes de composants décrivent l'organisation des
composants dans un système.
L'organisation peut être décrite comme l'emplacement des composants dans un
système. Ces composants sont organisés d'une manière spéciale pour répondre aux
exigences du système.
Comme nous l'avons déjà mentionné, ces composants sont des bibliothèques, des
fichiers, des exécutables, etc. Avant la mise en oeuvre de l'application, ces
composants doivent être organisés. Cette organisation de composants est
également conçue séparément dans le cadre de l'exécution du projet.

Les diagrammes des composants sont très importants du point de vue de la mise en
œuvre. Ainsi, l'équipe de mise en œuvre d'une demande doit avoir une connaissance
appropriée des détails du composant
Les diagrammes des composants peuvent être utilisés pour −

Modélisez les composants d'un système.

Modélisez le schéma de la base de données.

Modélisez les exécutables d'une application.

UML (1) 22
 Modélisez le code source du système.

Objectif des Diagrammes de Déploiement

Le terme Déploiement lui-même décrit le but du diagramme. Les diagrammes de
déploiement sont utilisés pour décrire les composants matériels, où les composants
logiciels sont déployés. Les diagrammes de composants et les diagrammes de
déploiement sont étroitement liés.
Les diagrammes de composants sont utilisés pour décrire les composants et les
diagrammes de déploiement montrent comment ils sont déployés dans le matériel.
UML est principalement conçu pour se concentrer sur les artefacts logiciels d'un
système. Cependant, ces deux diagrammes sont des diagrammes spéciaux utilisés
pour se concentrer sur les composants logiciels et matériels.
La plupart des diagrammes UML sont utilisés pour gérer les composants logiques,
mais les diagrammes de déploiement sont conçus pour se concentrer sur la
topologie matérielle d'un système. Les diagrammes de déploiement sont utilisés par
les ingénieurs système.
Le but des diagrammes de déploiement peut être décrit comme −

Visualiser la topologie matérielle d'un système.

Décrire les composants matériels utilisés pour déployer des composants

logiciels.

Décrire les nœuds de traitement runtime.

Comment dessiner un Diagramme de Déploiement?

Le diagramme de déploiement représente la vue de déploiement d'un système. Il est
lié au diagramme de composants car les composants sont déployés à l'aide des
diagrammes de déploiement. Un diagramme de déploiement est composé de
nœuds. Les nœuds ne sont rien d'autre que physiques matériel utilisé pour déployer
l'application.
Les diagrammes de déploiement sont utiles pour les ingénieurs système. Un
diagramme de déploiement efficace est très important car il contrôle les paramètres
suivants −

Performance

Évolutivité

UML (1) 23
 Maintenabilité

Portabilité

Avant de dessiner un diagramme de déploiement, les artefacts suivants doivent être

identifiés −

Noeuds

Relations entre nœuds

Voici un exemple de diagramme de déploiement pour donner une idée de la vue de

déploiement du système de gestion des commandes. Ici, nous avons montré des
nœuds comme −

Moniteur

Modem

Serveur de cache

Serveur

L'application est supposée être une application Web, qui est déployée dans un
cluster environnement utilisant le serveur 1, le serveur 2 et le serveur 3. L'utilisateur
se connecte à l'application en utilisant Internet. Le contrôle s'écoule du serveur de
mise en cache vers l'environnement en cluster.

Où Utiliser les Diagrammes de Déploiement?

UML (1) 24
 Les diagrammes de déploiement sont principalement utilisés par les ingénieurs
système. Ces diagrammes sont utilisés pour décrire les composants physiques
(matériel), leur distribution et leur association.

Les diagrammes de déploiement peuvent être visualisés comme les

composants/nœuds matériels sur lesquels résident les composants logiciels.
Des applications logicielles sont développées pour modéliser des processus métier
complexes. Des applications logicielles efficaces ne suffisent pas pour répondre aux
exigences de l'entreprise. Les exigences commerciales peuvent être décrites comme
la nécessité de prendre en charge le nombre croissant d'utilisateurs, temps de
réponse rapide, etc.
Pour répondre à ces types d'exigences, les composants matériels doivent être
conçus de manière efficace et rentable.
Les applications logicielles actuelles sont de nature très complexe. Les applications
logicielles peuvent être autonomes, Web, distribuées, mainframe et bien d'autres.
Par conséquent, il est très important de concevoir les composants matériels
efficacement.
Les diagrammes de déploiement peuvent être utilisés −

Pour modéliser la topologie matérielle d'un système.

Pour modéliser le système embarqué.

Pour modéliser les détails matériels d'un système client/serveur.

Pour modéliser les détails matériels d'une application distribuée.

Pour l'ingénierie Forward et Reverse.

Diagrammes de cas d'utilisation

Le diagramme de cas d'utilisation a pour but de capturer l'aspect dynamique d'un
système. Cependant, cette définition est trop générique pour décrire le but, car les
quatre autres diagrammes ( activité, séquence, collaboration et Statechart ) ont
également le même objectif. Nous examinerons un objectif spécifique, qui le
distinguera des quatre autres diagrammes.
Les diagrammes de cas d'utilisation sont utilisés pour recueillir les exigences d'un
système, y compris interne et influences externes. Ces exigences sont
principalement des exigences de conception. Par conséquent, lorsqu'un système est
analysé pour rassembler ses fonctionnalités, des cas d'utilisation sont préparés et
des acteurs sont identifiés.

UML (1) 25
 Une fois la tâche initiale terminée, les diagrammes de cas d'utilisation sont
modélisés pour présenter la vue extérieure.
En bref, les diagrammes de cas d'utilisation peuvent être dits comme suit −

Utilisé pour rassembler les exigences d'un système.

Utilisé pour obtenir une vue extérieure d'un système.

Identifier les facteurs externes et internes qui influencent le système.

Montrer l'interaction entre les exigences sont des acteurs.

Comment dessiner un Diagramme de Cas

d'Utilisation?
Les diagrammes de cas d'utilisation sont pris en compte pour l'analyse d'exigences
de haut niveau d'un système. Lorsque les exigences d'un système sont analysées,
les fonctionnalités sont capturées dans les cas d'utilisation.
Nous pouvons dire que les cas d'utilisation ne sont rien d'autre que les
fonctionnalités du système écrites de manière organisée. La deuxième chose qui est
pertinente pour les cas d'utilisation sont les acteurs. Les acteurs peuvent être définis
comme quelque chose qui interagit avec le système.
Les acteurs peuvent être un utilisateur humain, certaines applications internes, ou
peuvent être des applications externes. Lorsque nous prévoyons de dessiner un
diagramme de cas d'utilisation, nous devrions avoir les éléments suivants identifiés.

Fonctionnalités à représenter comme cas d'utilisation

Acteurs

Relations entre les cas d'utilisation et les acteurs.

Des diagrammes de cas d'utilisation sont dessinés pour saisir les exigences
fonctionnelles d'un système. Après en identifiant les éléments ci-dessus, nous
devons utiliser les directives suivantes pour dessiner un diagramme de cas
d'utilisation efficace

Le nom d'un cas d'utilisation est très important. Le nom doit être choisi de
manière à pouvoir identifier les fonctionnalités réalisées.

Donnez un nom approprié aux acteurs.

Afficher clairement les relations et les dépendances dans le diagramme.

UML (1) 26
 N'essayez pas d'inclure tous les types de relations, comme objectif principal du
diagramme c'est identifier les exigences.

Utilisez des notes chaque fois que nécessaire pour clarifier certains points
importants.

Voici un exemple de diagramme de cas d'utilisation représentant le système de

gestion des commandes. Par conséquent, si nous examinons le diagramme, nous
trouverons trois cas d'utilisation (Ordre, SpecialOrder et NormalOrder) et un acteur
qui est le client.
Les cas d'utilisation de SpecialOrder et NormalOrder sont étendus
de Commande cas d'utilisation. Par conséquent, ils ont étendu la relation. Un autre
point important est d'identifier la limite du système, qui est montré dans l'image. Le
client acteur se trouve en dehors du système car il est un utilisateur externe du
système.

Où Utiliser un Diagramme de Cas d'Utilisation?

Comme nous l'avons déjà discuté, il existe cinq diagrammes en UML pour modéliser
la vue dynamique d'un système. Maintenant, chaque modèle a un but spécifique à
utiliser. En fait, ces objectifs spécifiques sont différents angles d'un système en cours
d'exécution.
Pour comprendre la dynamique d'un système, nous devons utiliser différents types
de diagrammes. Le diagramme de cas d'utilisation est l'un d'entre eux et son but
spécifique est de rassembler les exigences du système et les acteurs.
Les diagrammes de cas d'utilisation spécifient les événements d'un système et leurs
flux. Mais le diagramme de cas d'utilisation ne décrit jamais comment ils sont mis en
œuvre. Le diagramme de cas d'utilisation peut être imaginé comme une boîte noire
où seules l'entrée, la sortie et la fonction de la boîte noire sont connues.

UML (1) 27
 Ces diagrammes sont utilisés à un très haut niveau de conception. Cette conception
de haut niveau est affinée encore et encore pour obtenir une image complète et
pratique du système. Un cas d'utilisation bien structuré décrit également la condition
préalable, la condition de poste et les exceptions. Ces éléments supplémentaires
sont utilisés pour faire des cas de test lors de l'exécution du test.
Bien que le cas d'utilisation ne soit pas un bon candidat pour l'ingénierie avant et
arrière, ils sont toujours utilisés d'une manière légèrement différente pour faire de
l'ingénierie avant et arrière. Il en va de même pour la rétro-ingénierie. Le diagramme
de cas d'utilisation est utilisé différemment pour le rendre approprié à l'ingénierie
inverse.
En ingénierie directe, des diagrammes de cas d'utilisation sont utilisés pour faire des
cas d'essai et en ingénierie inverse, des cas d'utilisation sont utilisés pour préparer
les détails des exigences de l'application existante.
Les diagrammes de cas d'utilisation peuvent être utilisés pour −

Analyse des besoins et conception de haut niveau.

Modéliser le contexte d'un système.

Inverse ingénierie.

Ingénierie avancée.

Objectif des diagrammes d'interaction (Sequence)

Le but des diagrammes d'interaction est de visualiser le comportement interactif du
système. Visualiser l'interaction est une tâche difficile. Par conséquent, la solution
consiste à utiliser différents types de modèles pour capturer les différents aspects de
l'interaction.
Les diagrammes de séquence et de collaboration sont utilisés pour capturer la
nature dynamique mais sous un angle différent.
Le but du diagramme d'interaction est −

Pour capturer le comportement dynamique d'un système.

Décrire le flux de messages dans le système.

Décrire l'organisation structurelle des objets.

Décrire l'interaction entre les objets.

Comment dessiner un Diagramme d'Interaction?

UML (1) 28
 Comme nous l'avons déjà discuté, le but des diagrammes d'interaction est de
capturer l'aspect dynamique d'un système. Donc, pour capturer l'aspect dynamique,
nous devons comprendre ce qu'est un aspect dynamique et comment il est visualisé.
L'aspect dynamique peut être défini comme instantané du système en cours
d'exécution à un moment donné
Nous avons deux types de diagrammes d'interaction en UML. L'un est le diagramme
de séquence et le le diagramme de collaboration est le suivant. Le diagramme de
séquence capture la séquence temporelle de le flux de message d'un objet à l'autre
et le diagramme de collaboration décrit le organisation d'objets dans un système
participant au flux de messages.
Les éléments suivants doivent être clairement identifiés avant de dessiner le
diagramme d'interaction

Objets participant à l'interaction.

Le message circule entre les objets.

La séquence dans laquelle les messages circulent.

Organisation d'objets.

Voici deux diagrammes d'interaction modélisant le système de gestion des

commandes. Le premier diagramme est un diagramme de séquence et le second est
un diagramme de collaboration

Le Diagramme Séquence
Le diagramme de séquence comporte quatre objets (Client, Order, SpecialOrder et
NormalOrder).
Le diagramme suivant montre la séquence de message pour SpecialOrder objet et le
même peut être utilisé en cas de NormalOrder objet. Il est important de comprendre
la séquence temporelle des flux de messages. Le flux de messages n'est rien d'autre
qu'un appel de méthode d'un objet.
Le premier appel est sendOrder () qui est une méthode de Ordre objet. Le prochain
appel est confirmer () qui est une méthode de SpecialOrder objet et le dernier appel
est Expédition () qui est une méthode de SpecialOrder objet. Le diagramme suivant
décrit principalement les appels de méthode d'un objet à l'autre, et c'est aussi le
scénario réel lorsque le système est en cours d'exécution.

UML (1) 29
 But des diagrammes d'activité
Les objectifs de base des diagrammes d'activité sont similaires aux quatre autres
diagrammes. Il capture le comportement dynamique du système. Quatre autres
diagrammes sont utilisés pour montrer le flux de messages d'un objet à un autre,
mais le diagramme d'activité est utilisé pour afficher le flux de messages d'une
activité à une autre.
L'activité est une opération particulière du système. Les diagrammes d'activité ne
sont pas seulement utilisés pour visualiser la nature dynamique d'un système, mais
ils sont également utilisés pour construire le système exécutable en utilisant des
techniques d'ingénierie avant et arrière. Le seul manquant chose dans le diagramme
d'activité est la partie message.
Il ne montre aucun flux de messages d'une activité à l'autre. Le diagramme d'activité
est parfois considéré comme l'organigramme. Bien que les diagrammes ressemblent
à un organigramme, ils ne le sont pas. Il montre différents flux tels que parallèle,
ramifié, simultané et unique.
Le but d'un diagramme d'activité peut être décrit comme −

Dessinez le flux d'activité d'un système.

Décrivez la séquence d'une activité à l'autre.

Décrivez le flux parallèle, ramifié et simultané du système.

UML (1) 30
 Comment dessiner un diagramme d'activité?
Les diagrammes d'activité sont principalement utilisés comme organigramme qui
comprend des activités réalisées par le système. Les diagrammes d'activité ne sont
pas exactement des organigrammes car ils ont des capacités supplémentaires. Ces
capacités supplémentaires incluent la ramification, le débit parallèle, le hydravion,
etc.
Avant de dessiner un diagramme d'activité, nous devons avoir une compréhension
claire des éléments utilisés dans le diagramme d'activité. L'élément principal d'un
diagramme d'activité est l'activité elle-même. Une activité est une fonction exécutée
par le système. Après avoir identifié les activités, nous devons comprendre comment
elles sont associées aux contraintes et aux conditions.

Avant de dessiner un diagramme d'activité, nous devons identifier les éléments

suivants −

Activités

Association

Conditions

Contraintes

Une fois que les paramètres mentionnés ci-dessus sont identifiés, nous devons faire
une disposition mentale de l'ensemble du flux. Cette disposition mentale est ensuite
transformée en diagramme d'activité.
Voici un exemple de diagramme d'activité pour le système de gestion des
commandes. Dans le diagramme, quatre activités sont identifiées qui sont associées
à des conditions. Un point important doit être clairement compris qu'un diagramme
d'activité ne peut pas être exactement assorti au code. Le diagramme d'activité est
conçu pour comprendre le flux d'activités et est principalement utilisé par les
utilisateurs professionnels
Le diagramme suivant est dessiné avec les quatre activités principales −

Envoyer la commande par le client

Réception de la commande

Confirmer la commande

Envoi de la commande

UML (1) 31
 Après réception de la demande de commande, des contrôles d'état sont effectués
pour vérifier s'il s'agit d'une commande normale ou spéciale. Une fois le type de
commande identifié, l'activité d'expédition est effectuée et marquée comme la fin du
processus.

Où Utiliser les Diagrammes d'Activité?

L'utilisation de base du diagramme d'activité est similaire aux quatre autres
diagrammes UML. L'utilisation spécifique est de modéliser le flux de contrôle d'une
activité à l'autre. Ce flux de contrôle n'inclut pas les messages.
Le diagramme d'activité est adapté pour modéliser le flux d'activité du système. Une
application peut avoir plusieurs systèmes. Le diagramme d'activité capture
également ces systèmes et décrit le flux d'un système à l'autre. Cette utilisation
spécifique n'est pas disponible dans d'autres diagrammes. Ces systèmes peuvent
être des bases de données, des files d'attente externes ou tout autre système.
Nous allons maintenant examiner les applications pratiques du diagramme d'activité.
De la discussion ci-dessus, il est clair qu'un diagramme d'activité est tiré d'un niveau
très élevé. Il donne donc une vue de haut niveau d'un système. Cette vue de haut
niveau est principalement pour les utilisateurs professionnels ou toute autre
personne qui n'est pas une personne technique.

UML (1) 32
 Ce diagramme est utilisé pour modéliser les activités qui ne sont que des exigences
commerciales. Le diagramme a plus d'impact sur la compréhension des entreprises
que sur les détails d'implémentation.
Le diagramme d'activité peut être utilisé pour −

Modéliser le flux de travail en utilisant les activités.

Modélisation des exigences commerciales.

Compréhension de haut niveau des fonctionnalités du système.

Enquêter sur les besoins de l'entreprise à un stade ultérieur.

But des diagrammes Statechart (Etat)

Le diagramme Statechart est l'un des cinq diagrammes UML utilisés pour modéliser
la nature dynamique d'un système. Ils définissent différents états d'un objet au cours
de sa vie et ces états sont modifiés par des événements. Les diagrammes Statechart
sont utiles pour modéliser les systèmes réactifs. Les systèmes réactifs peuvent être
définis comme un système qui répond à des événements externes ou internes.

Diagramme d'état décrit le flux de contrôle d'un état à un autre état. Les états sont
définis comme une condition dans laquelle un objet existe et il change quand un
événement est déclenché. Le but le plus important du diagramme Statechart est de
modéliser la durée de vie d'un objet de la création à la résiliation.
Diagrammes Statechart sont également utilisés pour l'ingénierie avant et arrière d'un
système. Cependant, le but principal est de modéliser le système réactif.
Voici les principaux objectifs de l'utilisation des diagrammes Statechart −

Pour modéliser l'aspect dynamique d'un système.

Modéliser la durée de vie d'un système réactif.

Décrire les différents états d'un objet pendant sa durée de vie.

Définir une machine d'état pour modéliser les états d'un objet.

Comment dessiner un diagramme Statechart?

Diagramme d'état est utilisé pour décrire les états de différents objets dans son cycle
de vie. L'accent est mis sur les changements d'état sur certains événements internes

UML (1) 33
 ou externes. Ces états d'objets sont importants pour les analyser et les mettre en
œuvre avec précision.
Les diagrammes de Statechart sont très importants pour décrire les états. Les états
peuvent être identifiés comme l'état des objets lorsqu'un événement particulier se
produit.
Avant de dessiner un diagramme Statechart, nous devons clarifier les points suivants
−

Identifier les objets importants à analyser.

Identifier les états.

Identifier les événements.

Voici un exemple de diagramme Statechart où l'objet de l'état de commande est

analysé
Le premier état est un état inactif à partir duquel le processus commence. Les
prochains États sont arrivés pour des événements tels que la demande d'envoi, la
demande de confirmation et la commande d'expédition. Ces événements sont
responsables de l'objet de changements d'ordre de l'état.
Pendant le cycle de vie d'un objet (, il commande ici un objet ), il passe par les états
suivants et il peut y avoir des sorties anormales. Cette sortie anormale peut se
produire en raison d'un problème dans le système. Lorsque tout le cycle de vie est
terminé, il est considéré comme une transaction complète, comme indiqué dans la
figure suivante. L'état initial et final d'un objet est également indiqué dans la figure
suivante.

UML (1) 34
 Où utiliser les diagrammes Statechart?
À partir de la discussion ci-dessus, nous pouvons définir les applications pratiques
d'un diagramme Statechart. Diagrammes Statechart sont utilisés pour modéliser
l'aspect dynamique d'un système comme les quatre autres diagrammes discutés
dans ce tutoriel. Cependant, il présente certaines caractéristiques distinctives pour
modéliser la nature dynamique.
Diagramme d'état définit les états d'un composant et ces changements d'état sont de
nature dynamique. Son but spécifique est de définir les changements d'état
déclenchés par les événements. Les événements sont des facteurs internes ou
externes qui influencent le système.
Diagrammes Statechart sont utilisés pour modéliser les états et aussi les
événements opérant sur le système. Lors de la mise en œuvre d'un système, il est
très important de clarifier les différents états d'un objet pendant sa durée de vie et
des diagrammes Statechart sont utilisés à cette fin. Lorsque ces états et événements
sont identifiés, ils sont utilisés pour le modéliser et ces modèles sont utilisés lors de
la mise en œuvre du système.

Si nous examinons la mise en œuvre pratique du diagramme Statechart, il est

principalement utilisé pour analyser les états des objets influencés par les

UML (1) 35
 événements. Cette analyse est utile pour comprendre le comportement du système
lors de son exécution.
L'utilisation principale peut être décrite comme −

Pour modéliser les états d'objet d'un système.

Pour modéliser le système réactif. Le système réactif est constitué d'objets

réactifs.

Identifier les événements responsables des changements d'état.

Ingénierie avant et arrière.

Les diagrammes UML sont utilisés pour modéliser différents aspects d'un système.
Les diagrammes de déploiement sont utilisés pour décrire les composants physiques
et leur distribution. Les diagrammes de cas d'utilisation sont utilisés pour recueillir les
exigences d'un système. Les diagrammes d'interaction visualisent le comportement
interactif du système. Les diagrammes d'activité sont utilisés pour modéliser le flux
de travail. Les diagrammes Statechart sont utilisés pour modéliser les états d'un
composant et les changements d'état déclenchés par les événements.

UML (1) 36