Tous les diagrammes UML peuvent être divisés en deux groupes, le premier étant constitué des diagrammes généraux. Les diagrammes généraux sont pratiquement indépendants du sujet de modélisation et peuvent être utilisés dans n'importe quel projet logiciel sans égard au domaine, au domaine de solution, etc.

1.5.1. Schéma d'utilisation

Schéma d'utilisation(diagramme de cas d'utilisation) est la représentation la plus générale de l'objectif fonctionnel du système.

Le diagramme d’utilisation est conçu pour répondre à la principale question de modélisation : que fait le système dans le monde extérieur ?

Un diagramme d'utilisation utilise deux types d'entités principales : les cas d'utilisation 1 et les acteurs 2, entre lesquels les types de relations de base suivants sont établis :

• association entre acteur et cas d'usage 3 ;
• généralisation entre acteurs 4 ;
• généralisation entre cas d'usage 5 ;
• dépendances (de différents types) entre cas d'utilisation 6.

Un diagramme d'utilisation, comme tout autre diagramme, peut contenir des commentaires 7 . De plus, cela est fortement recommandé pour améliorer la lisibilité des schémas.

Les principaux éléments de la notation utilisée dans le diagramme d'utilisation sont présentés ci-dessous. Une description détaillée est donnée à la section 2.2.

1.5.2. Diagramme de classes

Diagramme de classes(diagramme de classes) est le principal moyen de décrire la structure du système.

Cela n’est pas surprenant, puisque UML est avant tout un langage orienté objet et que les classes en sont le principal (sinon le seul) élément de base.

Un diagramme de classes utilise un type d'entité de base : les classes 1 (comprenant de nombreux cas particuliers de classes : interfaces, types primitifs, classes d'association et bien d'autres), entre lesquelles les types de relations de base suivants sont établis :

• association entre 2 classes (avec plein de détails supplémentaires) ;
• généralisation entre classes 3 ;
• dépendances (de divers types) entre classes 4 et entre classes et interfaces.

Certaines des notations utilisées dans un diagramme de classes sont présentées ci-dessous. Une description détaillée est donnée au chapitre 3.

1.5.3. Schéma de la machine

Schéma de la machine(diagramme de machine à états) est l'un des moyens de décrire le comportement en détail en UML sur la base de l'identification explicite des états et de la description des transitions entre les états.

Essentiellement, les diagrammes d'automates, comme leur nom l'indique, sont un graphique de transitions d'état (voir chapitre 4) chargé de nombreux détails et détails supplémentaires.

Sur un diagramme d'automate, un type principal d'entité est utilisé - les états 1, et un type de relation - les transitions 2, mais pour les deux, de nombreuses variétés, cas particuliers et notations supplémentaires sont définis. Il ne sert à rien de tous les énumérer dans une revue introductive.

Une description détaillée de toutes les variantes des diagrammes d'automates est donnée dans la section 4.2, et la figure suivante ne montre que les principaux éléments de la notation utilisée dans le diagramme d'automate.

1.5.4. Diagramme d'activité

Diagramme d'activité(diagramme d'activité) - un moyen de décrire le comportement basé sur la spécification des flux de contrôle et des flux de données.

Un diagramme d’activités est une autre façon de décrire un comportement qui rappelle visuellement un bon vieil organigramme algorithmique. Cependant, grâce à la notation modernisée cohérente avec l'approche orientée objet, et surtout grâce à la nouvelle composante sémantique (interprétation libre des réseaux de Petri), le diagramme d'activité UML est un outil puissant pour décrire le comportement du système.

Le diagramme d'activités utilise un type principal d'entité - l'action 1, et un type de relation - les transitions 2 (transferts de contrôle et de données). Sont également utilisées des constructions telles que des fourches, des fusions, des connexions, des branches 3, qui sont similaires aux entités, mais en fait elles ne le sont pas, mais constituent une manière graphique de représenter certains cas particuliers de relations multi-places. La sémantique des éléments du diagramme d’activités est abordée en détail au chapitre 4. Les principaux éléments de notation utilisés dans un diagramme d’activités sont présentés ci-dessous.

1.5.5. Diagramme de séquençage

Diagramme de séquençage(diagramme de séquence) est une manière de décrire le comportement d'un système basé sur l'indication de la séquence des messages transmis.

En fait, un diagramme de séquence est un enregistrement du protocole d'une session spécifique du système (ou un fragment d'un tel protocole). En programmation orientée objet, la chose la plus importante à l'exécution est la transmission des messages entre les objets communicants. C'est la séquence d'envoi des messages qui est affichée dans ce schéma, d'où le nom.

Un diagramme de séquence utilise un type principal d'entités - les instances de classificateurs en interaction 1 (principalement des classes, des composants et des acteurs), et un type de relation - les connexions 2 le long desquelles les messages sont échangés 3. Il existe plusieurs manières d'envoyer des messages, qui en notation graphique diffèrent par le type de flèche correspondant à la relation.

Un aspect important d’un diagramme de séquence est de montrer clairement le passage du temps. Contrairement à d'autres types de diagrammes, à l'exception peut-être des diagrammes de synchronisation, dans un diagramme de séquence, il est important non seulement la présence de connexions graphiques entre les éléments, mais également la position relative des éléments sur le diagramme. À savoir, on suppose qu'il existe un axe temporel (invisible), par défaut, dirigé de haut en bas, et le message envoyé ultérieurement est dessiné en dessous.

L’axe du temps peut être orienté horizontalement, auquel cas le temps est considéré comme s’écoulant de gauche à droite.

La figure suivante montre la notation de base utilisée dans un diagramme de séquence. Pour désigner les objets en interaction eux-mêmes, une notation standard est utilisée - un rectangle avec le nom de l'instance du classificateur. La ligne pointillée qui en sort s’appelle la bouée de sauvetage 4. Il ne s'agit pas d'une représentation d'une relation dans le modèle, mais d'un commentaire graphique destiné à guider le lecteur du diagramme dans la bonne direction. Les figures en forme de rayures étroites superposées sur la ligne de vie ne sont pas non plus des images des entités simulées. Il s'agit d'un commentaire graphique montrant les périodes de temps pendant lesquelles l'objet possède le flux de contrôle (occurrence d'exécution) 5 ou, en d'autres termes, l'activation de l'objet a lieu. Les étapes de fragments combinées 6 permettent au diagramme de séquence de refléter les aspects algorithmiques du protocole d'interaction. Pour d'autres détails sur la notation des diagrammes de séquence, voir le chapitre 4.

1.5.6. Schéma de communication

Schéma de communication(diagramme de communication) est une manière de décrire un comportement qui est sémantiquement équivalente à un diagramme de séquence.

En fait, il s'agit de la même description de la séquence d'échange de messages d'instances en interaction de classificateurs, exprimée uniquement par d'autres moyens graphiques. De plus, la plupart des outils peuvent convertir automatiquement les diagrammes de séquence en diagrammes de communication et vice versa.

Ainsi, dans le diagramme de communication, ainsi que dans le diagramme de séquence, un type principal d'entité est utilisé - les instances de classificateurs en interaction 1 et un type de relation - les connexions 2. Cependant, ici l'accent n'est pas mis sur le temps, mais sur la structure des liens entre des instances spécifiques.

La figure montre les principaux éléments de notation utilisés dans un diagramme de communication. Pour désigner les objets en interaction eux-mêmes, une notation standard est utilisée - un rectangle avec le nom de l'instance du classificateur. La position relative des éléments dans le diagramme de coopération n'a pas d'importance - seules les connexions (le plus souvent des instances d'associations) le long desquelles les messages sont transmis 3 sont importantes. La numérotation décimale hiérarchique est utilisée pour afficher l'ordre des messages dans le temps.

1.5.7. Diagramme des composants

Diagramme des composants(schéma des composants) - montre les relations entre les modules (logiques ou physiques) qui composent le système modélisé.

Le principal type d'entités dans un diagramme de composants sont les composants eux-mêmes 1, ainsi que les interfaces 2, à travers lesquelles la relation entre les composants est indiquée. Les relations suivantes s'appliquent dans un diagramme de composants :

• implémentations entre composants et interfaces (un composant implémente une interface) ;
• dépendances entre composants et interfaces (le composant utilise l'interface) 3.

La figure montre les principaux éléments de la notation utilisée dans un diagramme de composants. Une description détaillée est donnée au chapitre 3.

1.5.8. Diagramme de placement

Diagramme de placement(schéma de déploiement), en plus d'afficher la composition et les connexions des éléments du système, montre comment ils sont physiquement situés sur les ressources informatiques au moment de l'exécution.

Ainsi, dans un diagramme de placement, par rapport à un diagramme de composants, deux types d'entités s'ajoutent : l'artefact 1, qui est une implémentation du composant 2 et du nœud 3 (peut être soit un classificateur décrivant le type de nœud, soit une instance spécifique), ainsi que la relation d'association entre les nœuds 4, montrant que les nœuds sont physiquement connectés au moment de l'exécution.

La figure montre les principaux éléments de la notation utilisée dans un schéma d'implantation. Pour montrer qu'une entité fait partie d'une autre, soit une relation de dépendance de « déploiement » est appliquée 5, soit une figure d'une entité est placée à l'intérieur d'une figure d'une autre entité 6 . Une description détaillée du diagramme est donnée au chapitre 3.

Montrer le comportement d'un objet au cours de sa vie, de la création de l'objet jusqu'à sa destruction. Chaque diagramme d'état représente un automate.

Plan d'action

Dans la section Description, découvrez l'ensemble de base des symboles d'états-transitions nécessaires pour pouvoir lire des diagrammes.

Après avoir lu les autres sections (Exemple, Application), vous pouvez vous essayer à la création de diagrammes d'états vous-même.

Remarques (description)

Voici le jeu de caractères de base diagrammes d'état, nécessaire pour pouvoir lire le schéma. Après avoir lu les autres sections (« Exemple », « Application ») vous pourrez composer diagrammes d'état tout seul!

Terme	Image	Description
Pseudo-état initial		État initial du système
Transition		La transition signifie passer d’un état à un autre.
État		Désigne les actions effectuées par le système (peut inclure des options possibles) conduisant aux résultats observés par les acteurs.
État état d'activité		Une étape difficile dans un précédent peut être représentée par un autre précédent. En termes UML, on dit que le premier cas d’utilisation inclut le second.
État final		Vous permet de définir les limites des systèmes ou des sous-systèmes.
Activités internes		Cas où les États peuvent réagir à des événements sans effectuer de transition, auquel cas l'événement, la protection et l'activité sont placés à l'intérieur du rectangle de l'État.
Activité d'entrée		L'activité de saisie est exécutée chaque fois que vous entrez dans un état
Activité de sortie		Activité de sortie – S'exécute chaque fois que vous quittez l'état.
Super-État		Il arrive souvent que plusieurs États aient des transitions et des activités internes communes. Dans de tels cas, ils peuvent être transformés en sous-États et le comportement global peut être transféré à un super-État.
États parallèles		Les États peuvent être divisés en plusieurs États parallèles fonctionnant simultanément.

Comment utiliser les techniques de créativité

Les diagrammes d'état UML sont utiles pour décrire le comportement d'un seul objet dans plusieurs cas d'utilisation. Mais ils ne sont pas très adaptés pour décrire des comportements caractérisés par l’interaction de nombreux objets. Il est donc logique d’utiliser d’autres technologies en conjonction avec des diagrammes d’états. Par exemple, les diagrammes d'interaction (Chapitre 4) font un excellent travail en décrivant le comportement de plusieurs objets dans un seul cas d'utilisation, et les diagrammes d'activités UML sont utiles pour montrer la séquence d’actions de base de plusieurs objets dans plusieurs cas d’utilisation.

Tout le monde ne considère pas les diagrammes d’état comme naturels. Regardez comment les experts travaillent avec eux. Il est possible que les membres de votre équipe pensent que les diagrammes d'états-transitions ne conviennent pas à leur style de travail. Ce n’est pas la plus grande difficulté ; vous devez vous rappeler d'utiliser différentes techniques de travail ensemble.

Si vous utilisez des diagrammes d'états, n'essayez pas de les dessiner pour chaque classe du système. Cette approche est souvent utilisée dans un but d’exhaustivité formellement stricte, mais elle constitue presque toujours un gaspillage d’efforts. Utilisez les diagrammes d'états-transitions uniquement pour les classes qui présentent un comportement intéressant, où dessiner un diagramme d'états-transitions vous aide à comprendre comment les choses se produisent.

De nombreux experts estiment que L'éditeur d'interface utilisateur et les objets de contrôle disposent de fonctionnalités utiles lorsqu'ils sont affichés à l'aide d'un diagramme d'état.

Comment apprendre

Ici, nous avons essayé de fournir un moyen aussi simple que possible d'apprendre Diagrammes d'état UML.

Comme beaucoup d’autres langages, il utilise un ensemble de symboles pour la description. La signification de ces signes figure dans le tableau de la rubrique « Remarques (description) ». Chaque signe a son propre nom (terme) et orthographe. De plus, chaque terme est accompagné d’une brève explication pour comprendre rapidement son essence fondamentale.

Ensuite, nous vous recommandons d'aller dans la section « Exemples » diagrammes d'état pour vous essayer à la lecture de différents schémas. Ensuite, cela vaut la peine d'étudier la section « Application », car, bien que le nombre de types de diagrammes dans UML soit faible, vous ne pouvez tirer le meilleur parti de leur utilisation que si vous utilisez les diagrammes correspondants aux fins prévues.

Exemple d'utilisation

Diagrammes de machines à états est une technologie bien connue pour décrire le comportement d’un système. Les diagrammes d'état existent sous une forme ou une autre depuis 1960 et, au début de la programmation orientée objet, ils étaient utilisés pour représenter le comportement d'un système. Dans les approches orientées objet, vous dessinez un diagramme d’état d’une classe unique pour montrer le comportement d’un objet unique au cours de sa durée de vie.

Chaque fois que l’on parle de machines à états finis, les exemples incluent inévitablement les systèmes de régulateur de vitesse ou les distributeurs automatiques.
Nous avons décidé d'utiliser un contrôleur de panneau de contrôle secret dans un château gothique. Dans ce château, nous voulons cacher nos trésors afin qu'ils soient difficiles à trouver. Pour accéder à la serrure du coffre-fort, il faut retirer la bougie stratégique du candélabre, mais la serrure n'apparaîtra que si la porte est fermée. Une fois la serrure apparue, nous pouvons y insérer la clé et ouvrir le coffre-fort. Pour plus de sécurité, nous avons fait en sorte que le coffre-fort ne puisse être ouvert qu'après avoir retiré la bougie. Si le voleur ne fait pas attention à cette précaution, alors nous libérerons un monstre dégoûtant qui avalera le voleur.

En figue. 10.1 affiché diagramme d'état une classe de contrôleur qui gère mon système de sécurité sophistiqué. Le diagramme d'état commence par l'état de l'objet contrôleur en cours de création : état Attendez. Ceci est indiqué dans le diagramme par pseudo-état initial, qui n'est pas un état mais qui a une flèche pointant vers l'état initial.
Le diagramme montre que le contrôleur peut être dans l'un des trois états suivants : Attendez, verrouillez et ouvrez. Le diagramme montre également les règles selon lesquelles le contrôleur passe d'un état à un autre. Ces règles se présentent sous forme de transitions – des lignes reliant les états.

La transition signifie passer d’un état à un autre. Chaque transition possède sa propre étiquette, composée de trois parties :
signature-déclencheur/activité. Tous sont facultatifs. Généralement, identifiant du déclencheur est le seul événement pouvant provoquer un changement d’état.

La garde, si elle est spécifiée, est une condition logique qui doit être satisfaite pour que la transition ait lieu. L'activité est un comportement du système lors d'une transition. Cela peut être n’importe quelle expression comportementale. La forme complète d'un déclencheur d'ID peut inclure plusieurs événements et paramètres. La transition de l'état d'attente (Fig. 10.1) à un autre état peut être lue comme « Dans l'état d'attente, si la bougie est retirée, vous voyez un verrou et passez à l'état de verrouillage. »

Les trois parties de la description de la transition sont facultatives. Sauter une activité signifie que rien ne se passe pendant la transition. Sauter les boucliers signifie que la transition est toujours effectuée si un événement déclencheur se produit. L'ID du déclencheur manque rarement, mais cela arrive. Cela signifie que la transition se produit immédiatement, ce qui peut être observé principalement dans les états actifs.

Lorsqu'un événement se produit dans un certain état, une seule transition peut être effectuée à partir de cet état, par exemple, dans l'état Lock (Fig. 10.1), les protections doivent s'exclure mutuellement. Si un événement se produit et qu'aucune transition n'est autorisée (par exemple, fermer un coffre-fort en état d'attente ou retirer une bougie alors que la porte est ouverte), l'événement est ignoré.

État final ( état final) signifie que la machine à états a fini de fonctionner, ce qui entraîne la suppression de l'objet contrôleur. Alors pour ceux qui ont eu l'imprudence de tomber dans le piège, puisque l'objet contrôleur cesse d'exister, on est obligé de remettre le lapin dans la cage, de nettoyer le sol et de redémarrer le système.

N'oubliez pas que les machines à états ne peuvent afficher que les objets qui sont directement observés ou sur lesquels une action est effectuée. Ainsi, même si vous pourriez vous attendre à ce que nous mettions ou retirions quelque chose du coffre-fort lorsque la porte est ouverte, nous ne l'avons pas marqué sur le schéma car le contrôleur ne peut rien nous en dire.

Lorsque les développeurs parlent d'objets, ils font souvent référence à l'état des objets, c'est-à-dire à la combinaison de toutes les données contenues dans les champs des objets. Cependant, un état dans un diagramme de machine à états est un concept d'état plus abstrait ; Le fait est que différents États nécessitent différentes manières de réagir aux événements.

Activités internes dans un statechart

Les États peuvent réagir aux événements sans effectuer de transition en utilisant activités internes (activités internes), auquel cas l'événement, la protection et l'activité sont placés à l'intérieur du rectangle d'état.

En figue. 10.2 montre l'état avec les activités des symboles internes et les événements du système d'aide, que vous pouvez observer dans les champs de texte de l'éditeur Interface utilisateur. L'activité interne est comme une auto-transition - une transition qui revient au même état. La syntaxe des activités internes est construite selon le même schéma logique d'événements, de protections et de procédures.

En figue. 10.2 montre également les activités spéciales : activités d'entrée et de sortie. Activité d'entrée exécuté chaque fois que vous entrez dans un état ; activité de sortie- chaque fois que vous quittez l'État. Toutefois, les activités internes ne sont pas initiées activités d'entrée et de sortie; c'est la différence entre activités internes ettransitions personnelles .

États d'activité dans un diagramme d'état

Dans les états que nous avons décrits jusqu'à présent, l'objet est silencieux et attend le prochain événement avant de faire quoi que ce soit. Cependant, des états sont possibles dans lesquels l'objet présente une certaine activité.

État Recherche En figue. 10.3 est un tel état état d'activité: l'activité en cours est indiquée par un symbole faire/; d'où le terme faire-activité (être actif). Une fois la recherche terminée, les transitions sont effectuées sans activité, comme l'affichage d'un nouvel équipement (Afficher le nouveau matériel). Si un événement d'annulation survient lors d'une activité ( Annuler), Que faire-activité juste interrompt et nous revenons à l'état Fenêtre de mise à jour du matériel.

Les activités de faire et les activités ordinaires représentent la manifestation d'un certain comportement. La différence cruciale entre les deux est que les activités normales se déroulent « instantanément » et ne peuvent pas être interrompues par des événements normaux, alors que les activités normales peuvent durer un temps limité et être interrompues, comme le montre la figure 1. 10.3. L'instantanéité est interprétée différemment selon les systèmes ; pour les systèmes temps réel, cela peut prendre plusieurs instructions machine, et pour les logiciels de bureau, cela peut prendre plusieurs secondes.

DANS UML1 les activités ordinaires étaient désignées par le terme action(action), et le terme activité(activité) a été utilisé uniquement pour faire des activités.

Superétats

Il arrive souvent que plusieurs États aient des transitions et des activités internes communes. Dans de tels cas, ils peuvent être transformés en sous-états et le comportement global peut être transféré à un super-état, comme le montre la figure 1. 10.4. Sans super-État, il faudrait dessiner une transition Annuler(annuler) pour les trois états au sein d'un état Entrez les détails de la connexion.

États parallèles

Les États peuvent être divisés en plusieurs États parallèles fonctionnant simultanément. En figue. La figure 10.5 montre un réveil simple qui peut allumer un CD ou une radio et afficher soit l'heure actuelle, soit l'heure de l'alarme.

Les options CD/Radio et Heure actuelle/Heure de l'alarme sont parallèles. Si vous vouliez représenter cela à l'aide d'un diagramme d'états non parallèles, vous vous retrouveriez avec un diagramme désordonné lorsque vous devrez ajouter des états. Séparer les deux domaines de comportement en deux diagrammes d’état rend les choses beaucoup plus claires.

Riz. 10.5 comprend également état de la préhistoire(pseudo-état historique). Cela signifie que lorsque l'horloge est allumée, l'option radio/CD passe dans l'état dans lequel se trouvait l'horloge lorsqu'elle a été éteinte. La flèche sortant de la préhistoire montre quel état existait initialement quand il n'y avait pas de préhistoire.

Implémentation d'états-transitions

Un diagramme d'état peut être implémenté de trois manières principales : en utilisant une instruction switch imbriquée, un modèle d'état et une table d'état. L'approche la plus directe pour travailler avec des diagrammes d'états-transitions est une instruction switch imbriquée, comme dans la Fig. 10.6.

Bien que cette méthode soit simple, elle est très longue même pour ce cas simple. De plus, avec cette approche, il est très facile de perdre le contrôle, nous vous déconseillons donc de l'utiliser même dans des situations élémentaires.
Le modèle State représente une hiérarchie de classes d'état pour gérer le comportement de l'état. Chaque état d’un diagramme d’état possède sa propre sous-classe d’état. Le contrôleur dispose de méthodes pour chaque événement qui sont simplement transmises à la classe d'état. Le diagramme d'état présenté sur la Fig. 10.1 pourrait être implémenté en utilisant les classes présentées dans la Fig. 10.7.

Le sommet de la hiérarchie est une classe abstraite qui contient une description de toutes les méthodes qui traitent les événements, mais sans implémentation.
Pour chaque état spécifique, il suffit de réécrire la méthode de gestion pour un événement spécifique qui initie une transition depuis l'état.
Une table d'état représente un diagramme d'état sous forme de données.

Ainsi, le diagramme de la Fig. 10.1 peut être présenté sous forme de tableau. 10.1.
Nous construisons ensuite un interpréteur qui utilise la table d'état d'exécution ou un générateur de code qui génère des classes à partir de cette table.

Évidemment, la majeure partie du travail sur la table des États est effectuée une seule fois, mais elle peut ensuite être utilisée chaque fois qu’un problème d’État doit être résolu. La table des états d'exécution peut être modifiée sans recompilation, ce qui est plutôt pratique. Le modèle d'état est plus facile à assembler et, bien que chaque état nécessite une classe distincte, la quantité de code à écrire est assez faible.

Les implémentations présentées sont presque minimes, mais elles donnent une idée de la façon d'utiliser diagrammes d'état. Dans chaque cas, la mise en œuvre de modèles d’état aboutit à un programme plutôt stéréotypé, il est donc généralement préférable de recourir à une forme de génération de code pour y parvenir.

Abonnez-vous à l'actualité du site, vous trouverez le formulaire d'inscription dans la colonne de droite du site.

Si vous souhaitez apprendre à travailler professionnellement en tant qu'indépendant, nous vous invitons au cours « ».

Un diagramme UML est un langage de description graphique spécialisé conçu pour la modélisation objet dans le développement de divers logiciels. Le langage a un large profil et constitue un standard ouvert qui utilise diverses notations graphiques pour créer un modèle abstrait d'un système. UML a été créé pour permettre la définition, la visualisation, la documentation et la conception de toutes sortes de systèmes logiciels. Il convient de noter que le diagramme UML lui-même n'est pas un langage de programmation, mais il offre la possibilité de générer du code séparé basé sur celui-ci.

Pourquoi est-ce nécessaire ?

L’utilisation d’UML ne se limite pas à la modélisation de toutes sortes de logiciels. En outre, ce langage est activement utilisé aujourd'hui pour modéliser divers processus métier, mener la conception de systèmes et également afficher les structures organisationnelles.

Avec UML, les développeurs de logiciels peuvent fournir un accord complet dans la notation graphique utilisée pour représenter des concepts courants tels que : composant, générique, classe, comportement et agrégation. De ce fait, une plus grande concentration sur l’architecture et le design est obtenue.

Il convient également de noter qu’il existe plusieurs types de tels graphiques.

Diagramme de classes

Un diagramme de classes UML est un diagramme structurel statique conçu pour décrire la structure d'un système, ainsi que pour montrer les attributs, les méthodes et les dépendances entre plusieurs classes différentes.

Il convient de noter qu'il existe plusieurs points de vue sur la construction de tels schémas, selon la manière dont ils seront utilisés :

• Conceptuel. Dans ce cas, le diagramme de classes UML décrit le modèle d'un domaine spécifique et fournit uniquement des classes d'objets d'application.
• Spécifique. Le diagramme est utilisé dans le processus de conception de divers systèmes d'information.
• Mise en œuvre. Le diagramme de classes comprend toutes sortes de classes directement utilisées dans le code du programme.

Diagramme des composants

Un diagramme de composants UML est un diagramme de structure complètement statique. Il est destiné à démontrer la décomposition d'un système logiciel particulier en divers composants structurels, ainsi que les connexions entre eux. Un diagramme de composants UML peut utiliser toutes sortes de modèles, bibliothèques, fichiers, packages, exécutables et bien d’autres éléments en tant que tels.

Diagramme de structure composite/composite

Un diagramme de structure composite/composite UML est également un diagramme de structure statique, mais il est utilisé pour montrer la structure interne des classes. Si possible, ce diagramme peut également démontrer l'interaction d'éléments situés dans la structure interne de la classe.

Un sous-type d'entre eux est le diagramme de collaboration UML, qui est utilisé pour démontrer les rôles, ainsi que l'interaction de diverses classes dans les limites de la coopération. Ils sont très pratiques si vous avez besoin de modéliser des modèles de conception.

Il convient de noter que les vues de diagramme de classe UML et de structure composite peuvent être utilisées simultanément.

Schéma de déploiement

Ce diagramme est utilisé pour modéliser les nœuds en cours d'exécution, ainsi que toutes sortes d'artefacts qui ont été déployés sur eux. Dans UML 2, les artefacts sont déployés sur différents nœuds, alors que dans la première version, seuls les composants étaient déployés. Ainsi, le diagramme de déploiement UML est utilisé principalement pour la deuxième version.

Une dépendance de manifestation se forme entre l'artefact et le composant qu'il implémente.

Diagramme d'objets

Cette vue vous permet de voir un instantané complet ou partiel du système en cours de création à un moment donné. Il affiche entièrement toutes les instances de classes d'un système particulier, indiquant les valeurs actuelles de leurs paramètres, ainsi que les connexions entre elles.

Schéma du package

Ce diagramme est de nature structurelle et son contenu principal concerne toutes sortes de packages, ainsi que les relations entre eux. Dans ce cas, il n'y a pas de division stricte entre plusieurs schémas structurels, de sorte que leur utilisation se fait le plus souvent uniquement par commodité et n'a aucune signification sémantique. Il est à noter que différents éléments peuvent fournir d'autres diagrammes UML (exemples : les packages et les diagrammes de packages eux-mêmes).

Leur utilisation est réalisée afin d'assurer l'organisation de plusieurs éléments en groupes selon un certain critère afin de simplifier la structure, ainsi que d'organiser le travail avec le modèle d'un système donné.

Diagramme d'activité

Un diagramme d'activité UML représente la décomposition d'une activité spécifique en plusieurs composants. Dans ce cas, le concept d '«activité» est la spécification d'un certain comportement exécutable sous la forme d'une exécution séquentielle parallèle et coordonnée de divers éléments subordonnés - des types d'activités imbriqués et diverses actions, unis par des flux allant des sorties d'un certain nœud aux entrées d'un autre.

Les diagrammes d'activités UML sont souvent utilisés pour modéliser divers processus métier, calcul parallèle et séquentiel. Entre autres choses, ils simulent toutes sortes de procédures technologiques.

Schéma de la machine

Ce type est également appelé un peu différemment - diagramme d'état UML. Il présente une machine à états finis avec des états simples et composites, ainsi que des transitions.

Une machine à états est une spécification d'une séquence d'états différents par lesquels passe un certain objet, ou interaction, en réponse à certains événements de sa vie, ainsi que la réponse de l'objet à de tels événements. Une machine à états qui utilise un diagramme d'état UML est attachée à un élément source et utilisée pour définir le comportement de ses instances.

Les diagrammes dits du dragon peuvent être utilisés comme analogues de tels diagrammes.

Diagrammes de cas d'utilisation

Un diagramme de cas d'utilisation UML décrit toutes les relations qui s'établissent entre les acteurs ainsi que les différents cas d'utilisation. Sa tâche principale est de fournir un moyen à part entière grâce auquel le client, l'utilisateur final ou tout développeur peut discuter ensemble du comportement et des fonctionnalités d'un système donné.

Si un diagramme de cas d'utilisation UML est utilisé dans le processus de modélisation du système, l'analyste :

• Séparez clairement le système modélisé de son environnement.
• Identifier les acteurs, les modalités de leur interaction avec ce système, ainsi que ses fonctionnalités attendues.
• Définir dans le glossaire comme domaine divers concepts liés à une description détaillée de la fonctionnalité d'un système donné.

Si un diagramme d'utilisation est développé en UML, la procédure commence par une description textuelle, obtenue lors du travail avec le client. Il convient de noter que diverses exigences non fonctionnelles sont complètement omises lors du processus d'élaboration d'un modèle de cas d'utilisation et qu'un document séparé sera généré pour elles.

Communications

Un diagramme de communication, tout comme un diagramme de séquence UML, est transitif, c'est-à-dire qu'il exprime une interaction, mais en même temps la démontre de différentes manières et, si nécessaire, peut être converti de l'un à l'autre avec le degré de précision requis. .

Le diagramme de communication reflète les interactions qui se produisent entre les différents éléments de la structure composite, ainsi que les rôles de coopération. La principale différence entre celui-ci et un diagramme de séquence est qu'il rend les relations entre plusieurs éléments assez explicites et n'utilise pas le temps comme dimension distincte.

Ce type se distingue par un format absolument libre permettant d'agencer plusieurs objets et connexions de la même manière que dans un diagramme d'objets. S'il est nécessaire de maintenir l'ordre des messages dans ce format libre, ils sont numérotés par ordre chronologique. La lecture de ce diagramme commence par le message initial 1.0, et se poursuit ensuite dans le sens de transmission des messages d'un objet à un autre.

Pour la plupart, ces diagrammes montrent exactement les mêmes informations qu'un diagramme de séquence nous fournit, mais comme il utilise une manière différente de présenter les informations, certaines choses dans un diagramme deviennent beaucoup plus faciles à identifier que dans un autre. Il convient également de noter qu'un diagramme de communication montre plus clairement avec quels éléments chaque élément individuel interagit, tandis qu'un diagramme de séquence montre plus clairement dans quel ordre les interactions se produisent.

Diagramme de séquençage

Un diagramme de séquence UML montre les interactions entre plusieurs objets classés en fonction du moment où ils se produisent. Ce diagramme montre l'interaction chronologique entre plusieurs objets. Il affiche notamment tous les objets qui participent à l'interaction, ainsi que la séquence complète des messages échangés entre eux.

Les principaux éléments dans ce cas sont les désignations de divers objets, ainsi que des lignes verticales représentant le passage du temps et des rectangles représentant l'activité d'un certain objet ou l'exécution d'une fonction.

Diagramme de coopération

Ce type de diagramme permet de démontrer les interactions entre plusieurs objets, en faisant abstraction de la séquence de traduction des messages. Ce type de diagramme affiche sous une forme compacte absolument tous les messages transmis et reçus d'un certain objet, ainsi que les formats de ces messages.

Étant donné que les diagrammes de séquence et de communication sont simplement des vues différentes des mêmes procédures, Rational Rose offre la possibilité de créer un diagramme de communication à partir d'un diagramme de séquence ou vice versa, et de les synchroniser également de manière entièrement automatique.

Diagrammes de présentation des interactions

Il s'agit de diagrammes UML qui sont un type de diagramme d'activité et incluent à la fois des éléments de séquence et des constructions de flux de contrôle.

Il convient de noter que ce format combine Collaboration et Diagramme de séquence, qui permettent d'envisager l'interaction entre plusieurs objets du système en formation sous différents points de vue.

Chronogramme

Représente une version alternative d’un diagramme de séquence qui démontre explicitement le changement d’état le long d’une ligne de vie sur une échelle de temps spécifique. Peut être très utile dans diverses applications en temps réel.

Quels sont les avantages?

Il convient de noter plusieurs avantages qui distinguent le diagramme d'utilisation UML des autres :

• Le langage est orienté objet, de sorte que les technologies permettant de décrire les résultats de l'analyse et de la conception sont sémantiquement proches des méthodes de programmation de toutes sortes de langages modernes orientés objet.
• En utilisant ce langage, un système peut être décrit de presque tous les points de vue possibles, et divers aspects de son comportement sont décrits de la même manière.
• Tous les diagrammes sont relativement faciles à lire même après une introduction relativement rapide à leur syntaxe.
• UML vous permet d'étendre et également d'introduire vos propres stéréotypes graphiques et textuels, ce qui favorise son utilisation non seulement en génie logiciel.
• La langue est devenue assez répandue et se développe également très activement.

Défauts

Malgré le fait que la construction de diagrammes UML présente de nombreux avantages, ils sont souvent critiqués pour les inconvénients suivants :

• Redondance. Dans la grande majorité des cas, les critiques estiment qu'UML est trop volumineux et trop complexe, ce qui est souvent injustifié. Il comprend un grand nombre de conceptions et de diagrammes redondants ou pratiquement inutiles, et le plus souvent ces critiques sont dirigées contre la deuxième version, pas la première, car les révisions plus récentes contiennent davantage de compromis « conçus par un comité ».
• Diverses inexactitudes dans la sémantique. Parce qu'UML est défini par une combinaison de lui-même, de l'anglais et de l'OCL, il n'a pas la rigidité inhérente aux langages définis avec précision par des techniques de description formelle. Dans certaines situations, la syntaxe abstraite de l'OCL, de l'UML et de l'anglais commence à se contredire, tandis que dans d'autres cas, elle est incomplète. L'inexactitude dans la spécification du langage lui-même affecte à la fois les utilisateurs et les fournisseurs d'outils, conduisant finalement à une incompatibilité des outils en raison de la manière unique dont les différentes spécifications sont traitées.
• Problèmes en cours de mise en œuvre et d'étude. Tous les problèmes ci-dessus créent des défis dans la mise en œuvre et l’apprentissage d’UML, en particulier lorsque la direction oblige les ingénieurs à l’utiliser sans connaissances préalables.
• Le code reflète le code. Une autre opinion est que ce ne sont pas les modèles beaux et attrayants qui sont importants, mais les systèmes de travail eux-mêmes, c'est-à-dire que le code est le projet. Selon ce point de vue, il est nécessaire de développer une manière plus efficace d’écrire des logiciels. UML est généralement apprécié dans les approches qui compilent des modèles pour régénérer le code exécutable ou source. Mais en réalité, cela peut ne pas suffire, car le langage manque de propriétés d’exhaustivité de Turing, et chaque code généré sera finalement limité à ce que l’outil d’interprétation UML peut deviner ou déterminer.
• Incompatibilité de charge. Ce terme vient de la théorie de l'analyse des systèmes pour déterminer l'incapacité de l'entrée d'un certain système à percevoir une autre sortie. Comme toute notation standard, UML peut représenter certains systèmes de manière plus efficace et plus concise que d’autres. Ainsi, le développeur est plus enclin aux solutions qui sont plus à l'aise pour entrelacer toutes les forces d'UML, ainsi que d'autres langages de programmation. Ce problème est plus évident si le langage de développement n'est pas conforme aux principes de base de l'orthodoxie orientée objet, c'est-à-dire qu'il n'essaie pas de fonctionner conformément aux principes de la POO.
• Essaie d'être universel. UML est un langage de modélisation à usage général qui tente d'être compatible avec n'importe quel langage de traitement disponible aujourd'hui. Dans le contexte d'un projet donné, pour que l'équipe de conception atteigne l'objectif final, il est nécessaire de sélectionner les fonctionnalités applicables de ce langage. De plus, les moyens possibles de limiter la portée d'UML dans un domaine particulier passent par un formalisme qui n'est pas entièrement articulé et qui est lui-même sujet à critique.

Ainsi, l’utilisation de ce langage n’est pas pertinente dans toutes les situations.

UML (Unified Modeling Language) est un langage de description graphique pour la modélisation objet dans le domaine du développement logiciel. UML est un langage général, un standard ouvert qui utilise la notation graphique pour créer un modèle abstrait d'un système, appelé modèle UML. UML a été créé pour définir, visualiser, concevoir et documenter principalement des systèmes logiciels. UML n'est pas un langage de programmation, mais la génération de code est possible grâce aux moyens permettant d'exécuter des modèles UML sous forme de code interprété. Wikipédia

Produits commerciaux

Microsoft Visio

Type : logiciel commercial

Un logiciel populaire de Microsoft qui vous permet de dessiner des diagrammes riches, notamment UML :

Depuis la version 2010, il est devenu possible de publier des schémas sur le web (SharePoint + Visio Services) :

Visionneuse Visio est un programme gratuit qui vous permet de visualiser des diagrammes Visio créés précédemment. Vous pouvez le télécharger à %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visuel%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modélisation,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Séquence%20Diagramme%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Utilisation%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010 :

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualisation%20et%20Modélisation%20Fonction%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82 :

%0A

• %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
%0A
• %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20couche%20diagrammes%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20couche%20diagrammes
%0A

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualisation%20et%20Modélisation%20Feature%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/ru-ru/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Possibilités :

• Diagramme de cas d'utilisation ;
• Diagramme de déploiement (schémas de topologie) ;
• Diagramme d'états-transitions ;
• Diagramme d'activité;
• Diagramme d'interaction ;
• Diagramme de séquençage;
• Diagramme de collaboration ;
• Diagramme de classes ;
• Diagramme des composants.

Captures d'écran:

Programmes open source

StarUML

Possibilités :

• Prise en charge d'UML 2.0
• MDA (architecture pilotée par modèle)
• Architecture de plug-in (vous pouvez écrire dans des langages compatibles COM : C++, Delphi, C#, VB, ...)

StarUML est écrit principalement en Delphi, mais les composants peuvent également être écrits dans d'autres langages, par exemple C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Ci-dessous quelques captures d'écran.

Diagramme de classes :

Diagramme de cas d'utilisation :

ArgoUML

Graphiques pris en charge :

• Classe
• État
• Cas d'utilisation
• Activité
• Collaboration
• Déploiement
• Séquence

Possibilités :

• Prend en charge neuf diagrammes UML 1.4
• Indépendant de la plateforme (Java 5+)
• Métamodèle standard UML 1.4
• Prise en charge XMI
• Exporter vers GIF, PNG, PS, EPS, PGML et SVG
• Langues : EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
• Prise en charge du langage OCL
• Ingénierie avant et inverse

Capture d'écran:

UML est un langage de modélisation graphique à usage général permettant de spécifier, visualiser, concevoir et documenter tous les artefacts créés lors du développement de systèmes logiciels.

Il existe de nombreux bons livres qui décrivent UML en détail (parfois même de manière très détaillée), j'aimerais rassembler en un seul endroit les concepts de base sur les diagrammes, les entités et les connexions entre eux pour un rappel rapide, quelque chose comme un aide-mémoire.

Cet article utilise des éléments des livres : Ivanov D. Yu., Novikov F. A. Langage de modélisation unifié UML Et Léonenkov. Tutoriel UML.

Tout d'abord, décidons de l'éditeur. Sous Linux, j'ai essayé différents éditeurs UML, j'ai surtout aimé UMLet, bien qu'il soit écrit en Java, il se déplace très rapidement et contient la plupart des modèles d'entités. Il existe également ArgoUML, un éditeur UML multiplateforme, également écrit en Java, riche en fonctionnalités mais plus lent.

je me suis arrêté à UMLet, installez-le sous Arch Linux Et Ubuntu:

# sur Arch Linux yaourt -S umlet # sur Ubuntu sudo apt-get install umlet

En UML, toutes les entités peuvent être divisées dans les types suivants :

• de construction;
• comportemental;
• regroupement;
• annotatif;

Il existe quatre principaux types de relations utilisées dans UML :

Dépendance- indique qu'un changement dans une entité indépendante affecte d'une manière ou d'une autre une entité dépendante. Graphiquement, la relation de dépendance est représentée par une ligne pointillée avec une flèche dirigée de l'entité dépendante vers l'entité indépendante.

Association- se produit si une entité est directement liée à une autre (ou à d'autres - l'association peut être non seulement binaire). Graphiquement, une association est représentée par une ligne continue avec divers ajouts reliant les entités liées.

Généralisation est une relation entre deux entités, dont l'une est un cas particulier (spécialisé) de l'autre. Graphiquement, une généralisation est représentée par une ligne avec une flèche triangulaire non remplie à la fin, dirigée du particulier (sous-classe) au général (superclasse).

Implémentations- Une relation d'implémentation indique qu'une entité est une implémentation d'une autre. Graphiquement, la mise en œuvre est représentée par une ligne pointillée avec une flèche triangulaire non remplie à l'extrémité, dirigée de l'entité de mise en œuvre vers l'entité en cours de mise en œuvre.

DANS UML2 défini 13 types de diagrammes. Selon les normes, chaque diagramme doit avoir un cadre avec un rectangle (coin inférieur droit biseauté) dans le coin supérieur gauche, qui indique l'identifiant (tag) et le titre du diagramme.

Diagrammes pour décrire la structure d'un système:

• Diagramme des composants (balise composant);
• Schéma de déploiement, balise déploiement);
• Diagramme de classes (diagramme de classes, balise classe);
• Diagramme d'objets (balise objet);
• Diagramme de structure composite, balise classe);

Diagrammes pour décrire le comportement du système:

• Diagramme de synchronisation (diagramme d'interaction, balise Horaire);
• Diagramme d'activité (balise activité);
• Diagramme de séquence, balise Dakota du Sud);
• Schéma de communication (balise communication);
• Diagramme de machine d'état, balise machine à états);
• diagramme de présentation des interactions, balise interaction);

Les diagrammes ressortent :

• Diagramme de cas d'utilisation (diagramme de cas d'utilisation, balise de cas d'utilisation) ;
• Diagramme de package (schéma de package, balise emballer);

Schéma d'utilisation

Schéma d'utilisation(diagramme de cas d'utilisation) est la représentation la plus générale de l'objectif fonctionnel du système.

Lorsque vous considérez un diagramme de cas d'utilisation comme modèle de système, vous pouvez l'associer à un modèle de boîte noire. Chaque cas d'utilisation définit une séquence d'actions qui doivent être effectuées par le système conçu lorsqu'il interagit avec l'acteur correspondant.

Un diagramme d'utilisation utilise deux types d'entités de base : les cas d'utilisation et les acteurs, entre lesquels les types de relations de base suivants sont établis.

Relation associative- Cette relation spécifie le rôle spécifique qu'un acteur joue lorsqu'il interagit avec une instance de cas d'utilisation. Une relation d'association est indiquée par une ligne continue entre un acteur et un cas d'utilisation. Cette ligne peut comporter des symboles supplémentaires, tels qu'un nom et une multiplicité.

Relation d'expansion- définit la relation entre les instances d'un cas d'utilisation particulier et un cas d'utilisation plus général, dont les propriétés sont déterminées en fonction de la manière dont ces instances sont combinées entre elles. Ainsi, s'il existe une relation d'extension du cas d'utilisation A au cas d'utilisation B, cela signifie que les propriétés d'une instance du cas d'utilisation B peuvent être étendues en raison de la présence de propriétés dans le cas d'utilisation étendu A.

Une relation d'extension entre les cas d'utilisation est indiquée par une ligne pointillée avec une flèche (option de relation de dépendance) pointant vers le cas d'utilisation qui est une extension du cas d'utilisation d'origine.

Relation de généralisation sert à indiquer le fait qu'un cas d'utilisation A peut être généralisé au cas d'utilisation B. Dans ce cas, l'option A sera une spécialisation de l'option B. Dans ce cas, B est appelé un ancêtre ou un parent de A, et l'option A est un enfant d'option utilise V.

Graphiquement, cette relation est représentée par une ligne continue avec une flèche en forme de triangle ouvert, qui indique le cas d'utilisation parent.

Une relation de généralisation entre les cas d'utilisation est utilisée lorsqu'il est nécessaire de noter que les cas d'utilisation enfants ont tous les attributs et comportements des cas d'utilisation parents.

Relation d'inclusion entre deux cas d'utilisation indique qu'un comportement spécifié pour un cas d'utilisation est inclus en tant que composant constitutif dans la séquence de comportements de l'autre cas d'utilisation.

Une relation d'inclusion dirigée du cas d'utilisation A vers le cas d'utilisation B indique que chaque instance du cas d'utilisation A inclut les propriétés fonctionnelles spécifiées pour le cas d'utilisation B.

Graphiquement, cette relation est indiquée par une ligne pointillée avec une flèche (variante de la relation de dépendance) dirigée du cas d'utilisation de base vers celui inclus.

Diagramme de classes

Diagramme de classes(diagramme de classes) est le principal moyen de décrire la structure statique d'un système.

Un diagramme de classes utilise un type principal d'entités : les classes (comprenant de nombreux cas particuliers de classes : interfaces, types primitifs, classes d'association, etc.), entre lesquelles s'établissent les principaux types de relations suivants : dépendances, associations, généralisations, implémentations.

Relation de dépendance en général, indique une relation sémantique entre deux éléments du modèle ou deux ensembles de tels éléments, qui n'est pas une relation d'association, de généralisation ou de mise en œuvre. Une relation de dépendance est utilisée dans une situation où une modification apportée à un élément du modèle peut nécessiter une modification d'un autre élément du modèle qui en dépend.

Une relation de dépendance est représentée graphiquement par une ligne pointillée entre les éléments correspondants avec une flèche à une extrémité, la flèche pointant de la classe client de la dépendance vers la classe indépendante ou source.

Il peut y avoir des mots-clés spéciaux (stéréotypes) au-dessus de la flèche :

• "accès" - sert à indiquer la disponibilité des attributs publics et des opérations de la classe source pour les classes clientes ;
• "bind" - la classe client peut utiliser un modèle pour son paramétrage ultérieur ;
• "dériver" - ​​les attributs de la classe client peuvent être calculés à partir des attributs de la classe source ;
• "import" - les attributs publics et les opérations de la classe source deviennent une partie de la classe client, comme s'ils y étaient déclarés directement ;
• "raffiner" - indique que la classe client sert à affiner la classe source pour des raisons historiques lorsque des informations supplémentaires apparaissent au cours des travaux sur le projet.

Relation associative correspond à la présence d’une certaine relation entre les classes. Cette relation est indiquée par une ligne continue avec des symboles spéciaux supplémentaires qui caractérisent les propriétés individuelles d'une association particulière. Des caractères spéciaux supplémentaires peuvent être le nom de l'association, ainsi que les noms et multiplicités des classes de rôles de l'association. Le nom de l'association est un élément facultatif de sa désignation.

Relation d'agrégation se produit entre plusieurs classes si l’une des classes représente une entité qui inclut d’autres entités comme composants. Il est utilisé pour représenter des relations système de type « partie-tout ».

Rapport de composition est un cas particulier de relation d'agrégation. Cette relation sert à mettre en évidence une forme particulière de relation « partie-tout », dans laquelle les parties constitutives sont en quelque sorte situées au sein du tout. La spécificité de la relation entre elles réside dans le fait que les parties ne peuvent agir indépendamment du tout, c'est-à-dire qu'avec la destruction du tout, toutes ses parties constitutives sont détruites.

Relation de généralisation est une relation entre un élément plus général (parent ou ancêtre) et un élément plus spécifique ou spécialisé (enfant ou descendant). Lorsqu'elle est appliquée à un diagramme de classes, cette relation décrit la structure hiérarchique des classes et l'héritage de leurs propriétés et de leur comportement. Cela suppose que la classe descendante possède toutes les propriétés et le comportement de la classe ancêtre, et possède également ses propres propriétés et comportements que la classe ancêtre n'a pas.

Schéma de la machine

Schéma de la machine(schéma de machine d'état) ou diagramme d'état dans UML 1 (diagramme de diagramme d'état) est une façon de décrire le comportement en détail dans UML. Essentiellement, les diagrammes de machine, comme leur nom l'indique, sont un graphique d'états et de transitions d'une machine à états finis chargé de nombreux détails et détails supplémentaires.

Un diagramme d'état décrit le processus de changement d'état d'une seule classe, ou plus précisément d'une instance d'une certaine classe, c'est-à-dire qu'il modélise tous les changements possibles dans l'état d'un objet spécifique. Dans ce cas, un changement d'état d'un objet peut être provoqué par des influences externes provenant d'autres objets ou de l'extérieur. C’est pour décrire la réaction d’un objet à de telles influences extérieures que l’on utilise les diagrammes d’états.

Dans un diagramme d'automate, un type principal d'entité est utilisé - les états, et un type de relation - les transitions, mais pour les deux, de nombreuses variétés, cas particuliers et notations supplémentaires sont définis. L'automate représente les aspects dynamiques du système modélisé sous la forme d'un graphe orienté dont les sommets correspondent à des états, et les arcs à des transitions.

Etat initial est un cas particulier d'état qui ne contient aucune action interne (pseudo-état). L'objet est dans cet état par défaut au moment initial. Il sert à indiquer la zone graphique du diagramme d'état à partir de laquelle commence le processus de changement d'état.

Finale (finale) un état est un cas particulier d'état qui ne contient également aucune action interne (pseudo-états). L'objet sera dans cet état par défaut une fois que la machine aura terminé son fonctionnement au moment final.

Diagramme d'activité

Lors de la modélisation du comportement d'un système en cours de conception ou d'analyse, il devient nécessaire non seulement de présenter le processus de changement de ses états, mais également de détailler les caractéristiques de la mise en œuvre algorithmique et logique des opérations effectuées par le système.

Diagramme d'activité(diagramme d'activité) est une autre façon de décrire un comportement qui ressemble visuellement au bon vieil organigramme d'un algorithme. Utilisé pour modéliser le processus d'exécution des opérations.

L'utilisation principale des diagrammes d'activités est de visualiser les caractéristiques de mise en œuvre des opérations de classe, lorsqu'il est nécessaire de présenter des algorithmes pour leur mise en œuvre.

Un diagramme d'activités utilise un type principal d'entité - l'action, et un type de relation - les transitions (transferts de contrôle). Des constructions telles que des fourches, des fusions, des connexions et des branches sont également utilisées. Il est recommandé d'utiliser un verbe avec des mots explicatifs comme nom d'une action simple.

Diagramme de séquençage

Diagramme de séquençage(diagramme de séquence) est une manière de décrire le comportement d'un système « à l'aide d'exemples ».

En fait, un diagramme de séquence est un enregistrement du protocole d'une session spécifique du système (ou un fragment d'un tel protocole). En programmation orientée objet, la chose la plus importante à l'exécution est la transmission des messages entre les objets communicants. C'est la séquence d'envoi des messages qui est affichée dans ce schéma, d'où le nom.

Un diagramme de séquence utilise un type d'entité de base - des instances de classificateurs en interaction (principalement des classes, des composants et des acteurs) et un type de relation - des liens le long desquels les messages sont échangés.

Types de messages possibles (image tirée de larin.in) :

Schéma de communication

Schéma de communication(diagramme de communication) - une manière de décrire un comportement qui est sémantiquement équivalente à un diagramme de séquence. En fait, il s'agit de la même description de la séquence d'échange de messages d'instances en interaction de classificateurs, exprimée uniquement par d'autres moyens graphiques.

Ainsi, dans le diagramme de communication, ainsi que dans le diagramme de séquence, un type principal d'entités est utilisé - les instances de classificateurs en interaction et un type de relation - les connexions. Cependant, ici l'accent n'est pas mis sur le temps, mais sur la structure des liens entre des instances spécifiques.

Diagramme des composants

Diagramme des composants(schéma des composants) - montre les relations entre les modules (logiques ou physiques) qui composent le système modélisé.

Le principal type d'entités dans un diagramme de composants sont les composants eux-mêmes, ainsi que les interfaces par lesquelles les relations entre les composants sont spécifiées. Les relations suivantes s'appliquent dans un diagramme de composants :

• implémentations entre composants et interfaces (un composant implémente une interface) ;
• dépendances entre composants et interfaces (le composant utilise l'interface) ;

Diagramme de placement

Diagramme de placement(schéma de déploiement), en plus d'afficher la composition et les connexions des éléments du système, montre comment ils sont physiquement situés sur les ressources informatiques au moment de l'exécution.

Un diagramme de présentation, comparé à un diagramme de composants, ajoute deux types d'entités : un artefact, qui est une implémentation d'un composant et d'un nœud (peut être soit un classificateur décrivant le type de nœud, soit une instance spécifique) et une relation d'association. entre les nœuds, indiquant que les nœuds sont physiquement connectés pendant l'exécution.

Diagramme d'objets

Diagramme d'objets(diagramme d'objets) - est une instance d'un diagramme de classes.

Un diagramme d'objets utilise un type principal d'entités : les objets (instances de classes), entre lesquels sont indiquées des connexions spécifiques (le plus souvent des instances d'associations). Les diagrammes d'objets sont de nature auxiliaire - en fait, ce sont des exemples (vidages de mémoire, pourrait-on dire) montrant quels objets sont disponibles et les connexions entre eux à un moment donné du fonctionnement du système.

Schéma de structure interne(diagramme de structure composite) est utilisé pour une représentation plus détaillée des classificateurs structurels, principalement des classes et des composants.

Un classificateur structurel est représenté par un rectangle avec le nom du classificateur en haut. Il y a des pièces à l'intérieur. Il peut y avoir plusieurs parties. Les pièces peuvent interagir les unes avec les autres. Ceci est indiqué à l'aide de connecteurs de différents types. L'emplacement sur la limite extérieure de la pièce à laquelle le connecteur se fixe est appelé port. Les ports sont également situés sur la limite extérieure du classificateur structurel.

Diagramme de présentation des interactions Un diagramme de synthèse d'interaction est un type de diagramme d'activités avec une syntaxe étendue : les éléments d'un diagramme de synthèse d'interaction peuvent être des liens vers des usages d'interaction définis par des diagrammes de séquence.

Chronogramme

Chronogramme Le chronogramme est une forme spéciale de diagramme de séquence qui se concentre sur les états changeants de différentes instances de classificateur et leur synchronisation temporelle.

Schéma du package

Schéma du package(schéma du package) est le seul outil qui permet de gérer la complexité du modèle lui-même.

Les principaux éléments de notation sont des packages et des dépendances avec divers stéréotypes.

Modèle entité-relation (modèle ER)

Analogue diagrammes de classes(UML) peut-être Modèle ER, qui est utilisé lors de la conception de bases de données (modèle relationnel).

Le modèle entité-relation (modèle ER) est un modèle de données qui vous permet de décrire des diagrammes conceptuels d'un domaine. Le modèle ER est utilisé dans la conception de bases de données (conceptuelles) de haut niveau. Avec son aide, vous pouvez identifier les entités clés et identifier les connexions qui peuvent être établies entre ces entités. Wikipédia

Tout fragment d'un domaine peut être représenté comme un ensemble d'entités entre lesquelles il existe un certain nombre de connexions.

Concepts de base:

Essence(entité) est un objet qui peut être identifié d'une manière qui le distingue des autres objets, par exemple : CLIENT 777. Une entité est en réalité un ensemble d’attributs.

Ensemble d'entités(ensemble d'entités) - un ensemble d'entités du même type (ayant les mêmes propriétés).

Connexion(relation) est une association établie entre plusieurs entités.

Domaine(domaine) - ensemble de valeurs (domaine de définition) de l'attribut.

Il existe trois types de liaisons binaires :

• Un par un- une seule instance d'une entité d'une classe est associée à une seule instance d'une entité d'une autre classe, par exemple, HEAD - DEPARTMENT ;
• 1 à N ou un à plusieurs- une seule instance d'une entité d'une classe est associée à plusieurs instances d'une entité d'une autre classe, par exemple, DÉPARTEMENT - EMPLOYÉ ;
• N à M ou plusieurs à plusieurs- de nombreuses instances d'une entité d'une classe sont associées à de nombreuses instances d'une entité d'une autre classe, par exemple, EMPLOYÉ - PROJET ;
Dictionnaire des concepts de base en UML

Objet- une entité unique qui encapsule l'état et le comportement.

Classe- description d'un ensemble d'objets avec des attributs communs qui définissent l'état et des opérations qui définissent le comportement.

Interface- un ensemble nommé d'opérations qui définit un ensemble de services pouvant être demandés par un consommateur et fournis par un fournisseur de services.

Coopération- un ensemble d'objets qui interagissent pour atteindre un objectif.

Acteur- une entité située en dehors du système modélisé et interagissant directement avec lui.

Composant- une partie modulaire du système avec un ensemble clairement défini d'interfaces requises et fournies.

Artefact- un élément d'information utilisé ou généré au cours du processus de développement logiciel. En d’autres termes, un artefact est une unité physique d’implémentation dérivée d’un élément de modèle (tel qu’une classe ou un composant).

Nœud- une ressource informatique sur laquelle sont localisés et, si nécessaire, exécutés les artefacts.

Les entités comportementales sont destinées à décrire un comportement. Il n’existe que deux entités comportementales principales : l’état et l’action.

État- une période du cycle de vie d'un objet, pendant laquelle l'objet satisfait à une certaine condition et exerce ses propres activités ou attend l'apparition d'un événement.

Action- calcul atomique primitif.

Machine est un package qui définit de nombreux concepts nécessaires pour représenter le comportement de l'entité modélisée sous la forme d'un espace discret avec un nombre fini d'états et de transitions.

Classificateur est un descripteur d'un ensemble d'objets du même type.

Lecture supplémentaire

• Fowler M.UML. Fondamentaux, 3e édition
• Buch G., Rambo D., Jacobson I. Langage UML. Mode d'emploi