Qu’est-ce que le UML ?

Qu’est-ce que le UML ?

Le langage de modélisation unifié est une notation graphique standard ouverte pour le développement de systèmes proposée par le groupe de gestion des objets. La notation s’appuie sur les travaux de Booch, Rumbaugh et Jacobson. Le UML est un langage de modélisation pour exprimer et concevoir des documents, logiciels particulièrement utile pour la conception orientée objet. Ce langage peut être utilisé depuis la conception initiale générale jusqu’à la conception détaillée très spécifique tout au long du cycle de vie du développement logiciel. La définition du UML est la suivante :

• Langage de modélisation unifié ( UML ) est un langage graphique pour la modélisation et le développement de systèmes logiciels. Les diagrammes UML deviennent un produit de travail commun que les développeurs utilisent pour discuter de toutes les phases du développement logiciel, depuis l’analyse des besoins, la conception et l’implémentation. L’objectif ici est de modéliser le système logiciel avant de le construire.
• Citation : « Le langage de modélisation unifié (UML) est une famille de notations graphiques, soutenue par un seul méta-modèle, qui aident à décrire et à concevoir des systèmes logiciels, en particulier les systèmes logiciels construits selon le style orienté objet (OO). » [Martin Fowler – UML Distillé] p. 1.

 Pourquoi le UML ?

À mesure que les architectures logicielles grandissent en taille et en complexité, la nécessité de modèles logiciels augmente également. Le UML est le langage de modélisation dominant dans l’industrie logicielle. Il est actuellement une norme de fait adoptée par le groupe de gestion des objets, le plus grand consortium logiciel au monde. Il est difficile de trouver un projet logiciel avec plus de 10 développeurs qui n’utilise pas le UML d’une manière ou d’une autre pour spécifier son architecture.

Voici quelques autres faits concernant l’utilisation du UML dans notre processus de développement logiciel :

• Le logiciel devient de plus en plus complexe : une version assez ancienne de Windows XP contient plus de 40 millions de lignes de code.
• Un seul programmeur ne peut pas gérer l’ensemble de ce volume de code.
• Le code n’est pas facilement compréhensible par les développeurs qui ne l’ont pas écrit.
• Nous avons besoin de représentations plus simples pour les systèmes complexes : la modélisation est un moyen de gérer la complexité.

Qu’est-ce qu’un modèle ?

• Un modèle est une abstraction de la chose réelle, en omettant les détails.
• « L’ensemble de tous les éléments qui décrivent votre système, y compris leurs connexions mutuelles, constituent votre modèle. » (Russ et Hamilton 12).

Lorsque nous utilisons le UML pour créer des modèles d’un système en cours de développement avant de coder le logiciel, ils représentent le problème de manière simplifiée. Ils fournissent une structure pour la résolution des problèmes. Ils aident à comprendre comment aborder le problème en cours. Ils permettent également d’expérimenter plusieurs solutions. Étant donné que les modèles sont créés avant le développement réel du système, nous pouvons comprendre différentes possibilités, problèmes, options, etc. Cela conduit également à une réduction des coûts de développement. Étant donné que le temps ne sera pas perdu en essais et erreurs, le produit sera prêt plus rapidement. Les modèles aident également à gérer la complexité du problème, ce qui facilite la planification du développement, l’allocation des ressources telles que les machines, les programmeurs, les testeurs.

Ce que le UML N’EST PAS ?

• Le UML n’est pas une notation, mais un langage.
• Le UML n’appartient à personne. Il est ouvert à l’utilisation par quiconque le souhaite. Il n’est pas propriétaire.
• Le UML n’est ni un processus ni une méthode.
• Le UML encourage l’utilisation des techniques orientées objet et des cycles de vie de développement logiciel itératifs.
• Le UML n’est pas difficile. Il est vaste, mais il n’est pas nécessaire de le connaître entièrement. De plus, il n’est pas nécessaire d’utiliser ou de comprendre chaque petit détail.
• Le UML n’est pas chronophage. S’il est utilisé correctement, l’utilisation du UML réduit les coûts de développement. En même temps, il offre l’avantage d’une compréhension et d’une communication faciles, une productivité accrue et une meilleure qualité.
• Le UML n’est pas limité. Il est suffisamment souple pour permettre de nouveaux vocabulaires (concepts, mots et termes), des propriétés (informations supplémentaires sur les mots) et des sémantiques (règles du langage) nécessaires à un domaine spécifique.

Objectif du UML

• Un langage de modélisation visuel et non un langage de programmation visuel. Bien que certains outils de modélisation disposent de générateurs de code et que certains peuvent inverser les modèles à partir du code.
• Il est destiné à créer des diagrammes qui peuvent soutenir le processus de développement logiciel, toutefois, le UML n’est PAS un processus ou une méthode de développement logiciel. Par conséquent, le UML est indépendant du processus.
• Un langage standard pour la création de plans de logiciels.
• Un outil de communication.
• Un langage pour documenter les exigences, l’architecture, les tests, la planification du projet, etc.
• Il est destiné aux systèmes logiciels, mais peut modéliser d’autres systèmes.
• Il est destiné à soutenir le processus de développement orienté objet.
• Il peut capturer à la fois les structures statiques et le comportement dynamique d’un système.
• Les diagrammes UML peuvent aider les parties prenantes à comprendre, discuter et s’entendre sur les exigences.
• Les diagrammes UML peuvent aider à abstraire des processus complexes à un niveau plus facile à comprendre.
• Les diagrammes UML aident à faciliter la résolution de problèmes.

Qu’est-ce qu’un langage de modélisation fournit ?

• Éléments de modèle: Concepts et sémantiques
• Notation: Représentation visuelle des éléments de modèle
• Lignes directrices: Astuces et suggestions pour utiliser les éléments dans la notation

Brève histoire

Dans les années 80, lorsque nous avons commencé à modéliser, il existait de nombreuses méthodologies différentes. Et chaque méthodologie avait sa propre notation. Le problème était que si différentes personnes utilisaient des notations différentes, à un moment donné quelqu’un devait effectuer une traduction. Souvent, un symbole signifiait une chose dans une notation, et quelque chose de totalement différent dans une autre notation. En 1991, tout le monde a commencé à publier des livres. Grady Booch a publié sa première édition. Ivar Jacobson a publié la sienne, et Jim Rumbaugh a publié sa méthodologie OMT. Chaque livre avait ses forces ainsi que ses faiblesses. OMT était très fort en analyse, mais plus faible en conception. La méthodologie Booch était plus forte en conception et plus faible en analyse. Et Objectory d’Ivar Jacobson était particulièrement bon en matière d’expérience utilisateur, ce que ni Booch ni OMT ne prenaient vraiment en compte à l’époque. Booch et Jacobson ont fusionné leurs deux méthodes en 1994, puis Rumbaugh s’est joint à eux en 1995. UML 1.1 a été publié en 1997 par l’OMG, intégrant les contributions d’autres, par exemple Yourden. La version UML v2.x est la version la plus récente.

Dates de publication

• 1995 – UML 0.8
• 1996 – UML 0.9 – Les Trois Amis
• 1997 – L’OMG reprend le contrôle.
• 1997 – OMG UML 1.1
• 1998 – OMG UML 1.2
• 1999 – OMG UML 1.3
• 2001 – OMG UML 1.4
• 2003 – OMG UML 1.5
• 2003 – OMG UML 2.0 – Adopté
• 2005 – OMG UML 2.0 – Version finale
• 2006 – OMG UML 2.1
• UML2.1.2(11/04/07) – Version actuelle au 27/05/08

La motivation de l’unification des méthodes par les « trois Amegos »

• Faits que les méthodes individuelles évoluent vers l’une l’autre indépendamment
• Unification de la sémantique et de la notation pour assurer la stabilité du marché de conception orientée objet
• Anticipation que l’unification améliorerait les méthodes individuelles antérieures

Partenaires UML

• Société Rational Software
• IBM
• Hewlett-Packard
• I-Logix
• ICON Computing
• Intellicorp
• MCI Systemhouse
• Microsoft
• ObjecTime
• Oracle
• Platinum Technology
• Taskon
• Texas Instruments/Sterling Software
• Unisys

Apport de notation UML pour différentes méthodes avant l’unification

UML représente l’unification des notations Booch, OMT et Objectory, ainsi que des meilleures idées provenant de plusieurs autres méthodologistes, comme indiqué dans la figure ci-dessous. En unifiant les notations utilisées par ces méthodes orientées objet, le langage de modélisation unifié fournit la base d’une norme de fait dans le domaine de l’analyse et de la conception orientées objet, fondée sur une large base d’expérience utilisateur.

Le rôle de la notation

La notation joue un rôle important dans tout modèle : elle est le ciment qui maintient le processus ensemble. La notation a trois rôles :

• Elle sert de langage pour communiquer les décisions qui ne sont pas évidentes ou qui ne peuvent pas être déduites directement à partir du code lui-même.
• Elle fournit une sémantique suffisamment riche pour capturer toutes les décisions stratégiques et tactiques importantes.
• Elle offre une forme suffisamment concrète pour permettre aux humains de raisonner et aux outils de la manipuler.

Le langage de modélisation unifié (UML) fournit une notation très robuste, qui évolue de l’analyse vers la conception. Certains éléments de la notation (par exemple, classes, associations, agrégations, héritage) sont introduits lors de l’analyse. D’autres éléments de la notation (par exemple, indicateurs d’implémentation de contenance et propriétés) sont introduits lors de la conception.

Avantages d’UML

UML peut être appliqué à des domaines diversdomaines d’application (par exemple, banque, finance, internet, aérospatiale, santé, etc.) Il peut être utilisé avec tous les principaux objets et composants méthodes de développement logiciel et pour divers plateformes d’implémentation.

• Vous savez exactement ce que vous obtenez
• Vous aurez des coûts de développement plus faibles
•  Votre logiciel se comportera comme vous l’attendez. Moins de surprises
•  Les bonnes décisions sont prises avant que vous ne receviez un code mal rédigé. Coûts globaux réduits
• Nous pouvons développer des systèmes plus efficaces en mémoire et en processeur
• Les coûts de maintenance du système seront plus faibles. Moins de réapprentissage a lieu
• Travailler avec un nouveau développeur sera plus facile.
• La communication avec les programmeurs et les sous-traitants externes sera plus efficace.

Vue UML 4 + 1

UML se compose des quatre vues suivantes du système en cours de développement (voir Fig. 3) [Eriksson & Penker, 1998 ; Kruchten, 2000] :

• Vue cas d’utilisation : montre la fonctionnalité du système telle qu’elle est perçue par les acteurs externes ; elle est décrite dans les diagrammes de cas d’utilisation et occasionnellement dans les diagrammes d’activité.
• Vue logique :montre comment cette fonctionnalité est conçue à l’intérieur du système, en termes de structure statique et de comportement dynamique du système ; elle est décrite dans les diagrammes de classes et d’objets (modèle statique) et dans les diagrammes de transition d’état, de séquence, de collaboration et d’activité (modèle dynamique)
• Vue composant : montre l’organisation des composants logiciels ; elle est décrite dans les diagrammes de composants.
• Vue déploiement : montre la configuration physique (déploiement) des nœuds de traitement en temps réel au sein des ordinateurs et des dispositifs, ainsi que des composants, processus et objets qui y résident ; elle est décrite dans les diagrammes de déploiement.
• Vue processus : montre l’aspect concurrent du système en temps réel, comme les tâches, les threads, les processus et les interactions, et traite les problèmes de communication et de synchronisation de ces threads ; elle est décrite dans les diagrammes dynamiques (diagrammes de transition d’état, de séquence, de collaboration et d’activité) et dans les diagrammes d’implémentation (diagrammes de composants et de déploiement).

Chaque système se compose du statique et du dynamique modèle. Le modèle statique est représenté dans les diagrammes de classes et d’objets. Cependant, il révèle peu concernant le comportement du système. Le comportement du système est capturé graphiquement à l’aide de scénarios (c’est-à-dire diagrammes de cas d’utilisation), diagrammes de séquence, diagrammes de transition d’état et diagrammes d’activité. Ces éléments constituent le modèle dynamique du système. Le comportement du système est le comportement global de tous les objets appartenant au système.

Si nous voulons mapper les cinq vues ci-dessus aux phases du cycle de vie itératif de la figure 3, nous pourrions dire ce qui suit :

• L’analyse orientée objet (OOA), qui développe un modèle des exigences des utilisateurs du point de vue de l’utilisateur, correspond à la vue des cas d’utilisation.
• La conception orientée objet (OOD) ajoute des détails et des décisions de conception (du point de vue du développeur) à l’analyse et correspond à la vue logique.
• Enfin, la mise en œuvre ou la programmation orientée objet (POO) correspond à la vue du processus, de déploiement et des composants.

Diagrams UML 2

UML dispose de plusieurs types de diagrammes différents qui peuvent être utilisés pour décrire un modèle sous différents points de vue. Il existe deux grandes catégories de diagrammes, qui sont ensuite divisées en sous-catégories :

• Diagrammes structuraux – Lediagrammes structurauxreprésentent l’aspect statique du système. Ces aspects statiques représentent les parties d’un diagramme qui forment la structure principale et donc stable. Ces parties statiques sont représentées par des classes, des interfaces, des objets, des composants et des nœuds.
• Diagrammes comportementaux – Tout système peut avoir deux aspects, statique et dynamique. Ainsi, 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 davantage comme les parties changeantes ou mobiles d’un système.

Diagrammes structuraux

• Diagramme de classes – diagramme de la structure statique des classes et interfaces du système et de leurs relations ou associations (y compris l’héritage, l’agrégation et l’association), incluant les opérations et attributs des classes. Les modes de présentation sont : association, héritage, dépendance. Il s’agit d’un diagramme très courant dans UML.
• Diagramme d’objets – est un diagramme de la structure statique d’un système à un moment ou une situation spécifique (instantané) illustrant une relation dans un système.
• Diagramme de composants – est un diagramme qui décrit l’organisation et les dépendances des composants au sein du système.
• Diagramme de structure composite – est un diagramme qui explore les instances en temps réel d’instances interconnectées collaborant via des liens de communication.
• Diagramme de paquetages – est un diagramme qui illustre comment un système est divisé en groupes logiques et quels types de dépendances peuvent exister entre ces groupes.
• Diagramme de déploiement – est un diagramme qui décrit comment les unités physiques distribuables (composants logiciels déployables, applications, serveurs, applications, matériel, etc.) constituent l’architecture du système distribué.

Diagrammes comportementaux

• Diagramme de cas d’utilisation – diagramme des cas d’utilisation (fonctions/logiciels/services) et du rôle des acteurs (utilisateurs – humains ou systèmes). Ce diagramme est vu du point de vue de l’utilisateur.
• Diagramme d’activité – est un diagramme de la nature dynamique d’un système en modélisant le flux de contrôle d’une activité à une autre. Représentez la manière dont un système (par exemple : objet/classe) réagit à un événement interne. (remarque : les événements externes sont décrits par un diagramme d’état). Pour la modélisation des processus métier, vous pouvez utiliser ce diagramme pour modéliser la logique d’un cas d’utilisation ou d’une règle métier.
• Diagramme d’état (aussi appelé diagramme d’état, diagramme de machine à états) – est un diagramme de la manière dont un système (par exemple : objet/classe) réagit à un événement externe. (remarque : les événements internes sont décrits par un diagramme d’activité).

Diagrammes de type d’interaction– interactions des parties organisationnelles du modèle.

• Diagramme de séquence – est un diagramme de l’interaction et du flux de messages entre objets, ainsi que de l’ordre temporel relatif des messages
• Diagramme de communication(aussi appelé diagrammes de collaboration de UML1) – est un diagramme de la manière dont les systèmes collaborent pour accomplir une tâche et des associations qui doivent exister entre les systèmes. Le diagramme de collaboration est le résultat de la prise du diagramme de séquence et de sa description d’interaction avec le diagramme de classe. En résumé, ce diagramme montre le flux de messages entre objets et les associations de base (relations) entre classes
• Diagramme de temporisation – est un diagramme qui explore les comportements d’un ou plusieurs objets au cours d’une période donnée.
• Diagramme d’aperçu d’interaction – est un diagramme de l’interaction et du contrôle de flux entre les diagrammes d’interaction (diagramme de séquence, diagramme de communication, diagramme de temporisation, diagramme d’aperçu d’interaction).

Profil UML

Le profil UML n’est pas exactement un diagramme, mais un profil destiné à décrire des extensions et des sous-ensembles de UML. Les sous-ensembles sont décrits à l’aide du langage de contrainte d’objets (OCL). Les extensions sont créées en définissant des stéréotypes, qui sont des balises pouvant décorer tout élément de modèle. Par exemple, nous pouvons marquer une classe « persistante » et utiliser cette balise pour identifier une classe dont les instances sont stockées au-delà de la durée de vie du système en cours d’exécution. Informellement – et cela est idéologiquement inexact – un profil est tout ensemble d’extensions et de sous-ensembles de UML, qu’ils soient ou non documentés à l’aide de ces mécanismes. Formellement, un profil est l’ensemble des définitions OCL et de stéréotypes qui décrivent les règles, qui dans UML 2, sont capturées dans un package.

Diagrammes associés au développement logiciel

Entre les différences des méthodologies OOAD et l’évolution des normes UML, les noms des diagrammes et leurs fonctions peuvent évoluer au fil du temps. Voici quelques exemples de diagrammes et/ou produits de travail qui peuvent ou non faire partie de UML1 ou UML2, mais qui pourraient être utilisés dans les méthodologies OOAD :

• Diagramme de contexte du système
• Diagramme d’entité-association (similaire au diagramme de classe) avec ERD conceptuel, logique et physique
• Analyse de robustesse

Conclusion

Nous avons examiné les origines et la définition de UML afin de fournir une compréhension simplifiée de ce qu’il est et de ce qu’il peut nous offrir. Nous avons également étudié comment nous pouvons tirer profit de son utilisation sur notre prochain projet de développement, et brièvement exploré les vues architecturales, les modèles et les types de diagrammes disponibles dans UML 2. UML n’est pas un processus, mais une notation visuelle standard ouverte pour le développement de systèmes logiciels intensifs. Les composants nécessaires à un projet réussi exigent trois aspects : une notation, un processus et un outil :

Notation uniquement – Vous pouvez apprendre une notation (par exemple UML), mais si vous ne savez pas comment l’utiliser (processus), vous échouerez probablement.

Processus uniquement – Vous pourriez avoir un excellent processus, mais si vous ne pouvez pas communiquer le processus (notation), vous échouerez probablement. Et enfin

Pas de support d’outil – si vous ne pouvez pas documenter efficacement les artefacts de votre travail (outil), vous risquez de perdre beaucoup de temps et finalement échouer.

Outil UML automatisé

Visual Paradigm est un outil automatisé qui vous garantit le succès dans vos projets logiciels grâce à :

1. Édition de syntaxe facile pour minimiser le besoin de mémorisation de la notation
2. Support des processus et outils de développement logiciel agile et scrum populaires et les plus simples
3. Automatisé pour simplifier tout projet et tout rapport de produit et tout artefact, en temps réel

Ressources UML

1. Guide complet des 14 types de diagrammes UML – Cybermedian
   • Ce guide présente un aperçu des 14 types de diagrammes UML pris en charge par la version Community de Visual Paradigm. Il explique comment les diagrammes UML aident à visualiser les systèmes intensifs en logiciels et décrit les fonctionnalités offertes par chaque type de diagramme. Le guide met également en évidence la polyvalence de Visual Paradigm dans le soutien à divers diagrammes UML pour divers besoins de modélisation11.
2. Apprenez la modélisation UML avec les meilleurs outils gratuits UML (à la fois en ligne et logiciels gratuits pour bureau) – Cybermedian
   • Cet article discute des avantages de l’utilisation de Visual Paradigm pour la modélisation UML, en mettant l’accent sur son support de la dernière norme UML 2.x et sur sa vaste gamme de types de diagrammes. Il mentionne également les capacités d’intégration de l’outil avec les plateformes de développement populaires et son adoption massive dans le milieu académique et industriel12.
3. Apprendre par l’exemple : Diagrammes d’états machine UML – Cybermedian
   • Cette ressource se concentre sur les diagrammes d’états machine UML et recommande Visual Paradigm comme outil idéal pour créer ces diagrammes. Elle offre une analyse approfondie de la manière dont les diagrammes d’états machine peuvent modéliser le comportement dynamique des systèmes et met en évidence l’intégration de Visual Paradigm avec les outils et plateformes de développement13.
4. Diagrammes UML : un guide complet – Cybermedian
   • Ce guide complet explique l’importance des diagrammes UML dans le développement logiciel et la manière dont Visual Paradigm soutient divers types de diagrammes UML. Il couvre les diagrammes structurels, comportementaux et d’interaction, en offrant des perspectives sur la manière dont Visual Paradigm peut être utilisé pour créer des modèles UML efficaces14.
5. Outil en ligne UML gratuit – Cybermedian
   • Cet article présente Visual Paradigm Online (VP Online) Édition Express, un outil en ligne gratuit pour créer des diagrammes UML. Il met en évidence la facilité d’utilisation de cet outil, son absence de limitations et sa compatibilité avec divers navigateurs web, ce qui en fait une option accessible pour la création de diagrammes UML à usage personnel et non commercial15.
6. Comprendre les diagrammes de temporisation UML : un guide complet – Cybermedian
   • Ce guide explique les diagrammes de temporisation UML et leur importance dans les systèmes en temps réel. Il aborde la manière dont Visual Paradigm peut être utilisé pour créer ces diagrammes, en se concentrant sur la représentation visuelle des contraintes de temps et de durée au sein d’un système16.
7. Le guide complet des diagrammes UML 2.5 – Cybermedian
   • Ce guide présente un aperçu des diagrammes UML 2.5 et met en avant Visual Paradigm comme un choix de premier plan pour la modélisation complète. Il aborde la polyvalence de l’outil, son interface conviviale et ses puissantes fonctionnalités de génération de code, ce qui le rend adapté aux professionnels de divers secteurs17.
8. Un guide complet des diagrammes de classes UML – Cybermedian
   • Ce guide se concentre sur les diagrammes de classes UML et sur la manière dont Visual Paradigm soutient leur création. Il aborde l’adoption généralisée de cet outil dans le milieu académique et son utilisation dans la conception et l’analyse des systèmes et des bases de données. Le guide mentionne également la disponibilité d’exemples et de modèles pour commencer rapidement la modélisation UML18.
9. Tutoriel sur les diagrammes de paquetages UML avec Visual Paradigm – Cybermedian
   • Ce tutoriel explique les étapes nécessaires pour créer un diagramme de paquetages UML à l’aide de Visual Paradigm. Il explique l’importance des diagrammes de paquetages pour organiser les grands systèmes et fournit un guide étape par étape pour leur création à l’aide de Visual Paradigm19.
10. Le guide complet de la modélisation visuelle pour le développement logiciel agile – Cybermedian
    • Ce guide aborde le rôle des outils UML dans le développement logiciel agile et met en avant Visual Paradigm comme un choix populaire. Il explique comment Visual Paradigm propose une interface conviviale et des fonctionnalités telles que la validation, la génération de code et l’ingénierie inverse pour améliorer le processus de modélisation20.