UML signifie Langage de modélisation unifié. Il s’agit d’un langage de modélisation standardisé composé d’un ensemble intégré de diagrammes conçu pour aider les développeurs de systèmes et de logiciels à spécifier, visualiser, construire et documenter les artefacts des systèmes logiciels, ainsi que pour la modélisation des entreprises et d’autres systèmes non logiciels.

UML représente une collection des meilleures pratiques d’ingénierie qui se sont avérées efficaces dans la modélisation de systèmes complexes et de grande taille. UML est une composante essentielle du développement de logiciels orientés objet et du processus de développement logiciel. UML utilise principalement des notations graphiques pour exprimer la conception des projets logiciels. L’utilisation d’UML aide les équipes de projet à communiquer, à explorer des conceptions potentielles et à valider la conception architecturale du logiciel. Dans cet article, nous fournissons des informations détaillées sur ce qu’est UML.

Origines du UML

L’objectif du UML est de fournir une notation standard pouvant être utilisée par toutes les méthodes orientées objet, et de sélectionner et intégrer les meilleurs éléments des notations antérieures. Le UML est conçu pour une large gamme d’applications. Il propose donc des constructions pour une vaste gamme de systèmes et d’activités (par exemple, systèmes distribués, analyse, conception de systèmes et déploiement).

Le UML est né de l’unification de trois notations de modélisation orientées objet majeures :

1. Technique de modélisation des objets (OMT) [James Rumbaugh 1991] – particulièrement adapté à l’analyse et aux systèmes d’information intensifs en données.
2. Booch [Grady Booch 1994] – très puissant pour la conception et l’implémentation. Grady Booch a travaillé de manière approfondie avec le langage Ada et a été un contributeur majeur au développement orienté objet de ce langage. Bien que la méthode Booch soit puissante, sa notation n’était pas très populaire (de nombreuses formes nuageuses dans ses modèles – pas très élégantes).
3. OOSE (Ingénierie logicielle orientée objet [Ivar Jacobson 1992]) – caractérisé par un modèle appelé Cas d’utilisation. Les cas d’utilisation constituent une technique puissante pour comprendre le comportement de l’ensemble du système (un domaine où l’OO était traditionnellement faible).

En 1994, le monde du logiciel a été choqué lorsque Jim Rumbaugh, créateur de l’OMT, a quitté General Electric pour rejoindre Grady Booch chez Rational Software. La collaboration visait à fusionner leurs idées en une méthode unifiée (le titre provisoire était « Méthode unifiée »).

Dès 1995, Ivar Jacobson, créateur de l’OOSE, a également rejoint Rational, et ses idées (notamment le concept de « Cas d’utilisation ») ont été intégrées à la nouvelle méthode unifiée – désormais appelée Langage de modélisation unifié 1. L’équipe formée par Rumbaugh, Booch et Jacobson était affectueusement connue sous le nom des « Trois Amis ».

Le UML a également été influencé par d’autres notations orientées objet à l’époque :

• Mellor et Shlaer [1998]
• Coad et Yourdon [1995]
• Wirfs-Brock [1990]
• Martin et Odell [1992]

Le UML a également intégré de nouveaux concepts absents des autres méthodes majeures de l’époque, tels que les mécanismes d’extension et les langages de contraintes.

Histoire du UML

1. Pendant l’année 1996, le Groupe de gestion des objets (OMG) a publié la première demande de proposition (RFP), qui a servi de catalyseur pour que ces organisations collaborent sur une réponse commune à la RFP.
2. Rational a formé le consortium UML Partners avec plusieurs organisations disposées à consacrer des ressources à une définition solide du UML 1.0. Parmi les contributeurs les plus importants à la définition du UML 1.0 figuraient :
   • Digital Equipment Corporation
   • Hewlett-Packard
   • I-Logix
   • IntelliCorp
   • IBM
   • ICON Computing
   • MCI Systemhouse
   • Microsoft
   • Oracle
   • Rational Software
   • Texas Instruments
   • Unisys
3. Cette collaboration a produit UML 1.0, un langage de modélisation bien défini, expressif, puissant et polyvalent. Il a été soumis à l’OMG comme réponse initiale au RFP en janvier 1997.
4. En janvier 1997, IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies et Softeam ont également soumis des réponses distinctes au RFP à l’OMG. Ces entreprises ont rejoint les partenaires UML afin de contribuer leurs idées, et les partenaires ont conjointement produit une réponse révisée UML 1.1. UML 1.1 s’est concentré sur l’amélioration de la clarté des sémantiques d’UML 1.0 et sur l’intégration des contributions des nouveaux partenaires. Il a été soumis à l’OMG pour examen et adopté à l’automne 1997. Les versions ont évolué de 1.1 à 1.5, suivies par UML 2.0 à 2.5 (la version actuelle est UML 2.5).

Pourquoi UML ?

À mesure que la valeur stratégique du logiciel augmentait pour de nombreuses entreprises, l’industrie cherchait des technologies pour automatiser la production logicielle et améliorer la qualité tout en réduisant les coûts et le temps de mise sur le marché. Ces technologies incluent la technologie des composants, la programmation visuelle, les modèles et les cadres. Les entreprises cherchent également des moyens de gérer la complexité à mesure que leur périmètre et leur échelle augmentent. En particulier, elles reconnaissent la nécessité de résoudre des problèmes architecturaux récurrents tels que la distribution physique, la concurrence, la réplication, la sécurité, l’équilibrage de charge et la tolérance aux pannes. En outre, le développement du World Wide Web, tout en simplifiant certaines choses, a aggravé ces problèmes architecturaux. Le langage de modélisation unifié (UML) a été conçu pour répondre à ces besoins.

1. Fournir aux utilisateurs un langage de modélisation visuelle prêt à l’emploi, expressif, pour concevoir et échanger des modèles significatifs.
2. Fournir des mécanismes d’extension et de spécialisation pour étendre les concepts fondamentaux.
3. Être indépendant des langages de programmation et des processus de développement particuliers.
4. Fournir une base formelle pour comprendre le langage de modélisation.
5. Encourager la croissance du marché des outils orientés objet.
6. Soutenir des concepts de développement de haut niveau tels que les collaborations, les cadres, les modèles et les composants.
7. Intégrer les meilleures pratiques.

UML – Aperçu

Avant de plonger dans la théorie UML, examinons brièvement certains des principaux concepts d’UML.

La première chose à remarquer à propos d’UML est qu’il existe de nombreux diagrammes (modèles) différents auxquels il faut s’habituer. La raison en est que un système peut être vu sous de nombreux angles différents. Le développement logiciel implique de nombreux acteurs.

Par exemple :

• Analystes
• Concepteurs
• Développeurs
• Testeurs
• QA
• Clients
• Rédacteurs techniques

Toutes ces personnes s’intéressent à différents aspects du système, et chaque aspect nécessite un niveau de détail différent. Par exemple, les développeurs doivent comprendre la conception du système et être capables de traduire cette conception en code de bas niveau. En revanche, les rédacteurs techniques s’intéressent au comportement global du système et doivent comprendre la fonctionnalité du produit. UML essaie de fournir un langage suffisamment expressif pour que tous les intervenants puissent bénéficier d’au moins un diagramme UML.

Voici un aperçu rapide de chacun des 13 diagrammes présentés dans la structure des diagrammes UML 2 :

Diagrammes structurels montrent la structure statique du système et de ses composants à différents niveaux d’abstraction et d’implémentation, ainsi que leurs relations. Les diagrammes structurels comportent sept types :

• Diagramme de classes
• Diagramme de composants
• Diagramme de déploiement
• Diagramme d’objets
• Diagramme de paquetages
• Diagramme de structure composite
• Diagramme de profil

Diagrammes comportementaux montrent le comportement dynamique des objets dans le système, qui peut être décrit comme une série de changements au cours du temps. Il existe sept types de diagrammes comportementaux :

• Diagramme de cas d’utilisation
• Diagramme d’activité
• Diagramme d’état-machine
• Diagramme de séquence
• Diagramme de communication
• Diagramme d’aperçu des interactions
• Diagramme de temporisation

Qu’est-ce qu’un diagramme de classes ?

Un diagramme de classes est une technique de modélisation centrale utilisée dans presque toutes les méthodes orientées objet. Le diagramme décrit les types d’objets dans le système et les diverses relations statiques qui existent entre eux.

Relations

Il existe trois relations principales qui sont importantes :

1. Association – indique une relation entre des instances de types (par exemple, une personne travaille pour une entreprise, une entreprise possède plusieurs bureaux).
2. Héritage – l’ajout le plus évident aux diagrammes ER utilisés en programmation orientée objet. Il correspond directement à l’héritage dans la conception orientée objet.
3. Agrégation – une forme de composition d’objets dans la conception orientée objet.

Exemple de diagramme de classes

Pour plus de détails sur les diagrammes de classes, lisez l’article Qu’est-ce qu’un diagramme de classes ?

Qu’est-ce qu’un diagramme de composants ?

Dans le langage de modélisation unifié, un diagramme de composants illustre comment les composants sont connectés pour former des composants plus grands ou des systèmes logiciels. Il illustre l’architecture des composants logiciels et leurs dépendances. Ces composants logiciels incluent les composants d’exécution, les composants exécutables, ainsi que les composants de code source.

Exemple de diagramme de composants

Pour plus de détails sur les diagrammes de composants, lisez l’article Qu’est-ce qu’un diagramme de composants ?

Qu’est-ce qu’un diagramme de déploiement ?

Les diagrammes de déploiement aident à modéliser les aspects physiques des systèmes logiciels orientés objet. Il s’agit d’un diagramme de structure qui montre l’architecture du système sous la forme du déploiement (distribution) des artefacts logiciels sur des cibles de déploiement. Les artefacts représentent des éléments concrets dans le monde physique résultant du processus de développement. Il modélise la configuration en temps d’exécution dans une vue statique et visualise la distribution des artefacts dans une application. Dans la plupart des cas, cela implique la modélisation des configurations matérielles et des composants logiciels qui y résident.

Exemple de diagramme de déploiement

Pour plus de détails sur les diagrammes de déploiement, lisez l’article Qu’est-ce qu’un diagramme de déploiement ?

Qu’est-ce qu’un diagramme d’objets ?

Un diagramme d’objets est un graphe d’instances, comprenant des objets et des valeurs de données. Un diagramme d’objets statique est une instance d’un diagramme de classes ; il montre un instantané de l’état détaillé du système à un moment donné. La différence réside dans le fait qu’un diagramme de classes représente un modèle abstrait composé de classes et de leurs relations, tandis qu’un diagramme d’objets représente des instances à un moment précis, ce qui est intrinsèquement concret. L’utilisation des diagrammes d’objets est assez limitée, principalement pour illustrer des exemples de structures de données.

Diagramme de classes vs diagramme d’objets – Un exemple

Certaines personnes peuvent trouver difficile de comprendre la différence entre les diagrammes de classes UML et les diagrammes d’objets UML, car les deux contiennent des « blocs rectangulaires » nommés avec des attributs et des liens entre eux, ce qui fait que les deux diagrammes UML ont l’air similaires. Certains pensent même qu’ils sont identiques, car dans les outils UML, les symboles de diagramme de classes et de diagramme d’objets sont placés dans le même éditeur de diagrammes – le diagramme de classes.

Mais en réalité, les diagrammes de classes et les diagrammes d’objets représentent deux aspects différents du code. Dans cet article, nous proposons quelques idées sur ces deux diagrammes UML, ce qu’ils sont, comment ils diffèrent, et quand les utiliser.

Relation entre le diagramme de classes et le diagramme d’objets

Vous créez des « classes » lors de la programmation. Par exemple, dans un système bancaire en ligne, vous pouvez créer des classes telles que « Utilisateur », « Compte », « Transaction », etc. Dans un système de gestion de classe, vous pouvez créer des classes telles que « Enseignant », « Étudiant », « Devoir », etc. Dans chaque classe, il existe des attributs et des opérations qui représentent les caractéristiques et les comportements de la classe. Un diagramme de classes est un diagramme UML où vous pouvez visualiser ces classes, leurs attributs, leurs opérations et leurs relations entre elles.

Un diagramme d’objets UML montre à quoi ressemblent les instances d’objets de classes (dessinées dans un diagramme de classes UML) à un état particulier. Autrement dit, un diagramme d’objets UML peut être considéré comme une instance de la manière dont les classes (dans un diagramme de classes UML) sont utilisées à un état spécifique.

Si vous n’aimez pas ces définitions, jetez un œil aux exemples de diagrammes UML ci-dessous. Je pense que vous comprendrez leur différence en quelques secondes.

Exemple de diagramme de classes

L’exemple de diagramme de classes suivant représente deux classes – Utilisateur et Pièce jointe. Un utilisateur peut télécharger plusieurs pièces jointes, donc les deux classes sont associées par une relation de multiplicité 0…* du côté de la pièce jointe.

Exemple de diagramme d’objets

L’exemple de diagramme d’objets suivant montre à quoi ressemblent les instances d’objets des classes Utilisateur et Pièce jointe lorsque Peter (c’est-à-dire un utilisateur) tente de télécharger deux pièces jointes. Il y a donc deux spécifications d’instances pour les deux pièces jointes à télécharger.

Pour plus de détails sur les diagrammes d’objets, lisez l’article Qu’est-ce qu’un diagramme d’objets ?

Qu’est-ce qu’un diagramme de paquetage ?

Un diagramme de paquetage est un diagramme de structure UML qui montre les paquetages et les dépendances entre les paquetages. Les diagrammes de paquetage permettent de montrer différentes vues d’un système, par exemple sous forme d’application multi-couches (également appelée application multi-niveaux) – modèle d’application multi-couches.

Exemple de diagramme de paquetage

Pour plus de détails sur les diagrammes de paquetage, lisez l’article Qu’est-ce qu’un diagramme de paquetage ?

Qu’est-ce qu’un diagramme de structure composite ?

Les diagrammes de structure composite sont l’un des nouveaux artefacts ajoutés à UML 2.0. Un diagramme de structure composite est similaire à un diagramme de classes et constitue un type de diagramme de composants principalement utilisé pour modéliser un système à une échelle microscopique, mais il représente la structure interne d’une seule entité plutôt que d’une classe entière. Il s’agit d’un diagramme de structure statique qui montre la structure interne d’une classe et les collaborations que cette structure permet.

Le diagramme peut inclure des parties internes, des ports par lesquels les parties interagissent entre elles ou les instances de la classe interagissent avec le monde extérieur, ainsi que des connecteurs entre les parties ou les ports. Une structure composite est un ensemble d’éléments interconnectés qui collaborent en temps réel pour atteindre un objectif. Chaque élément a un rôle défini dans cette collaboration.

Exemple de diagramme de structure composite

Pour plus de détails sur les diagrammes de structure composite, lisez l’article Qu’est-ce qu’un diagramme de structure composite ?

Qu’est-ce qu’un diagramme de profil ?

Avec le diagramme de profil, vous pouvez créer des stéréotypes spécifiques au domaine et à la plateforme, et définir leurs relations. Vous pouvez créer des stéréotypes en dessinant des formes de stéréotypes et les relier par composition ou généralisation à travers une interface centrée sur les ressources. Vous pouvez également définir et visualiser les valeurs étiquetées des stéréotypes.

Exemple de diagramme de profil

Pour plus de détails sur les diagrammes de profil, lisez l’article Qu’est-ce qu’un diagramme de profil dans UML ?

Qu’est-ce qu’un diagramme de cas d’utilisation ?

Un modèle de cas d’utilisation décrit les exigences fonctionnelles d’un système en termes de cas d’utilisation. Il s’agit d’un modèle des fonctions souhaitées du système (cas d’utilisation) et de son environnement (acteurs). Les cas d’utilisation permettent de relier ce que le système doit faire à la manière dont le système répond à ces exigences.

Pensez au modèle de cas d’utilisation comme à un menu, comme celui que vous trouvez dans un restaurant. En regardant le menu, vous pouvez voir quels plats sont disponibles, les plats individuels et leurs prix. Vous savez également quel type de cuisine sert le restaurant : italienne, mexicaine, chinoise, etc. En regardant le menu, vous obtenez une idée globale de l’expérience culinaire qui vous attend dans ce restaurant. Le menu imite en réalité le comportement du restaurant.

Étant donné qu’il s’agit d’un outil de planification puissant, les modèles de cas d’utilisation sont utilisés par tous les membres de l’équipe tout au long de toutes les phases du cycle de développement.

Exemple de diagramme de cas d’utilisation

Pour plus de détails sur les diagrammes de cas d’utilisation, lisez l’article Qu’est-ce qu’un diagramme de cas d’utilisation ?

Qu’est-ce qu’un diagramme d’activité ?

Un diagramme d’activité est une représentation graphique des flux de travail d’activités et d’actions étape par étape, avec un support pour le choix, l’itération et la concurrence. Il décrit le flux de contrôle du système cible, par exemple pour explorer des règles commerciales complexes et des opérations, décrire des cas d’utilisation et des processus commerciaux. Dans le langage de modélisation unifié, les diagrammes d’activité visent à modéliser à la fois les processus computationnels et organisationnels (c’est-à-dire les flux de travail).

Exemple de diagramme d’activité

Pour plus de détails sur les diagrammes d’activité, lisez l’article Qu’est-ce qu’un diagramme d’activité ?

Qu’est-ce qu’un diagramme d’état-machine ?

Un diagramme d’état est un type de diagramme utilisé dans UML pour décrire le comportement d’un système basé sur le concept de statechart de David Harel. Les diagrammes d’état représentent les états autorisés et les transitions, ainsi que les événements qui affectent ces transitions. Il aide à visualiser l’intégralité du cycle de vie d’un objet, facilitant ainsi une meilleure compréhension des systèmes basés sur les états.

Exemple de diagramme d’état-machine

Pour plus de détails sur les diagrammes d’état-machine, lisez l’article Qu’est-ce qu’un diagramme d’état-machine ?

Qu’est-ce qu’un diagramme de séquence ?

Un diagramme de séquence modélise la collaboration d’objets selon une séquence temporelle. Il montre comment les objets interagissent entre eux dans un scénario particulier de cas d’utilisation. Grâce à ses capacités avancées de modélisation visuelle, vous pouvez créer des diagrammes de séquence complexes en quelques clics seulement. En outre, certains outils de modélisation (comme Visual Paradigm) peuvent générer des diagrammes de séquence à partir du flux d’événements que vous avez définis dans les descriptions de cas d’utilisation.

Exemple de diagramme de séquence

Pour plus de détails sur les diagrammes de séquence, lisez l’article Qu’est-ce qu’un diagramme de séquence ?

Qu’est-ce qu’un diagramme de communication ?

Similaire à un diagramme de séquence, un diagramme de communication est également utilisé pour modéliser le comportement dynamique d’un cas d’utilisation. Contrairement aux diagrammes de séquence, les diagrammes de communication mettent davantage l’accent sur la visualisation de la collaboration entre objets plutôt que sur la séquence temporelle. Ils sont sémantiquement équivalents, de sorte que certains outils de modélisation (comme Visual Paradigm) permettent de générer l’un à partir de l’autre.

Exemple de diagramme de communication

Pour plus de détails sur les diagrammes de communication, lisez l’article Qu’est-ce qu’un diagramme de communication ?

Qu’est-ce qu’un diagramme d’aperçu d’interaction ?

Un diagramme d’aperçu d’interaction se concentre sur un aperçu du flux de contrôle de l’interaction. Il s’agit d’une variante du diagramme d’activité où les nœuds représentent des interactions ou des occurrences d’interaction. Le diagramme d’aperçu d’interaction décrit les interactions où les messages et les lignes de vie sont masqués. Vous pouvez créer des liens vers des diagrammes « réels » et assurer une navigation efficace entre les diagrammes dans le diagramme d’aperçu d’interaction.

Exemple de diagramme d’aperçu d’interaction

Pour plus de détails sur les diagrammes d’aperçu d’interaction, lisez l’article Qu’est-ce qu’un diagramme d’aperçu d’interaction ?

Qu’est-ce qu’un diagramme de temporisation ?

Un diagramme de temporisation montre le comportement des objets au cours d’une période donnée. Les diagrammes de temporisation sont une forme particulière de diagramme de séquence. La différence entre les diagrammes de temporisation et les diagrammes de séquence réside dans le fait que les axes sont inversés, de sorte que le temps augmente de gauche à droite, et que les lignes de vie sont affichées dans des compartiments séparés disposés verticalement.

Exemple de diagramme de temporisation

Pour plus de détails sur les diagrammes de temporisation, lisez l’article Qu’est-ce qu’un diagramme de temporisation ?

Apprenez UML. Dessinez UML.

Obtenez Visual Paradigm Community Edition – un outil UML GRATUIT qui vous aide à apprendre UML plus rapidement et plus efficacement. Visual Paradigm Community Edition prend en charge tous les types de diagrammes UML. Son modèleur UML primé est intuitif et facile à utiliser.

Téléchargement gratuit

Glossaire et terminologie UML

• Classe abstraite – Une classe qui n’est jamais instanciée. Aucune instance de cette classe n’existe jamais.
• Acteur – Un objet ou une personne qui initie les événements liés au système.
• Activité: Une étape ou une action dans un diagramme d’activité. Représente une opération effectuée par le système ou un acteur.
• Diagramme d’activité: Un organigramme amélioré qui montre les étapes et les décisions dans un processus, ainsi que des opérations parallèles, comme un algorithme ou un processus métier.
• Agrégation – Fait partie d’une autre classe. Représenté par un losange creux à côté de la classe conteneur dans le diagramme.
• Artéfact – Un document décrivant la sortie d’une étape du processus de conception. La description peut être graphique, textuelle ou une combinaison des deux.
• Association – Une connexion entre deux éléments dans le modèle. Cela peut représenter une variable membre dans le code, une association entre un dossier personnel et la personne qu’il représente, une relation entre deux catégories de travailleurs, ou toute autre relation similaire. Par défaut, les deux éléments d’une association se connaissent mutuellement et sont équivalents. Une association peut également être navigable, ce qui signifie que l’extrémité source connaît l’extrémité cible, mais pas inversement.
• Classe d’association: Une classe qui représente une association entre deux autres classes et ajoute des informations à cette association.
• Attribut – Une caractéristique d’un objet qui peut être utilisée pour référencer d’autres objets ou stocker des informations sur l’état de l’objet.
• Classe de base: La classe qui définit les attributs et les opérations hérités par les sous-classes à travers une relation de généralisation.
• Branche: Un point de décision dans un diagramme d’activité. Plusieurs transitions émergent d’une branche, chacune avec une condition de garde. Lorsque le contrôle atteint la branche, exactement une condition de garde doit être vraie, et le contrôle suit la transition correspondante.
• Classe: Une catégorie d’objets similaires, tous décrits par les mêmes attributs et opérations, et tous compatibles par affectation.
• Diagramme de classe – Montre les classes dans le système et les relations entre elles.
• Classificateur: Un élément UML qui possède des attributs et des opérations. Plus précisément, les acteurs, les classes et les interfaces.
• Collaboration: Une relation entre deux objets dans un diagramme de communication, indiquant que les messages peuvent circuler dans les deux sens entre les objets.
• Diagramme de communication – Un diagramme qui montre comment une opération est réalisée tout en mettant l’accent sur les rôles des objets.
• Composant: Une unité déployable de code dans le système.
• Diagramme de composant: Un diagramme qui montre les relations entre divers composants et interfaces.
• Concept – Un nom ou un concept abstrait à inclure dans le modèle de domaine.
• Phase de construction – La troisième phase du Processus Unifié Rational, durant laquelle plusieurs itérations fonctionnelles sont construites dans le système. C’est là que se déroule la majeure partie du travail.
• Dépendance: Une relation indiquant qu’un classificateur connaît les attributs et opérations d’un autre classificateur, mais n’est pas directement connecté à aucune instance de ce second classificateur.
• Diagramme de déploiement: Un diagramme montrant les relations entre divers processeurs.
• Domaine – La partie de l’univers de discours avec laquelle le système est impliqué.
• Phase d’élaboration – La deuxième phase du Processus Unifié Rational, permettant une planification supplémentaire du projet, y compris les itérations de la phase de construction.
• Élément: Tout élément affiché dans le modèle.
• Encapsulation – Les données à l’intérieur d’un objet sont privées.
• Généralisation – Indique qu’une classe est une sous-classe d’une autre (superclasse). La flèche creuse pointe vers la superclasse.
• Événement: Dans un diagramme d’état, cela représente un signal, un événement ou une entrée qui provoque une action ou un changement d’état du système.
• État final: Dans un diagramme d’état ou un diagramme d’activité, cela représente le point où le diagramme est terminé.
• Fork: Un point dans un diagramme d’activité où plusieurs threads de contrôle parallèles commencent.
• Généralisation: Une relation d’héritage où une sous-classe hérite et ajoute aux attributs et opérations d’une classe de base.
• GoF – Modèles de conception du Gang des Quatre.
• Haute cohésion – Un modèle d’évaluation GRASP qui garantit qu’une classe n’est pas trop complexe et ne réalise pas des fonctions non liées.
• Faible couplage – Un modèle d’évaluation GRASP qui mesure le degré de dépendance ou de connexion entre une classe et une autre classe.
• Phase d’initiation – La première phase du Processus Unifié Rational, qui traite de la conceptualisation initiale et du démarrage du projet.
• Héritage – Une sous-classe hérite des attributs ou des caractéristiques de sa classe parente (classe supérieure). Ces attributs peuvent être redéfinis dans la sous-classe.
• État initial: Dans un diagramme d’état ou un diagramme d’activité, cela représente le point où le diagramme commence.
• Instance – Un objet est une instance d’une classe. La classe agit comme un modèle pour la création d’objets. Un nombre quelconque d’instances de la classe peut être créé.
• Interface: Un classificateur qui définit des attributs et des opérations formant un contrat comportemental. Une classe ou un composant fournisseur peut choisir de réaliser l’interface (c’est-à-dire implémenter ses attributs et opérations). Les classes ou composants clients peuvent alors dépendre de l’interface, utilisant ainsi le fournisseur sans connaître les détails de la véritable classe fournisseur.
• Itération – Une portion mini-projet où une petite fonctionnalité est ajoutée au projet. Comprend un cycle de développement comprenant l’analyse, la conception et la codification.
• Réunion: Un point dans un diagramme d’activité où plusieurs fils de contrôle parallèles se synchronisent et se rejoignent.
• Membre: Un attribut ou une opération dans un classificateur.
• Fusion: Un point dans un diagramme d’activité où des chemins de contrôle différents se rejoignent.
• Message – Une requête émise par un objet à un autre, demandant à l’objet récepteur d’effectuer une action. C’est essentiellement un appel à une méthode de l’objet récepteur.
• Méthode – Une fonction ou une procédure dans un objet.
• Modèle – L’élément central de UML. Composé d’éléments divers disposés en hiérarchies avec des relations entre les éléments.
• Multiplicité – Affiché à côté de la boîte de concept externe dans un modèle de domaine et indique la relation quantitative entre les objets et d’autres objets.
• Navigation: Indique quel bout d’une relation connaît l’autre bout. Une relation peut avoir une navigation bidirectionnelle (chaque bout connaît l’autre) ou une navigation unidirectionnelle (un bout connaît l’autre, mais pas inversement).
• Notation – Documentation graphique avec des règles pour créer des méthodes d’analyse et de conception.
• Note: Un commentaire textuel ajouté à un diagramme pour expliquer plus en détail le diagramme.
• Objet – Dans un diagramme d’activité, un objet qui reçoit des informations ou fournit des informations à une activité. Dans un diagramme de collaboration ou de séquence, un objet participant au scénario décrit dans le diagramme. Généralement : une instance ou un exemple d’un classificateur donné (Acteur, Classe ou Interface).
• Paquet – Un groupe d’éléments UML qui appartiennent logiquement ensemble.
• Diagramme de paquet: Un diagramme de classes où tous les éléments sont des paquets et des dépendances.
• Modèle – Une solution au problème de l’affectation de responsabilités pour les interactions entre objets. C’est une solution nommée à un problème courant et bien connu.
• Paramètre: Un paramètre d’une opération.
• Polymorphisme – Même message, méthodes différentes. Utilisé également comme un modèle.
• Privé: Niveau de visibilité appliqué à un attribut ou une opération, indiquant que seul le code contenu dans le classificateur conteneur peut accéder au membre.
• Processeur: Dans un diagramme de déploiement, cela représente un ordinateur ou un autre dispositif programmable sur lequel le code peut être déployé.
• Protégé: Niveau de visibilité appliqué à un attribut ou une opération, indiquant que seul le code contenu dans le classificateur conteneur ou ses sous-classes peut accéder au membre.
• Public: Niveau de visibilité appliqué à un attribut ou une opération, indiquant que tout code peut accéder au membre.
• Flèche de direction de lecture – Indique la direction d’une relation dans un modèle de domaine.
• Réalisation: Indique qu’un composant ou une classe fournit une interface donnée.
• Rôle – Utilisé dans un modèle de domaine, il s’agit d’une description facultative du rôle joué par une entité.
• Diagramme de séquence: Un diagramme montrant l’existence des objets au fil du temps et les messages échangés entre ces objets au fil du temps pour effectuer un comportement. Diagramme d’état – Un diagramme montrant tous les états possibles d’un objet.
• État: Dans un diagramme d’état, cela représente un état ou une condition du système ou du sous-système : ce qu’il fait à un instant donné, ainsi que ses valeurs de données.
• Diagramme d’état: Un diagramme montrant les états d’un système ou d’un sous-système, les transitions entre ces états, et les événements qui provoquent ces transitions.
• Statique: Un modificateur appliqué à un attribut indiquant qu’une seule copie de l’attribut est partagée entre toutes les instances du classificateur. Un modificateur appliqué à une opération indiquant que l’opération est indépendante et ne s’applique pas à une instance spécifique du classificateur.
• Stéréotype: Un modificateur appliqué à un élément de modèle indiquant quelque chose qui ne peut généralement pas être exprimé en UML. En essence, les stéréotypes vous permettent de définir votre propre « dialecte » d’UML.
• Sous-classe: Une classe qui hérite des attributs et des opérations définis par une superclasse via une relation d’ généralisation.
• Ligne de nage: Un élément dans un diagramme d’activité indiquant quelle partie du système ou du domaine est responsable d’une activité particulière. Toutes les activités dans une ligne de nage sont la responsabilité de l’objet, du composant ou de l’acteur représenté par la ligne de nage.
• Time boxing – Chaque itération a une limite de temps fixe avec un objectif spécifique.
• Transition: Dans un diagramme d’activité, cela représente le flux de contrôle d’une activité, branche, fusion, division ou jonction à une autre. Dans un diagramme d’état, cela représente un changement d’un état à un autre.
• Phase de transition – La phase finale du Processus Unifié Rational durant laquelle les utilisateurs sont formés à utiliser le nouveau système et le système est mis à disposition des utilisateurs.
• UML – Le langage de modélisation unifié améliore l’analyse et la conception des projets logiciels en permettant des relations plus étroites entre les objets grâce à la documentation textuelle et graphique.
• Cas d’utilisation: Dans un diagramme de cas d’utilisation, cela représente une action entreprise par le système en réponse à une demande d’un acteur.
• Diagramme de cas d’utilisation: Un diagramme montrant les relations entre les acteurs et les cas d’utilisation.
• Visibilité: Un modificateur pour un attribut ou une opération indiquant quel code peut accéder le membre. Les niveaux de visibilité incluent Public, Protégé et Privé.
• Flot de travail – Un ensemble d’activités qui produisent un résultat spécifique.

Livres UML populaires

Voici certains des livres UML les plus vendus que vous pouvez lire pour apprendre UML :

1. UML Distillé : Un bref guide vers le langage standard de modélisation des objets
2. UML 2 et le Processus Unifié : Analyse et conception orientées objet pratiques
3. Apprendre UML 2.0
4. Construire des applications web avec UML
5. Manuel de référence du langage de modélisation unifié
6. Les éléments du style UML™ 2.0
7. UML pour les développeurs Java
8. Schéma de UML
9. Guide de l’utilisateur du langage de modélisation unifié
10. Guide de certification UML 2 : Examens fondamentaux et intermédiaires
11. Les fondamentaux de la conception orientée objet en UML
12. Application de la modélisation orientée objet pilotée par les cas d’utilisation avec UML : un exemple annoté de commerce électronique
13. Conception de systèmes orientés objet flexibles avec UML
14. Modélisation orientée objet pilotée par les cas d’utilisation avec UML
15. Analyse et conception de systèmes avec UML version 2.0 : une approche orientée objet
16. UML 2.0 en bref
17. Analyse et conception orientées objet avec applications
18. UML expliqué
19. Design Patterns : Éléments de logiciels orientés objet réutilisables
20. Le Principe des objets : Développement orienté modèle agile avec UML 2.0

Liens connexes

1. Outil professionnel de conception UML pour la modélisation visuelle