Si vous imprimez cette page, choisissez « Aperçu avant impression » dans votre navigateur, ou cliquez sur le lien Version imprimable dans la boîte à outils, vous verrez cette page sans ce message, ni éléments de navigation sur la gauche ou en haut.
Vous avez la permission de copier, distribuer et/ou modifier ce document selon les termes de la Licence de documentation libre GNU, version 1.2 ou plus récente publiée par la Free Software Foundation ; sans sections inaltérables, sans texte de première page de couverture et sans Texte de dernière page de couverture. Une copie de cette licence est inclue dans l'annexe nommée « Licence de documentation libre GNU ».
En raison de limitations techniques, la typographie souhaitable du titre, « Modélisation UML : Version imprimable Modélisation UML/Version imprimable », n'a pu être restituée correctement ci-dessus.
UML , "Unified Modeling Language" soit langage unifié pour la modélisation en français, représente l'état de l'art des langages de modélisation objet. Il fournit les fondements pour spécifier, construire, visualiser et décrire les artifices d'un système logiciel. Pour cela, UML se base sur une sémantique précise et sur une notation graphique expressive. Il définit des concepts de base et offre également des mécanismes d'extension de ces concepts. UML est un langage de modélisation objet. En tant que tel, il facilite l’expression et la communication de modèles en fournissant un ensemble de symboles et de règles qui régissent l'assemblage de ces symboles.
UML permet de modéliser de manière claire et précise la structure et le comportement d'un système indépendamment de toute méthode ou de tout langage de programmation. Les créateurs d'UML insistent tout particulièrement sur le fait qu'UML est un langage de modélisation et non une méthode.
UML est la fusion des langages Booch, OMT et OOSE il s'est rapidement imposé à la fois auprès des utilisateurs et sur le terrain de la normalisation.
UML n’est pas un langage propriétaire et est accessible à tous et les fabricants d’outils ainsi que les entreprises de formation peuvent librement en faire usage.
UML est donc un langage visuel qui permet de modéliser et de communiquer à propos de systèmes, par l'intermédiaire de diagrammes et de texte.
Modéliser, c’est décrire de manière visuelle et graphique les besoins et, les solutions fonctionnelles et techniques de votre projet logiciel.
On est d’accord que c’est plus facile de constituer un meuble à partir de schéma plutôt qu’une page de texte!
Cet exemple nous démontre que l’utilisation de schémas et d’illustrations rend quelque chose de complexe plus compréhensible.
Par exemple la figure 1.1 communique les informations suivantes :
- Un gestionnaire dirige une équipe exécutant un projet.
- Chaque gestionnaire possède un nom et un matricule, chaque gestionnaire peut démarrer ou terminer un projet.
- Chaque projet possède une date de début et une date de fin
L'histoire d'UML se compose de 5 périodes distinctes :
La période de fragmentation :
Entre le milieu des années 1970 et le milieu des années 1990, les organisations commencèrent à saisir la valeur du logiciel pour les entreprises, mais ne disposaient que d'une collection fragmentée de techniques permettant de le produire et de l'entretenir. Parmi les diverses techniques émergeantes et les méthodes se concentrant sur la production et la maintenance efficace des logiciels ( chacune d'elles possédant ses propres langages de modélisation), trois se démarquèrent :
La méthode BOOCH de Grady Booch mettait l'accent sur le design et la construction des systèmes logiciels.
La méthode OMT (Objet Modeling Technique) de James Rumbaugh insistait sur l'analyse des systèmes logiciels.
La méthode OOSE ( Object-Oriented Software Engineering) de Ivar Jacobson se consacrait au business engineering et à l'analyse des exigences.
Alors que les méthodes orientées objet commencaient à se développer sur la base des méthodes structurées, l'industrie s'est fragmentée entre ces trois et d'autres méthodes.
La période d'unification
UML 1.0 émergea entre le milieu des années 1990 et 1997. James Rumbaugh puis Ivar Jacobson rejoignirent Grady Booch chez Rational Software Corporation afin d’unifier leurs approches. Comme les organisations commençaient à saisir la valeur d'UML, le groupe de travail de L'OMG publia une requête RFP ( Request for proposal) afin d’établir un standard définissant la signification des concepts orientés objet. Rational Software Corporation forma le Consortium des Partenaires UML avec diverses autres organisations et soumit à l'OMG la version 1.0 d'UML en réponse à cette requête.
La période de normalisation
UML 1.1 émergea durant la deuxième moitié de 1997. Toutes les réponses à la requête RFP furent combinées dans la version 1.1 du langage. L'OMG adopta UML et assuma en novembre 1997 la responsabilité du développement futur de ce standard.
La période de révision
Plusieurs versions se succédèrent après l'adoption d'UML 1.1. L'OMG forma un groupe de révision chargé de recevoir les commentaires du public et d'apporter des corrections mineures au standard.
La période d'industrialisation
En parallèle à cette période de révision, l'OMG soumet UML à une normalisation internationale auprès de l'organisme ISO ( International Organisation for Standardization).
La compréhension des buts et de la vision du groupe OMG à propos du langage UML permet de mieux saisir les motivations sous-jacentes. Les buts de l'OMG étaient de rendre le langage UML :
Prêt à l'emploi
Expressif
Simple
Précis
Extensible
Indépendant d'une implémentation
Indépendant d'un processus
Grâce aux quatre premières caractéristiques, UML peut immédiatement être appliqué.
En raison de limitations techniques, la typographie souhaitable du titre, « Modélisation UML : Version imprimable Modélisation UML/Version imprimable », n'a pu être restituée correctement ci-dessus.
L’alphabet d’UML est composé essentiellement de formes géométriques et symboliques (rectangles, lignes, autres éléments graphiques) et de chaînes de caractères. Ces éléments n’ont pas de signification propre ; les plus petites unités porteuses de sens dans un langage sont les « mots ».
Un mot représente un groupe d’éléments issus de l’alphabet du langage, qui définit une unité de sens. Par exemple, la langue française possède de nombreux mots, tels que « projet », « contrôleur de gestion », « équipe », « contrôler »… En UML les mots appartiennent à deux grandes catégories :
Concepts : qui sont représentés par des rectangles ou des symboles avec un nom.
Relation entre concepts : ils sont illustrés par des lignes connectant les symboles entre eux.
La figure ci-dessous illustre un exemple de concepts :
Une phrase représente un groupe de mots issus du vocabulaire du langage, qui définit une unité de sens grammaticale contenant un sujet et une expression concernant ce sujet. La grammaire d’un langage spécifie les règles de combinaison des mots afin de former des phrases. La figure 3, représente ce concept :
Les concepts qui expriment les phrases s’appellent des classes et les relations générales s’appellent des associations. Ainsi en UML nous pouvons utiliser des phrases spécifiques impliquant des « Étudiants » des « projets » des « équipes », et les concepts sont alors appelés objets, et les relations liens.
Une classe définit un type d’objet et ses caractéristiques. Un objet est une instance d’une classe. Ici la figure ci-dessous illustre trois classes : Étudiant, Équipe, Projet informatique.
Un attribut est un élément connu par un objet et représente essentiellement une donnée. Une classe définit des attributs et un objet possède es valeurs pour ces attributs. Même si deux objets possèdent les mêmes valeurs d’attributs, chacun garde sa propre identité et est unique. On peut visualiser les attributs dans UML comme ci-dessous, ou on ajoute un deuxième compartiment pour les attributs qui sont énumérés. Chaque attribut peut contenir des valeurs, pour cela on ajoute le signe «= » à la suite de chaque attribut.
Les attributs sont des caractéristiques dites structurelles, car elles communiquent la structure de la classe.
Une action qu’un objet peut réaliser s’appelle une opération, et représente essentiellement un traitement. La manière dont l’objet réalise le traitement correspondant à une opération donnée correspond à la méthode ou implémentation de l’opération. Une classe définit des opérations et des méthodes qui s’appliquent à ses objets. Les méthodes et opérations sont à ajouter dans un autre compartiment.
En raison de limitations techniques, la typographie souhaitable du titre, « Modélisation UML : Version imprimable Modélisation UML/Version imprimable », n'a pu être restituée correctement ci-dessus.
Comme n’importe quel type de projet, un projet informatique nécessite une phase d’analyse, suivi d’une étape de conception. Dans la phase d’analyse, on cherche d’abord à bien comprendre et à décrire de façon précise les besoins des utilisateurs ou des clients. Que souhaitent-ils faire avec le logiciel ? Quelles fonctionnalités veulent-ils ? Pour quel usage ? Comment l’action devrait-elle fonctionner ? C’est ce qu’on appelle « l’analyse des besoins ». Après validation de notre compréhension du besoin, nous imaginons la solution. C’est la partie analyse de la solution. Dans la phase de conception, on apporte plus de détails à la solution et on cherche à clarifier des aspects techniques, tels que l’installation des différentes parties logicielles à installer sur du matériel.Ainsi, UML définit 9 types de diagrammes dans deux catégories de vues, les vues statiques et les vues dynamiques.
Vues statiques:
Les diagrammes de cas d’utilisation décrivent le comportement et les fonctions d’un système du point de vue de l’utilisateur
Les diagrammes de classes décrivent la structure statique, les types et les relations des ensembles d’objets
Les diagrammes d’objets décrivent les objets d ’un système et leurs relations
Les diagrammes de composants décrivent les composants physiques et l’architecture interne d’un logiciel
Les diagrammes de déploiement décrivent la répartition des programmes exécutables sur les différents matériels
Vues dynamiques :
Les diagrammes de collaboration décrivent les messages entre objets (liens et interactions)
Les diagrammes d’états-transitions décrivent les différents états d’un objet
Les diagrammes d’activités décrivent les comportements d’une opération (en termes d’actions)
Les diagrammes de séquence décrivent de manière temporelle les interactions entre objets et acteur
En raison de limitations techniques, la typographie souhaitable du titre, « Modélisation UML : Version imprimable Modélisation UML/Version imprimable », n'a pu être restituée correctement ci-dessus.
Notre système (ou logiciel) est une boîte qui contient d’autres boîtes, les packages . Chaque package est donc une boîte qu’il faudra ouvrir pour en découvrir le contenu. Le contenu d’un package est illustré par différents diagrammes. Un de ces diagrammes représente les cas d’utilisation, c’est-à-dire les fonctionnalités ou lots d’actions que devront réaliser nos acteurs. Le diagramme de cas d'utilisation représente les fonctionnalités nécessaires aux utilisateurs. On peut faire un diagramme de cas d'utilisation pour le logiciel entier ou pour chaque package.
Ci-dessous un exemple de diagramme de cas d'utilisation pour un package (gestion des stocks).
Le diagramme des cas d'utilisation illustre ce que le logiciel doit permettre de faire.
Exemple: Comment réaliser le diagramme de cas d'utilisation?
Nous allons prendre l'exemple du package "gestion des achats". Il faut donc identifier toutes les fonctionnalités dont les différents acteurs concernés par le package auront besoin. Dans notre projet de réalisation d'une boutique en ligne, nous indiquons qu'un client devra pouvoir utiliser le site pour consulter le catalogue des produits. Nous pouvons en déduire que le catalogue des produits est un cas d'utilisation.
Le cas d’utilisation « Consulter le catalogue » de l’acteur principal « Client » est représenté sous forme d’ellipse.
On le schématise ainsi:
Un cas d’utilisation n’est pas forcément lié à un seul acteur. Nous pouvons indiquer qu’un commercial devra également pouvoir consulter le catalogue des produits (par exemple, pour montrer des caractéristiques d’un produit lors d’une visite chez son client) en reliant cet acteur au même cas d’utilisation.
En observant la demande de notre client nous pouvons noter les besoins suivants:
Le diagramme ci-dessous nous donne une version de diagramme de cas d’utilisation un peu plus complète.
Il nous manque encore un élément, le cas d’utilisation « Enregistrer un achat ».
Un logiciel à développer est considéré comme un système, vu au départ comme une boîte noire.
Le système est utilisé par des acteurs principaux, et parfois, il peut être lié à des acteurs secondaires. Les acteurs secondaires échangent des informations avec le système, mais ne déclenchent aucune des fonctionnalités.
Un système peut être composé de plusieurs packages. Chacun des packages contient une famille de fonctionnalités nécessaires aux acteurs.
Les fonctionnalités utiles aux acteurs sont appelées des cas d’utilisation. Un diagramme de cas d’utilisation permet d’illustrer QUI devrait pouvoir faire QUOI, grâce au système. Il en existe un par package.
Il existe des cas plus complexes que ce que nous venons de voir. Il s’agit dans ce cas souvent de cas d’utilisation dont le scénario renvoie vers d’autre cas d’utilisation: les cas d’utilisation internes.
Les cas d’utilisation que nous avons découvert dans la partie 1 sont directement liés à un acteur et sont appelés des « cas d’utilisation principales ». On y décrit ce qu’un utilisateur doit pouvoir faire grâce au logiciel à développer. On parle donc des fonctionnalités principales du logiciel à développer.
Chacun de ces cas d’utilisation nécessitera un certain nombre d’actions. Il arrive que l’on doive regrouper certaines actions dans un ou plusieurs cas d’utilisation complémentaires qui ne sont pas directement liés à un acteur. On parle alors d’un cas d’utilisation interne.
Pour trouver les cas d’utilisation internes, nous devrons réfléchir à chaque cas d’utilisation que nous avons déjà indiqué dans notre diagramme.
Les cas d’utilisation internes seront indiqués dans le diagramme de cas d’utilisation. Leur particularité réside dans le fait qu’ils ne seront pas directement liés aux acteurs, mais aux cas d’utilisation qui en ont besoin.
Dans la partie précédente, nous nous étions arrêté au diagramme de cas d’utilisation du package « Gestion des achats » qui mettait en évidence les acteurs et les cas d’utilisation principaux (dernier schéma de la partie 1).
On constate très vite qu’au niveau des acteurs « Client » et « Commercial », les cas d’utilisation « Consulter catalogue produits » et « Enregistrer un achat » s’entrecroisent.
Le diagramme reste lisible puisqu’il n’y a pas trop de liens qui se croisent mais il faut éviter, car cela devient vite affreux lorsqu’il y a beaucoup de cas d’utilisation.
Pour cela, nous introduirons la notion de spécialisation au niveau de certains acteurs.
Si plusieurs acteurs ont besoin d’un ou de plusieurs cas d’utilisation communs et qu’ils ont également besoin de cas d’utilisation spécifiques.
On utilise alors :
un acteur générique qui est lié aux cas d’utilisations communs ;
des acteurs spécialisés qui sont liés à des cas d’utilisation spécifiques.
On indique qu’un acteur est la spécialisation d’un autre en dessinant une flèche vers l’acteur principal.
Dans notre étude de cas, on constate que deux acteurs ont les mêmes cas d’utilisation. Pour indiquer cela, nous créons un nouvel acteur générique appelé « Acheteur », dont « Client » et « Commercial » sont des spécialisations. Nous pouvons alors relier l’acteur générique aux cas d’utilisation « Consulter catalogue produits » et « Enregistrer un achat »
La spécialisation est également possible au niveau des cas d’utilisation, voyons cela dans l'exemple ci-dessous:
Intéressons-nous cette fois-ci au cas d’utilisation « Enregistrer un achat ». L’objectif ici est de détailler les actions au sein de cette fonctionnalité.
Reprenons l'exemple du diagramme de le "Gestion d'achats", on réalise qu’un acheteur qui enregistre un achat en ligne peut constituer un panier. Celle-ci nécessitera plusieurs étapes :
- une recherche de produits selon une catégorie;
- la consultation de la fiche produit ;
- la validation d’un produit à ajouter au panier ;
etc.
Le schéma ci-dessous illustre notre exemple:
Nous avons
introduit un nouveau cas d’utilisation interne , appelé « Constituer panier ». Ce cas d’utilisation sera nécessaire et lié au cas d'utilisation principal « Enregistrer un achat » par une flèche représentant la relation dite « Include ».
La relation « include » est utilisée pour indiquer que le cas d’utilisation source (départ de la flèche) contient TOUJOURS le cas d’utilisation inclus.Dans le schéma précédent, le cas d’utilisation source « Enregistrer un achat » contiendra TOUJOURS le cas d’utilisation « Constituer un panier ».
Dans la version précédente de notre diagramme, l’acteur « Système bancaire » était lié au cas d’utilisation « Enregistrer un achat ». Maintenant que ce cas d’utilisation a été complété par des cas d’utilisation internes, nous pouvons être plus précis. Nous avons donc déplacé ce lien vers le cas d’utilisation : « Enregistrement règlement ».
Nous remarquons ci-dessus une relation "extend" entre "Sélectionner un client" et "Enregistrer un achat".
En effet, une relation « extend » est utilisée pour indiquer que le cas d’utilisation source (à l’origine de la flèche) n’est pas toujours nécessaire au cas d’utilisation principal, mais qu’il peut l’être dans certaines situations. On doit alors préciser la condition qui fera que le cas d’utilisation en « extend » est nécessaire.
Dans exemple le cas d’utilisation interne « Sélectionner le client » n’étant pas une action obligatoire au cas d’utilisation principal « Enregistrer un achat », on peut dès lors parler de relation « extend ».
Dès lors qu’il y a une relation « extend », il faudra toujours définir la condition, c’est-à-dire : à quelle condition cette relation peut avoir lieu ? Pour indiquer cela, il faut ajouter une ligne « extension points » et définir la condition « EXT ».
Le cas d’utilisation « Sélectionner un client » est une relation « extend » du cas d’utilisation principal « Enregistrer un achat ». Cette action n’est possible qu’à condition que l’acteur soit le « Commercial », et non pas le « Client ».
Les cas d’utilisation principaux sont complétés par des cas d’utilisation internes, qui sont des précisions d’autres cas d’utilisation.
Les cas d’utilisation internes sont reliés au cas initial par des relations de type « include » ou « extend ».
Une relation « include » permet d’indiquer qu’un cas d’utilisation a toujours besoin du cas d’utilisation lié.
Une relation « extend » c’est une relation qui est soumise à une condition.On doit toujours expliciter la condition qui doit être rencontrée pour que le cas d’utilisation lié soit utile.
En raison de limitations techniques, la typographie souhaitable du titre, « Modélisation UML : Version imprimable Modélisation UML/Version imprimable », n'a pu être restituée correctement ci-dessus.
Définition : Classification qui représente un ensemble d’objets partageant les mêmes spécifications de propriétés, de contraintes et de sémantique.
Le diagramme de classe est un diagramme faisant partie des diagrammes structurels et est un des diagrammes d’UML le plus utilisé du fait de sa notation syntaxique riche. Il représente la structure d’une application orientée objet en montrant les classes et les relations qui s’établissent entre elles.
Les classes sont schématisées par une boite rectangulaire à trois sections, la première avec le nom de la classe et ses propriétés, la seconde avec les attributs et la troisième avec les opérations. Une classe peut aussi être représentée seulement en un seul rectangle. Voici le schéma d’un objet de la classe Étudiant :
ceci est un diagramme d'objet, pas un diagramme de classe. Elle représente l'objet Ikra de la classe Étudiant
Définition Association : Relation qui peut s’établir entre instances de classes.
Exemple de relations entre classes :
Comme nous pouvons le constater l’association est composée des informations suivantes :
Le nom de l’association apporte une précision sémantique et facilite la lecture du diagramme : « une course est réalisée par un chauffeur ».
Le rôle apporte également une précision sémantique à la lecture du diagramme et permet d’identifier la fonction des classes participantes à l’association. On lit ainsi « un chauffeur indépendant est propriétaire d’au moins un taxi », ce qui est plus précis que : « un chauffeur indépendant possède au moins un véhicule ».
La multiplicité est implicitement une règle de gestion qui permet de préciser le nombre d’instances impliquées dans la relation (attention, contrairement aux notations d’autres méthodologies, le positionnement des multiplicités est inversé). Notations possibles des multiplicités :
Multiplicité
Signification
1
Exactement 1
5
Exactement 5
*
Plusieurs incluant la possibilité d’aucun
0..*
Idem
0..1
Au plus un, ce qui signifie également optionnellement
1..*
Au moins un
1..5
Entre un et cinq
L’agrégation et la composition sont deux précisions supplémentaires de l’association qui introduisent la notion de « est composé de ». Cette notion est purement sémantique dans le cas de l’agrégation et introduit une règle de gestion dans le cas de la composition.
Le diagramme de classe en analyse permet de définir toute la structure conceptuelle d’une application et d’en faire ressortir toutes les contraintes ou règles de gestion. Le travail d’analyse réalisé sur un diagramme de classe est important car il apporte énormément de sens dans la définition des concepts utilisés par l’application et notamment en formalisant précisément les relations entre classes. L’analyste se concentre en conséquence sur les impacts sémantiques de ce qu’il est en train de décrire et doit maitriser les notations d’UML.
La conception doit compléter le modèle d’analyse de façon à préciser les techniques qui doivent être employées pour le codage. Le diagramme de classe représente alors directement la structure du code qui doit être réalisé ; c’est pourquoi ce diagramme prend une place prépondérante dans la phase de conception.
Le conception des attributs et des opérations est une première tâche de conception, qui consiste à définir précisément les visibilités, les types, les cardinalités, les paramètres, les propriétés et les contraintes.
Le diagramme de classe est le plus à même de formaliser la structure objet des développements logiciels et, par nature, de centraliser l’information collectée sur le modèle pendant toutes les phases d’analyse et de conception. La modélisation autour du diagramme de classe est donc incontournable tant dans le domaine du développement spécifique que dans les travaux d’ingénierie système.
En raison de limitations techniques, la typographie souhaitable du titre, « Modélisation UML : Version imprimable Modélisation UML/Version imprimable », n'a pu être restituée correctement ci-dessus.
Un diagramme de collaboration est un outil essentiel dans la conception d'un projet en équipe. En effet ce diagramme permet de représenter simplement les échanges entre les objets, sans surcharge avec des informations sur leurs contenus ou chronologiques.
En raison de limitations techniques, la typographie souhaitable du titre, « Modélisation UML : Version imprimable Modélisation UML/Version imprimable », n'a pu être restituée correctement ci-dessus.
Le diagramme d'activités
Les diagrammes d'activités permettent de déterminer des traitements a priori séquentiels. Ils offrent un pouvoir d'expression très proche des langages de programmation objet: spécification des actions de base (déclaration de variables, affectation etc.), structures de contrôle (conditionnelles, boucles), ainsi que les instructions particulières à la programmation orientée objet (appels d'opérations, exceptions etc.). Ils sont donc bien adaptés à la spécification détaillée des traitements en phase de réalisation. On peut également utiliser de façon plus informelle pour décrire des enchaînements d'actions de haut niveau, en particulier pour la description détaillée en cas d'utilisation.
Les diagrammes d'activités privilégient les traitements. Ils sont adaptés à la modélisation du cheminement de flots de contrôle (toutes les instructions, branches, chemins...) et de flots de données (toutes les définitions de variable, les utilisations...). Ils représentent graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation.
Les diagrammes d'activités ont certaines similitudes avec les diagrammes d'états-transitions dans leur présentation mais ils sont différents dans leurs interprétations. En effet, les diagrammes d'état-transitions sont orientés vers des systèmes réactifs, mais ils ne doivent pas présenter une vision unifiée d'un traitement avec plusieurs classeurs et ils peuvent être complétés par des diagrammes de séquence par exemple. A contrario, les diagrammes d'activité ne sont pas rattachés à un classeur particulier. Ils peuvent être attachés à n'importe quel élément de modélisation afin de visualiser, spécifier, construire ou documenter le comportement de cet élément.
Ensuite, la principale différence entre les diagrammes d'interaction et les diagrammes d'activités est que les premiers privilégient le flot de contrôle d'un objet à l'autre, contrairement aux seconds qui mettent en avant le flot de contrôle d'une activité à l'autre.
Dans la phase de conception, les diagrammes d'activités sont particulièrement adaptés à la description des cas d'utilisation car ils viennent illustrer et consolider leur description textuelle. De plus, leur représentation sous la forme d'organigrammes les rend facilement compréhensible et accessible les diagrammes d'états-transitions. Par exemple, un diagramme d'activité se concentre sur les activités telles que les voient les acteurs qui collaborent avec le système dans le cadre d'un processus métier. La modélisation du flot d'objet est souvent importante dans ce type de modèle qui peut être rapproché de la modélisation bien connue de workflow.
Cette page Modélisation UML : Le diagramme d'activité est largement inspirée du livre UML2 de l'apprentissage à la pratique[1] de Laurent Audibert.
Les modèles UML sont utilisés pour expliquer comment fonctionne un système de manière abstraite. En même temps, UML 2 ne présente pas une simple description informelle en présentant un système à un niveau de détails qui permette son exécution. Le but est de donner une vision se rapprochant des langages de programmation impératifs comme C++ ou Java, UML 2 a pour objectif de se détacher des langages de programmation classiques. UML doit posséder des mécanismes présentant la précision d'un langage de programmation au niveau de la description de l'effet des actions. Étant donné que UML est universel, c’est à la charge des outils de définir la syntaxe d'un langage de programmation existant. Mais UML propose une définition des instructions de base qui représentent le langage orienté objet: c’est la description des actions UML.
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. Ce 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.
Par exemple, une action peut être:
- la création d'un nouvel objet ou lien
- l'émission d'un signal
- une affectation de valeur à des attributs
- la réception d'un signal
- un calcul arithmétique simple etc.
Désormais, nous allons présenter les différents types d'actions les plus courants.
L'action Call Operation correspond à l'invocation d'une opération sur un objet sur un classeur de manière synchrone (qui a lieu en même temps) ou asynchrone. Lorsque l'action est exécutée, les paramètres sont transmis à l’objet cible. Si l'appel est asynchrone, l'action est terminée et les éventuelles valeurs de retour seront ignorées. Lorsque l'appel est synchrone, l'appelant est bloqué pendant l'exécution de l'opération et les valeurs de retour, s'il y en a, pourront être réceptionnées.
C'est une variante de l'action Call Operation car elle invoque directement une activité plutôt qu'une opération. Elle correspond à l'invocation d'un comportement spécifié à l'aide d'un diagramme UML, par exemple un diagramme d'activités ou d'interactions. Cela offre la possibilité, dans les diagrammes d'activités, de directement référer à d'autres types de diagrammes. On peut donc utiliser un diagramme de séquence par exemple (imbriqué dans un diagramme d'activités) pour illustrer le comportement d'une activité, et inversement.
Cette action crée un message et le transmet à un objet cible, où elle peut déclencher un comportement. Elle correspond à des appels asynchrones correspondant à des envois de messages asynchrones: l'appelant poursuit son exécution sans attendre que l'entité cible ait bien reçu le message. Ce type d'appel est bien adapté à la modélisation de systèmes matériels (communication sur un bus, interruptions d'entrée/sortie avec send signal) ou de protocoles de communication particuliers.
L'exécution de cette action interrompt l'exécution en cours jusqu'à la réception du type d'événement spécifié, qui est généralement un signal. Cette action est utilisée pour la réception de signaux asynchrones.
Action accepter appel (Accept Call) et action répondre (Reply)
L'action Appeler appel est une variante de Accept Event pour les appels synchrones. L'action Répondre permet de transmettre un message en réponse à la réception d'une action de type Accept Call. Les actions accept call et reply peuvent être utilisées du côté récepteur pour décomposer la réception de l'appel. Reply correspond précisément au return des langages de programmation.
Cette action permet de lever explicitement une exception.
Une exception est un élément important de l'approche orientée objet; elle permet de traiter des cas particuliers.
Pour faciliter la compréhension, nous avons représentés certaines actions évoquées précédemment, sous la forme d'un schéma:
Une représentation spécifique des actions de communication
Premièrement, on détecte l'arrivée du train; cette action représente l'action "accept event" c'est-à-dire qu'on reçoit le signal de l'arrivée du train. Deuxièmement, "faire clignoter les feux" est une action "send signal", cela veut dire qu'on envoie un signal qui est transmis à un objet cible sans attendre que ce dernier ait bien reçu le signal. Ensuite, l'action "time event" est un événement temporel déclenché après l'écoulement d'une certaine durée. Enfin, "abaisser la barrière" est une action "send signal", un message est envoyé et transmis à la cible.
On distingue graphiquement les actions associés à une communication: send signal, accept event et accept time event. Cela permet de mieux mettre en valeur les échanges entre les diagrammes de la spécification.
Une activité définit un comportement décrit par une série organisée 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 le traitement soit terminé. Une activité est un comportement et peut comporter des paramètres en entrée ou en sortie, ainsi que des variables locales au même titre qu'une opération.
Une activité peut regrouper des nœuds et des arcs, c’est ce qu'on peut appeler "groupe d'activités". Les nœuds et les arcs peuvent appartenir à plusieurs groupes. Le groupe d'activités représente un système qui est générique regroupant des activités pouvant être utilisé de façon variée. Un diagramme d'activité est lui-même un groupe d'activités. Voici ci-dessous un exemple de diagramme d'activités qui représente le fonctionnement d'une borne bancaire:
Schéma d'un groupe d'activités représentant le fonctionnement d'une borne bancaire
Cet exemple illustre différentes représentations des actions. Après avoir saisi le code, deux activités sont déclenchées: on choisit l'opération souhaitée si le code est valide ou la carte est restituée si on annule l'opération. Après avoir choisi l'opération, on trouve deux alternatives: choisir un montant qu'on dépose (dépôt) ou retire (retrait). Dans les deux cas, nous choisissons le compte par la suite. Si nous avons choisi de déposer des billets, nous devons insérer une enveloppe ce qui nous donne droit à la restitution de notre carte à la fin de l'opération. Si nous avons pris le choix d'effectuer un retrait de billets, nous avons le droit à deux options: afficher une publicité ou demander une autorisation de retrait. Enfin, la note portant le mot-clé "decisionInput" spécifie un critère de décision parmi plusieurs arcs d'activité, dont chacun doit satisfaire la variable "autorisation accordée" à "Non autorisé" ou "Autorisé" avant que la transition associée ne puisse être déclenchée (la garde).
Après avoir expliqué le diagramme d'activités et son fonctionnement, nous abordons majoritairement des nœuds qui sont essentiels dans un diagramme d'activités. Elle permet d'évoquer davantage en détail le contenu d'un diagramme d'activités.
Un nœud d'activité est un type d'élément abstrait qui permet de représenter les étapes le long du flot d'activité. On observe trois types de nœuds d'activité:
• les nœuds d'exécution (executable node)
• les nœuds d'objet (object node)
• les nœuds de contrôle (control nodes)
Un nœud exécutable est un nœud d'activité qui donne lieu à une exécution d'actions.
On trouve également le nœud d'action qui est un nœud d'activité exécutable qui constitue l'unité fondamentale de fonctionnalité exécutable dans une activité. Lorsqu'une action est exécutée, une transformation ou un calcul quelconque sont mis en place dans le système modélisé. En général, les actions sont liées à des opérations qui sont directement appelées. De plus, un nœud d'action doit avoir au moins un arc entrant.
Afin de comprendre au mieux le système des nœuds d'action, revenons sur le graphique précédent: Image:Schéma d'un groupe d'activités représentant le fonctionnement d'une borne bancaire.PNG. Un noeud d'activité est représenté par un rectangle aux coins arrondis qui contient sa description textuelle. Cette dernière peut aller d'un simple nom à une suite d'actions réalisées par l'activité. UML n'a pas de règle spécifique sur cette description textuelle, on peut utiliser un langage de programmation ou du pseudo-code. On peut le constater avec la première représentation graphique de cette leçon: Image:Actions de communication.PNG
Un nœud de contrôle est un nœud d'activité abstrait utilisé pour coordonner les flots entre les nœuds d'une activité. Il existe plusieurs types de nœuds de contrôle:
• nœud initial (initial node)
• nœud de fin d'activité(final node)
• nœud de fin de flot (flow final)
• nœud de décision (decision node)
• nœud de fusion (merge node)
• nœud de bifurcation (fork node)
• nœud d'union (join node)
Nous allons décrire ces différents nœuds de contrôle.
C'est un nœud de contrôle à partir duquel le flot débute lorsque l'activité enveloppante est invoquée. Une activité peut avoir plusieurs nœuds initiaux et un nœud a un arc sortant et pas d'arc entrant. Il est représenté par un petit cercle plein. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)
Un nœud final est un nœud de contrôle possédant un ou plusieurs arcs entrants et aucun arc sortant. Il y a deux type de nœuds finaux: nœud de fin d'activité et nœud de fin de flot.
Lorsque l'un des arcs d'un nœud de fin d'activité est activé, l'exécution de l'activité enveloppante s'arrête et tous les nœuds ou flots actifs appartenant de cette activité est abandonné. Si l'activité a été appelé par un appel synchrone, un message Reply qui contient les valeurs sortantes est transféré en retour à l'appelant. Un nœud de fin d'activité est représenté par un cercle contenant un petit cercle plein. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)
Un flot est terminé lorsqu'un flot d'exécution atteint un nœud de fin de flot. Mais cette fin de flot n'a pas d'incidence sur les autres flots actifs de l'activité enveloppante. Un nœud de fin de flot est représenté par un cercle vide barré d'une croix.
C'est un nœud de contrôle qui permet de faire un choix entre plusieurs flots sortants. Il possède un arc entrant et plusieurs arcs sortants, accompagnés de conditions de garde pour conditionner le choix. Quand le nœud de décision est atteint et qu'aucun arc en aval n'est franchissable (ce qui veut dire qu'aucune condition est vraie), cela signifie que le modèle est mal formé. C'est pour cela que l’utilisation d'une garde (else) est recommandée après un nœud de décision, car elle garantit un modèle bien formé. En effet, la condition de garde est validée si et seulement si toutes les autres gardes des transitions ayant la même source sont fausses. Lorsque plusieurs arcs sont franchissables (c'est-à-dire que plusieurs conditions de garde sont vraies), l'un d'entre eux est retenu et ce choix est non déterministe. Un nœud de décision est représenté par un losange. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)
Un nœud de fusion est un nœud de contrôle rassemblant plusieurs flots alternatifs entrants en un seul flot sortant. On ne l'utilise pas pour synchroniser des flots concurrents mais pour accepter un flot parmi plusieurs. Un nœud de fusion est représenté par un losange comme le nœud de décision. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)
Graphiquement, il est possible de fusionner un nœud de fusion et un nœud de décision, c'est-à-dire de posséder plusieurs arcs entrants et sortants. Il est aussi possible de fusionner un nœud de décision ou de fusion avec un autre nœud. Mais pour mieux mettre en évidence un branchement conditionnel, il est préférable d’utiliser un nœud de décision.
C'est un nœud de contrôle qui synchronise des flots multiples. Il possède plusieurs arcs entrants et un seul arc sortant. Lorsque tous les arcs entrants sont activés, l'arc sortant l'est aussi également. Un nœud d'union est aussi représenté par un trait plein épais. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)
Enfin il est possible de fusionner un nœud de bifurcation et un nœud d'union, possédant donc plusieurs arcs entrants et sortants.
Après vous avoir présentés les différents nœuds que peut avoir un diagramme d'activité, voici un exemple de diagramme d'activité qui illustre ces différents nœuds de contrôle. Ce diagramme décrit le fonctionnement d'une prise de commande.
Précédemment, nous avons expliqué la modélisation des flots de contrôle. Dans cette partie, nous allons aborder les flots de données, essentiels pour les traitements. Un nœud d'objet permet de définir un flot de données dans un diagramme d'activités.
Pour exprimer les valeurs passées en argument à une activité ainsi que les valeurs de retour, il faut utiliser des nœuds d'objet appelés pins d'entrée ou de sortie. L'activité ne peut commencer uniquement lorsqu'une valeur est affectée à chacun de ses pins de sortie. Un pin est représenté par un petit carré attaché à la bordure d'une activité.
Pins d'entrée et de sortie
Il peut contenir des flèches indiquant sa direction (entrée ou sortie) si l'activité ne permet pas de le déterminer de manière univoque.
Un pin de valeur est un pin d'entrée qui fournit une valeur à une action sans que cette valeur ne provienne d'un arc de flot d'objet. Il est toujours associé à une valeur spécifique. Graphiquement, il est représenté de la même manière qu'un pin d'entrée avec la valeur associée écrite à proximité.
Il permet de passer des données d'une activité à une autre. Un arc reliant un pin de sortie à un pin d'entrée est un flot d'objet. Dans cette situation, le type de pin récepteur doit être identique ou parent du type du pin émetteur. Nous pouvons le constater sur le schéma suivant (en haut de la figure):
Pin de valeur
Il y a une autre représentation possible d'un flot d'objet, axée sur les données, car elle fait intervenir un nœud d'objet détaché d'une activité spécifique (cf. le bas de la figure du schéma ci-dessus). Ce nœud est représenté par un rectangle dans lequel est mentionné le type de l’objet qui est souligné dans ce cas. Des arcs viennent relier ce nœud d'objet à des activités sources et cibles. On peut également mettre en crochet le nom d'un état ou liste d'états et également en accolades des contraintes.
Le flot d'objet mentionne deux comportements:
- "transformation" qui indique une interprétation particulière de la donnée véhiculée par le flot;
- "selection" présente l’ordre dans lequel les objets sont choisis dans le nœud pour le quitter.
C'est un nœud d'objet qui accepte les entrées de plusieurs nœuds d'objet ou produit des sorties vers plusieurs nœuds d'objet. Les flots en provenance d'un nœud tampon central ne sont donc pas directement connectés à des actions. Ce nœud modélise un tampon traditionnel qui peut contenir des valeurs venant de diverses sources et livrer des valeurs vers différentes destinations. Graphiquement, un nœud tampon central est représenté comme un nœud d'objet détaché (en bas du schéma suivant:Image:Pin de valeur.PNG) stéréotypé "centralBuffer". Voici ci-dessous un exemple de nœud tampon central pour centraliser toutes les commandes par différents procédés, avant qu’elles ne soient traitées:
Nœud tampon central
Il existe également un autre type de nœud tampon central appelé "Nœud de stockage données (data store node). Quand un flux sortant sélectionne une information, l'information est reproduite et elle ne se supprime pas du nœud de stockage des données comme ce qui se passe dans un nœud tampon central. Lorsque un flux entrant sélectionne une donnée déjà stockée , cette donnée est supprimée par une nouvelle. Ce nœud est représenté comme un nœud d'objet détaché avec écrit "datastore". Voici ci-dessous un exemple de nœud de stockage de donnée:
Noeud de stockage des données
Après avoir recruté le personnel, il est stocké dans le noeud de stockage des données de façon permanente, appelé dans ce cas "Base de données du Personnel". Ceux qui n'ont pas été affectés sont disponibles pour être affectés par l'activité "Affecter personnel". L'étiquette "selection: personnel.affectation=null" permet de sélectionner ceux qui n'ont pas été affectés.
Un nœud d'activité structurée est un espace de nom et une spécialisation d'un groupe d'activités et d'un nœud d'activité exécutable. C'est une partie structurée d'une activité qui ne présente aucun autre nœud structuré. Dans le même nœud d'activité structurée, les transitions doivent avoir leurs nœuds source et cible. Les arcs et les nœuds doivent être présents dans un seul et unique nœud d'activité structuré. De plus, c’est uniquement lorsque toutes les données d'entrée sont disponibles que l'activité structurée peut s'activer. Enfin le flux a la possibilité de quitter l'activité quand toutes les actions de l'activité structurée se termine.
Afin de faciliter la compréhension, voici un schéma représentant un nœud d'activité structurée:
Noeud d'activité structurée
Un nœud structuré est identifié par la dénomination "strutured" et par un nom qui décrit le comportement modélisé dans l'activité structurée. Comme vous pouvez le constater sur le schéma ci-dessus, un nœud d'activité structurée est représenté de la façon suivante: le contour du noeud est en pointillé et une ligne continu sépare le nœud structuré de l'activité structurée.
Les nœuds d'activité structurée ont été mis en place par l'UML 2.
On note trois types de nœud d'activité structurée: le nœud conditionnel, le nœud de boucle et le nœud séquentiel. Comme évoqué précédemment, ce sont des nœud d'activité mis en place à partir l'UML 2 ce qui signifie que leurs définitions ne sont pas précises au niveau de leur syntaxe.
Avant de présenter une structure de contrôle, il est important de définir les différents types de nœud d'activité:
- Nœud de séquence: c’est un noeud d'activité structurée intitulé "séquence" qui garantit l'exécution d'un certain nombre d'activités réalisé en séquence dans un ordre établi en amont
- Nœud conditionnel: c’est un noeud d'activité appelé "conditional" qui représente le choix exclusif d'une activité parmi un certain nombre d'activités alternatives
- Nœud de boucle: c’est un noeud d'activité appelé "loop" qui représente une structure de contrôle en boucle présentant une partie d'initialisation, une partie de test et une partie correspondant au corps de la boucle
Voici ci-dessous une représentation graphique des différentes structures de contrôle:
Les partitions sont aussi des éléments essentiels dans un diagramme d'activités. En effet, elles sont appelées couloirs ou lignes d'eau. Elles ont pour but d'organiser les noeuds d'activités disposés dans un diagramme d'activités par le biais de regroupements. Ce sont des unités d'organisation du modèle. Ces partitions sont utiles lorsqu'on doit désigner la classe responsable qui rassemble un ensemble de tâches par exemple. La classe en question est donc responsable du comportement des noeuds à l'intérieur de la partition précédemment évoquée. Graphiquement, les partitions sont représentées par des lignes continues. Elles peuvent prendre la forme d'un tableau. De plus, les noeuds d'activités doivent appartenir à une seule et unique partition et les transitions peuvent passer à travers les frontières des partitions.
Afin de faciliter la compréhension, voici ci-dessous un ensemble de noeuds d'objet et de partitions dans un diagramme d'activités:
Partitions
Pour savoir si vous avez bien compris ce qu'est un diagramme d'activités, exercez-vous sur l'exercice de la mousse au chocolat en vous amusant !
Vous avez la permission de copier, distribuer et/ou modifier ce document selon les termes de la licence de documentation libre GNU, version 1.2 ou plus récente publiée par la Free Software Foundation ; sans sections inaltérables, sans texte de première page de couverture et sans texte de dernière page de couverture.
↑UML2 de l'apprentissage à la pratique, Laurent Audibert, Ellipses Marketing, ISBN-10: 2340002044, ISBN-13: 978-2340002043
GFDL