Comment faire un diagramme uml. Caractéristiques générales du langage UML

UML (Unified Modeling Language - langage de modélisation unifié) - un langage de description graphique pour la modélisation d'objets dans le domaine du développement de logiciels. UML est un langage général, c'est 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 dans les outils d'exécution de modèles UML sous forme de code interprété. Wikipédia

Produits commerciaux

Microsoft Visio

Type : logiciel commercial

Populaire Logiciel de Microsoft, qui permet de dessiner des diagrammes riches, notamment UML :

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

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

%0A

Microsoft%20Visual%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%20cas%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%20Visuel%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%20Fonctionnalité%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
%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
%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
%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
%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
%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

%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/en-us/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Opportunités:

Diagramme de cas d'utilisation (diagrammes de précédents);
Diagramme de déploiement (diagrammes de topologie);
Diagramme d'états (diagrammes d'états);
Diagramme d'activité (diagrammes d'activité);
Diagramme d'interaction (diagrammes d'interaction);
Diagramme de séquence (schémas de séquences d'actions) ;
Diagramme de collaboration (diagrammes de collaboration);
Diagramme de classes (diagrammes de classes);
Diagramme de composants (schémas de composants).

Captures d'écran:

programmes open source

StarUML

Opportunités:

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

StarUML est écrit principalement en Delphi, mais vous pouvez ajouter des composants dans d'autres langages, tels que C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Ci-dessous quelques captures d'écran.

Diagramme de classe :

Diagramme de cas d'utilisation :

ArgoUML

Graphiques pris en charge :

classer
État
cas d'utilisation
Activité
Collaboration
Déploiement
Séquence

Opportunités:

Prise en charge de 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 d'OCL
Ingénierie directe, rétro-ingénierie

Capture d'écran:

Modèle UML(modèle UML) est un ensemble d'un ensemble fini de constructions de langage, dont les principales sont des entités et des relations entre elles.

Les entités et les relations du modèle elles-mêmes sont des instances des métaclasses du métamodèle.

Considérant le modèle UML à partir des positions les plus générales, on peut dire qu'il s'agit d'un graphe (plus précisément, un multi-pseudo-hyper-digraphe chargé), dans lequel les sommets et les arêtes sont chargés d'informations supplémentaires et peuvent avoir une structure interne complexe . Les sommets de ce graphe sont appelés entités et les arêtes sont appelées relations.. Le reste de la section fournit un aperçu rapide (préliminaire) mais complet des types d'entités et des relations disponibles. Heureusement, ils ne sont pas trop nombreux. Dans les chapitres suivants du livre, toutes les entités et relations sont à nouveau examinées, plus en détail et avec des exemples.

1.4.1. Essences

Pour faciliter la vue d'ensemble, les entités dans l'UML peuvent être divisées en quatre groupes :

de construction;
comportemental ;
regroupement;
annotatif.

Les entités structurelles, comme vous pouvez le deviner, sont destinées à décrire la structure. En règle générale, les entités structurelles incluent les éléments suivants.

Un objet(objet) 1 est une entité qui a un caractère unique et encapsule l'état et le comportement.

Classer(classe) 2 - description d'un ensemble d'objets avec des attributs communs qui définissent l'état et les opérations qui définissent le comportement.

Interface(interface) 3 est un ensemble nommé d'opérations qui définit un ensemble de services qui peuvent être demandés par le consommateur et fournis par le fournisseur de services.

La coopération(collaboration) 4 - un ensemble d'objets qui interagissent pour atteindre un objectif.

Acteur(acteur) 5 est une entité extérieure au système modélisé et interagit directement avec lui.

∇ Une telle relation existe certainement, ce qui est exprimé dans la Fig. Hiérarchie des types de diagramme pour UML 1 comme une relation de dépendance avec le stéréotype "affiner".

∇∇ Dans UML 1, il y avait une association involontaire entre un diagramme de collaboration et une entité du même nom, ce qui n'était pas tout à fait vrai et parfois trompeur.

∇∇∇ En UML 2, la charge syntaxique et sémantique du diagramme d'état a tellement changé que le nom ne reflète plus le contenu.

Une liste de nouveaux diagrammes et leurs noms adoptés dans ce livre est donnée ci-dessous.

Diagramme de structure composite
Schéma de l'emballage
Diagramme de machine d'état
Schéma de communication
Diagramme de présentation des interactions
Chronogramme

Sur la fig. Hiérarchie des types de diagramme pour UML 2 (parties 1 et 2) un diagramme de classes montrant la relation entre les diagrammes dans UML 2.

Plus loin dans ce chapitre, nous décrirons très brièvement les treize diagrammes canoniques afin d'avoir un contexte et un vocabulaire pour ce qui suit. Les détails sont exposés dans les chapitres restants du livre.

Mais avant de passer à la section suivante, faisons une petite digression sur la façon dont la norme exige que les graphiques soient formatés. Le modèle général de présentation graphique est donné ci-dessous.

Il y a deux principaux éléments de conception : un cadre extérieur et une étiquette avec le nom du graphique. Si tout est simple avec le cadre - c'est un rectangle qui délimite la zone dans laquelle les éléments du diagramme doivent être situés, alors le nom du diagramme est écrit dans un format spécial illustré à la Fig. Notation graphique.

Cette forme d'onglet complexe n'est pas prise en charge par tous les outils. Cependant, ce n'est pas nécessaire, puisque la sémantique est primaire, et la notation est secondaire. Dans ce qui suit, nous utilisons un rectangle comme étiquette de graphique tout au long, et cela ne devrait pas provoquer de malentendu.

Les balises (types) possibles pour les graphiques sont présentées dans le tableau suivant. Les balises proposées par la norme sont écrites dans la deuxième colonne. Cependant, comme l'a montré la pratique, les règles proposées par la norme ne sont pas toujours pratiques et logiquement justifiées, c'est pourquoi la troisième colonne du tableau contient une alternative raisonnable à notre avis.

Languette. Types de graphiques et balises

Nom du graphique	Balise (standard)	Tag (suggéré)
Diagramme d'utilisation	cas d'utilisation ou alors uc	cas d'utilisation
diagramme de classe	classer	classer
diagramme d'automate	machine d'état ou alors stm	machine d'état
Diagramme d'activité	activité ou alors loi	activité
diagramme de séquençage	interaction ou alors Dakota du Sud	Dakota du Sud
Diagramme de communication	interaction ou alors Dakota du Sud	communication
Diagramme des composants	composant ou alors cmp	composant
Diagramme d'emplacement	indéfini	déploiement
Diagramme d'objets	indéfini	chose
Schéma de la structure interne	classer	classer ou alors composant
Diagramme de présentation des interactions	interaction ou alors Dakota du Sud	interaction
Chronogramme	interaction ou alors Dakota du Sud	Horaire
Schéma de l'emballage	forfait ou alors paquet	forfait

Je pense que tout le monde a entendu dans son enfance un dicton tel que " Mesurer sept fois, couper une fois". En programmation, c'est pareil. C'est toujours mieux de penser à l'implémentation avant de passer du temps à l'exécuter. Souvent il faut créer des classes pendant l'implémentation, inventer leur interaction. Et souvent une représentation visuelle de cela peut aider à résoudre le problème de la manière la plus correcte. C'est là que nous aidons UML.

Qu'est-ce qu'UML ?

Si vous regardez les images dans moteurs de recherche, il devient clair que UML- il s'agit de schémas, de flèches et de carrés. Ce qui est important, c'est qu'UML se traduit par Langage de modélisation unifié. Le mot Unifié est important ici. Autrement dit, nos images seront comprises non seulement par nous, mais aussi par d'autres qui connaissent UML. Il s'avère que c'est un tel langage international pour dessiner des diagrammes.

Comme le dit Wikipédia

UML est un langage de description graphique pour la modélisation d'objets dans le développement de logiciels, la modélisation de processus métier, ingénierie des systèmes et la cartographie des structures organisationnelles.

La chose la plus intéressante à laquelle tout le monde ne pense pas ou ne devine pas est qu'UML a des spécifications. De plus, il existe même une spécification UML2. Vous trouverez plus d'informations sur la spécification sur le site Web d'Object Management Group. En fait, ce groupe est engagé dans le développement de spécifications UML. Il est également intéressant de noter qu'UML ne se limite pas à décrire la structure des classes. Il existe de nombreux types de diagrammes UML. Une brève description des types de diagrammes UML peut être vue dans le même Wikipedia: diagrammes UML ou dans la vidéo de Timur Batyrshinov Présentation des diagrammes UML. UML est également largement utilisé pour décrire divers processus, par exemple ici : Single sign-on using JWT. Revenant à l'utilisation des diagrammes de classes UML, il convient de noter le livre Head First: Design Patterns, dans lequel les modèles sont illustrés par ces mêmes diagrammes UML. Il s'avère que l'UML est effectivement utilisé. Et il s'avère que connaître et comprendre son application est une compétence très utile.

Application

Voyons comment vous pouvez travailler avec ce très UML de l'IDE. En tant qu'IDE, prenez Idée IntelliJ . Si utiliser IntelliJ Idea Ultime, alors nous aurons le plugin installé "prêt à l'emploi" Prise en charge UML". Il vous permet de générer automatiquement de beaux diagrammes de classes. Par exemple, via Ctrl + N ou l'élément de menu "Naviguer" -> "Classe" accédez à la classe Liste des tableaux. Maintenant, via le menu contextuel par le nom de la classe, sélectionnez "Diagramme" -> "Afficher la fenêtre contextuelle du diagramme". En conséquence, nous obtenons un beau graphique:

Mais que se passe-t-il si vous voulez vous dessiner, et même s'il n'y a pas de version Ultimate d'Idea ? Si nous utilisons IntelliJ Idea Community Edition, nous n'avons pas d'autre choix. Pour ce faire, vous devez comprendre le fonctionnement d'un tel schéma UML. Nous devons d'abord installer Graphviz . Il s'agit d'un ensemble d'utilitaires de visualisation de graphes. Il est utilisé par le plugin que nous allons utiliser. Après l'installation, vous devez ajouter un répertoire poubelle depuis le répertoire installé graphvizà une variable d'environnement CHEMIN. Après cela, dans IntelliJ Idea, sélectionnez Fichier -> Paramètres dans le menu. Dans la fenêtre "Paramètres", sélectionnez la catégorie "Plugins", cliquez sur le bouton "Parcourir les référentiels" et installez le plugin d'intégration PlantUML. Pourquoi celui-ci est-il si bon UsineUML? Il utilise un langage de description de graphe appelé " point" et cela lui permet d'être plus universel, puisque ce langage n'est pas utilisé que par PlantUML. De plus, on peut faire tout ce qu'on fait plus bas non seulement dans l'IDE, mais aussi dans un service en ligne planttext.com. Après avoir installé le plugin PlantUML, nous pourrons créer des diagrammes UML via "Fichier" -> "Nouveau". Créons un diagramme "Classe UML". Pendant ce temps, un modèle avec un exemple est automatiquement généré. Supprimons son contenu et créons le nôtre, armé d'un article de Habr : Class Relations - from UML to code. Et pour comprendre comment décrire cela dans le texte, prenons le manuel PlantUML : plantuml class-diagram . Dans celui-ci, au tout début, il y a une plaque avec comment décrire les connexions :

Concernant les connexions elles-mêmes, on peut encore jeter un coup d'œil ici : "Relations entre classes dans UML. Exemples". Sur la base de ces matériaux, commençons à créer notre diagramme UML. Ajoutez le contenu suivant décrivant les deux classes : @startuml class ArrayList ( ) class LinkedList ( ) @enduml Pour voir le résultat dans Idea, sélectionnez "View" -> " Fenêtres d'outils" -> "PlantUML". Nous obtenons juste deux carrés représentant des classes. Comme nous le savons, ces deux classes implémentent l'interface List. Cette relation les classes sont appelées - mise en œuvre (réalisation). Une flèche avec une ligne pointillée est utilisée pour décrire une telle relation. Dessinons-le : interface Liste Liste< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о forfait privé tableau d'éléments : ~ Object elementData Maintenant, nous voulons montrer que ArrayList contient des objets. Dans ce cas, le type de connexion sera - agrégation(agrégation). L'agrégat dans ce cas est ArrayList , car il contient d'autres objets. Nous choisissons l'agrégation car les objets de la liste peuvent vivre sans la liste : ils n'en font pas partie intégrante. Leur durée de vie n'est pas liée à la durée de vie de la liste. L'unité du latin est traduite par "collecté", c'est-à-dire quelque chose composé de quelque chose. Par exemple, dans la vie, il y a une unité de pompage, qui se compose d'une pompe et d'un moteur. L'unité elle-même peut être démontée, en laissant quelque chose parties constitutives. Par exemple, pour vendre ou mettre dans une autre unité. Il est donc sur la liste. Et cela s'exprime sous la forme d'un losange vide à l'unité et d'un trait continu. Disons-le de cette façon : class Object ( ) ArrayList o- Object Maintenant, nous voulons montrer que, contrairement à ArrayList , la classe LinkedList contient des Node - conteneurs qui font référence à des données stockées. Dans ce cas, les nœuds font partie de la LinkedList elle-même et ne peuvent pas vivre séparément. Node n'est pas un contenu directement stocké, mais contient uniquement une référence à celui-ci. Par exemple, lorsque nous ajoutons une ligne à la LinkedList, nous ajoutons un nouveau Node qui contient un lien vers cette ligne, ainsi qu'un lien vers le Node précédent et suivant. Ce type de connexion est appelé composition(composition). Pour afficher un composite (celui qui se compose de parties), un robic rempli est dessiné, une ligne continue y mène. Maintenant, écrivons ceci comme un affichage textuel du lien : class Node ( ) LinkedList * -- Node Et maintenant, nous devons apprendre à afficher un autre type de lien important - dépendance(relation de dépendance). Il est utilisé lorsqu'une classe en utilise une autre, alors que la classe ne contient pas la classe utilisée et n'est pas son successeur. Par exemple, LinkedList et ArrayList peuvent créer un ListIterator . Affichons cela sous forme de flèches en pointillés : class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Vous pouvez détailler autant que vous le souhaitez. Toutes les désignations sont listées ici : "PlantUML - Class Diagram". De plus, il n'y a rien de surnaturel à dessiner un tel schéma, et lorsque vous travaillez sur vos tâches, vous pouvez rapidement le dessiner à la main. Cela développera les compétences nécessaires pour réfléchir à l'architecture de l'application et aidera à identifier les défauts de structure de classe dès le début, et non après avoir déjà passé une journée à implémenter le mauvais modèle. Je pense que c'est une bonne raison pour essayer ?)

Automatisation

Il existe différentes manières de générer automatiquement des diagrammes PlantUML. Par exemple, dans des idées Il existe un plugin SketchIT, mais il ne les dessine pas correctement. Par exemple, l'implémentation des interfaces est dessinée de manière incorrecte (affichée comme héritage). Il existe également des exemples en ligne sur la façon d'intégrer cela dans le cycle de vie de la construction de votre projet. disons pour Maven il existe un exemple utilisant uml-java-docklet . Pour montrer comment cela se fait, utilisons l'archétype Maven pour créer rapidement un projet Maven. Exécutons la commande : mvn archetype:generate Sur la question du choix d'un filtre ( Choisissez un nombre ou appliquez un filtre) laissez par défaut en appuyant simplement sur Entrée. Ce sera toujours" maven-archetype-quickstart". Nous sélectionnons la dernière version. Ensuite, répondez aux questions et terminez la création du projet :

Étant donné que Maven n'est pas l'objet de cet article, les réponses à vos questions sur Maven se trouvent dans le Maven Users Center . Dans le projet généré, ouvrez le fichier de description du projet pour l'éditer, pom.xml. Nous y copierons le contenu de la description de l'installation de uml-java-docklet. L'artefact utilisé dans la description est introuvable dans le référentiel Maven Central. Mais cela a fonctionné pour moi avec ceci : https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . Autrement dit, dans cette description, il vous suffit de remplacer identifiant de groupe Avec " info.leadinglight" au " com.chfourie" et mettre la version " 1.0.0 ". Après cela, nous pouvons exécuter dans le répertoire où se trouve le fichier pom.xml ces commandes sont : mvn clean install et mvn javadoc:javadoc . Maintenant, si nous ouvrons la documentation générée (cible de l'explorateur\site\apidocs\index.html), nous verrons les diagrammes UML. Au fait, l'implémentation est déjà affichée correctement ici)

Conclusion

Comme vous pouvez le voir, UML vous permet de visualiser la structure de votre application. De plus, UML ne se limite pas à cela. Avec l'aide d'UML, vous pouvez décrire différents processus au sein de votre entreprise ou décrire le processus métier dans lequel la fonction que vous écrivez fonctionne. C'est à vous de décider dans quelle mesure UML vous est utile personnellement, mais il sera utile de trouver le temps et de le connaître plus en détail de toute façon. #Viacheslav Version russe de cet article : Diagramme UML Java sur CodeGym

UML est l'acronyme de Unified Modeling Language. En fait, il s'agit de l'une des techniques de modélisation des processus métier les plus populaires et d'une notation standard internationale pour spécifier, visualiser et documenter le développement de logiciels. Défini par le groupe de gestion d'objets, apparu à la suite de plusieurs systèmes supplémentaires Notation UML et est maintenant devenue la norme de facto pour la modélisation visuelle. Le principe fondateur de toute programmation orientée objet commence par la construction de modèles.

L'UML a été créé à partir du chaos autour du développement et de la documentation des logiciels. Dans les années 1990, il y avait plusieurs différentes manières représentations des systèmes logiciels. Il y avait un besoin pour une manière UML visuelle plus unifiée de représenter ces systèmes, et par conséquent, elle a été développée en 1994-1996 par trois ingénieurs en logiciel travaillant chez Rational Software. Il a ensuite été adopté comme norme en 1997 et l'est resté à ce jour avec seulement quelques mises à jour.

Fondamentalement, UML est un langage de modélisation usage général dans le domaine du développement logiciel. Cependant, il a maintenant trouvé sa place dans la documentation de plusieurs processus métier ou workflows, tels que les diagrammes d'activité. Le type de diagramme UML peut être utilisé en remplacement des organigrammes. Ils offrent à la fois un moyen plus standardisé de modéliser les flux de travail et un large éventail de fonctionnalités pour améliorer la lisibilité et l'efficacité.

L'architecture est basée sur un méta-objet, qui définit la base pour la création du langage UML. Il est suffisamment précis pour créer une application entière. Un UML entièrement exécutable peut être déployé sur plusieurs plates-formes à l'aide de différentes technologies avec tous les processus tout au long du cycle de développement logiciel.

UML est conçu pour que les utilisateurs développent un langage de modélisation visuel. Il prend en charge des concepts de développement de haut niveau tels que les structures, les modèles et les collaborations. UML est une collection d'éléments tels que :

Déclarations en langage de programmation.
Les acteurs décrivent le rôle joué par l'utilisateur ou tout autre système qui interagit avec l'objet.
Les activités à réaliser pour l'exécution du contrat de travail et à présenter sous forme de schémas.
Un processus métier qui comprend un ensemble de tâches qui créent un service spécifique pour les clients, visualisé par un organigramme d'actions séquentielles.
Composants logiciels logiques et réutilisables.

Les diagrammes UML se divisent en deux catégories. Le premier type comprend sept types de diagrammes représentant des informations structurelles, le second - les sept autres représentant des types généraux de comportement. Ces diagrammes servent à documenter l'architecture des systèmes et interviennent directement dans la modélisation UML du système.

Les diagrammes UML sont présentés comme des représentations statiques et dynamiques du modèle de système. La vue statique comprend des diagrammes de classe et de structure composite qui mettent l'accent sur la structure statique. La vue dynamique représente l'interaction entre les objets et les modifications des états internes des objets à l'aide de diagrammes de séquence, d'activité et d'état.

Une grande variété d'outils de modélisation UML sont disponibles pour simplifier la modélisation, notamment IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner et Dia.

L'utilisation d'UML prend différentes formes tant dans la documentation de développement logiciel que dans les processus métier :

Esquisser. Dans ce cas, les diagrammes UML sont utilisés pour transmettre divers aspects et caractéristiques d'un système. Cependant, il ne s'agit que d'une vue de haut niveau du système et n'inclura probablement pas tous les détails nécessaires pour mener le projet jusqu'au bout.
Forward Design - La conception de l'esquisse est effectuée avant le codage de l'application. Ceci est fait pour une meilleure vue d'ensemble du système ou du flux de travail que l'utilisateur essaie de créer. De nombreux problèmes ou lacunes de conception peuvent être identifiés, ce qui améliorera la santé et le bien-être général du projet.
Conception inversée. Une fois le code écrit, les diagrammes UML apparaissent comme une forme de documentation pour diverses activités, rôles, contributeurs et flux de travail.
Plan. Dans ce cas, le diagramme sert de construction complète qui ne nécessite que la mise en œuvre réelle du système ou du logiciel. Cela se fait souvent à l'aide des outils CASE (Computer Aided Software Engineering Tools). Le principal inconvénient de l'utilisation des outils CASE est qu'ils nécessitent un certain niveau de connaissances, de formation des utilisateurs, de gestion et de personnel.

UML n'est pas un langage de programmation autonome comme Java, C++ ou Python, cependant, avec les bons outils, il peut se transformer en un pseudo-langage de programmation UML. Pour atteindre cet objectif, l'ensemble du système doit être documenté dans différents diagrammes, et en utilisant le bon logiciel, les diagrammes peuvent être directement traduits en code. Cette méthode ne peut être utile que si le temps passé à dessiner les diagrammes prend moins de temps qu'à écrire le code proprement dit. Même si UML a été créé pour la modélisation de systèmes, il a trouvé plusieurs utilisations dans les domaines commerciaux.

Voici un exemple de diagramme UML pour la modélisation métier.

Une solution pratique serait de représenter visuellement le déroulement du processus de télévente à travers un diagramme d'activité. À partir du moment où la commande est prise en entrée, jusqu'au moment où la commande est terminée et qu'une sortie spécifique est donnée.

Il existe plusieurs types de diagrammes UML, et chacun d'eux effectue une tâche différente, qu'il soit développé avant l'implémentation ou après, dans le cadre de la documentation. Les deux catégories les plus larges couvrant tous les autres types sont le diagramme de comportement et le diagramme de structure. Comme leur nom l'indique, certains diagrammes UML tentent d'analyser et de décrire la structure d'un système ou d'un processus, tandis que d'autres décrivent le comportement du système, de ses participants et de ses composants.

Les différents types se répartissent comme suit :

Les 14 différents types de diagrammes UML ne sont pas tous utilisés régulièrement lors de la documentation de systèmes et d'architectures.
Le principe de Pareto s'applique également à l'utilisation des diagrammes UML.
20% des diagrammes sont utilisés par les développeurs 80% du temps.

Les éléments les plus couramment utilisés dans le développement de logiciels sont :

schémas d'utilisation ;
diagrammes de classes ;
séquences.

Diagrammes d'activités - Les diagrammes UML les plus importants pour créer des modèles de processus métier. Dans le développement de logiciels, ils sont utilisés pour décrire le flux de diverses activités. Ils peuvent être en série ou en parallèle. Ils décrivent les objets utilisés, consommés ou produits par une activité et les relations entre différentes activités.

Tout ce qui précède est essentiel pour modéliser les processus métier qui mènent de l'un à l'autre, car ils sont interconnectés avec un début et une fin clairs. Dans un environnement commercial, cela est également appelé cartographie des processus métier. Les principaux acteurs sont l'auteur, l'éditeur et l'éditeur. Un exemple d'UML est le suivant. Lorsqu'un examinateur examine un projet et décide que certaines modifications doivent être apportées. L'auteur examine ensuite le brouillon et le renvoie à nouveau pour analyser l'examen.

Diagramme d'utilisation

La pierre angulaire du système - utilisé pour analyser les exigences pour le niveau du système. Ces exigences sont exprimées en différentes options utiliser. Les trois principaux composants d'un diagramme UML sont :

Fonctionnel - présenté sous forme de cas d'utilisation.
Verbe qui décrit une action.
Acteurs - pour interagir avec le système. Les acteurs peuvent être des utilisateurs, des organisations ou une réclamation externe. Les relations entre les participants sont représentées par des flèches droites.

Par exemple, pour le schéma de gestion des stocks. Dans ce cas, il y a un propriétaire, un fournisseur, un gestionnaire, un spécialiste de l'inventaire et un inspecteur de l'inventaire. Les conteneurs ronds représentent les actions que les acteurs effectuent. Actions possibles : acheter et payer des actions, vérifier la qualité des actions, restituer des actions ou distribuer des actions.

Ce type de diagramme est bien adapté pour montrer le comportement dynamique entre les participants d'un système, ce qui le rend plus facile à représenter sans montrer les détails de mise en œuvre.

Temporaire

Les chronogrammes UML sont utilisés pour représenter les relations d'objet lorsque le focus dépend du temps. Dans ce cas, il n'est pas intéressant de savoir comment les objets interagissent ou se modifient, mais l'utilisateur veut imaginer comment les objets et les sujets agissent le long d'un axe de temps linéaire.

Chaque participant individuel est représenté par une ligne de vie, qui est essentiellement une ligne formant des étapes lorsqu'un participant individuel passe d'une étape à une autre. L'attention principale est portée sur la durée du temps des événements et les changements qui se produisent en fonction de celui-ci.

Les principaux composants d'un chronogramme sont :

Lifeline est un membre individuel.
Chronologie des états - le seul chemin de vie peut passer par différents états au sein d'un processus.
Contrainte de durée - une contrainte d'intervalle de temps qui représente la durée de la contrainte à remplir.
Limite de temps - Limitation de l'intervalle de temps pendant lequel quelque chose doit être exécuté par un participant.
Destruction Emergence - L'apparition d'un message qui détruit un membre individuel et décrit la fin du cycle de vie de ce membre.

Les diagrammes horizontaux, également appelés diagrammes d'états, sont utilisés pour décrire les différents états d'un composant au sein d'un système. Il prend le format de nom final car le diagramme est essentiellement une machine qui décrit les multiples états d'un objet et comment il change en fonction d'événements internes et externes.

Un diagramme d'état de machine très simple serait dans un jeu d'échecs. Une partie d'échecs typique se compose de mouvements effectués par les blancs et de mouvements effectués par les noirs. Les blancs ont le premier coup, initiant ainsi la partie. La fin de la partie peut avoir lieu indépendamment du fait que Blanc ou Noir gagne. Le jeu peut se terminer par un match, une démission ou un match nul (différents états de la voiture). Les diagrammes d'états sont principalement utilisés dans la conception UML directe et inverse de divers systèmes.

Séquentiel

Ce type de diagramme est le diagramme UML le plus important non seulement parmi la communauté informatique, mais aussi en tant que modèles de conception pour le développement d'applications métier. Ils sont populaires pour décrire les processus métier en raison de leur nature visuellement explicite. Comme son nom l'indique, les diagrammes décrivent la séquence de messages et d'interactions qui ont lieu entre les sujets et les objets. Les acteurs ou les objets ne peuvent être actifs que lorsque cela est nécessaire ou lorsqu'un autre objet souhaite communiquer avec eux. Toutes les communications sont présentées par ordre chronologique.

Pour plus d'informations, veuillez consulter l'exemple de diagramme de séquence UML ci-dessous.

Comme il ressort de l'exemple, des diagrammes structurels sont utilisés pour montrer la structure d'un système. Plus précisément, le langage est utilisé dans le développement de logiciels pour représenter l'architecture d'un système et la façon dont les différents composants sont liés.

Le diagramme de classes UML est le type de diagramme le plus courant pour la documentation des logiciels. Étant donné que la plupart des logiciels créés aujourd'hui sont toujours basés sur le paradigme de la programmation orientée objet, l'utilisation de diagrammes de classes pour documenter les logiciels relève du bon sens. En effet, la POO est basée sur les classes UML et les relations entre elles. En un mot, les graphiques contiennent des classes, ainsi que leurs attributs, également appelés champs de données, et leurs comportements, appelés fonctions membres.

Plus précisément, chaque classe comporte 3 champs : nom en haut, attributs juste en dessous du nom, opérations/comportement en bas. La relation entre les différentes classes (représentées par une ligne de connexion) constitue un diagramme de classes. L'exemple ci-dessus montre un diagramme de classes de base.

Objets

Lorsque vous discutez des diagrammes de structure UML, vous devez approfondir les concepts liés à l'informatique. En génie logiciel, les classes sont considérées comme des types de données abstraits tandis que les objets sont des instances. Par exemple, s'il y a "Car" qui est un type abstrait générique, alors l'instance de la classe "Car" serait "Audi".

Les diagrammes d'objets UML aident les développeurs de logiciels à vérifier si la structure abstraite générée est une structure viable lorsqu'elle est implémentée dans la pratique, c'est-à-dire lorsque les objets sont créés. Certains développeurs considèrent cela comme un niveau secondaire de vérification de la précision. Il affiche les instances de classe. Plus précisément, la classe générique "Client" a maintenant un vrai client, par exemple nommé "James". James est une instance d'une classe plus générale et a les mêmes attributs, cependant, avec des valeurs données. La même chose a été faite avec Compte"Comptes et Epargne". Ils sont tous deux des objets de leurs classes respectives.

Déploiements

Les diagrammes de déploiement sont utilisés pour visualiser la relation entre le logiciel et le matériel. Pour être plus précis, avec les diagrammes de déploiement, il est possible de construire un modèle physique de la façon dont les composants logiciels (artefacts) sont déployés sur des composants matériels appelés nœuds.

Un schéma de déploiement simplifié typique pour une application Web comprendrait :

Noeuds (serveur d'application et serveur de base de données).
Diagramme des artefacts de l'application cliente et de la base de données.

Le diagramme de package est similaire aux macros des diagrammes UML de déploiement que nous avons expliqués ci-dessus. Divers packages contiennent des nœuds et des artefacts. Ils regroupent les diagrammes et les composants de modèle en groupes, un peu comme un espace de noms encapsule différents noms qui sont quelque peu liés. En fin de compte, le package peut également être créé par plusieurs autres packages pour représenter des systèmes et des comportements plus complexes.

L'objectif principal d'un diagramme de package est de montrer les relations entre les différents composants importants qui composent un système complexe. Les programmeurs trouvent cette opportunité d'abstraction bon avantage d'utiliser des diagrammes de packages, en particulier lorsque certains détails peuvent être omis de l'image.

Comme toute autre chose dans la vie, pour faire quelque chose de bien, vous avez besoin des bons outils. Pour documenter des logiciels, des processus ou des systèmes, utilisez des outils qui proposent des annotations UML et des modèles de diagramme. Il existe divers outils de documentation logicielle qui peuvent aider à dessiner le diagramme.

Ils entrent généralement dans les catégories principales suivantes :

Le papier et le stylo sont faciles. Prenez du papier et un stylo, ouvrez le code de syntaxe UML à partir du Web et dessinez le type de diagramme de votre choix.
Outils en ligne - Plusieurs applications en ligne peuvent être utilisées pour créer un diagramme. La plupart d'entre eux proposent un abonnement payant ou un nombre limité de diagrammes dans le niveau gratuit.
Les outils en ligne gratuits sont presque les mêmes que ceux payants. La principale différence est que les payants proposent également des tutoriels et des modèles prêts à l'emploi pour des diagrammes spécifiques.
Application de bureau - L'application de bureau typique à utiliser pour les diagrammes et à peu près n'importe quel autre diagramme est Microsoft Visio. Il offre des fonctionnalités et des fonctionnalités avancées. Le seul inconvénient est que vous devez payer pour cela.

Ainsi, il est clair que l'UML est un aspect important associé au développement de logiciels orientés objet. Il utilise notation graphique pour créer des modèles visuels de programmes système.

Annotation: Le sujet de ce cours est L'UML - Langage de Modélisation Unifié. Dans la conférence précédente, nous avons parlé de ce qu'est UML, de son histoire, de son objectif, des manières d'utiliser le langage, de la structure de sa définition, de sa terminologie et de sa notation. Il a été noté qu'un modèle UML est un ensemble de diagrammes. Dans cette conférence, nous examinerons ces questions : pourquoi avons-nous besoin de plusieurs types de diagrammes ; types de diagrammes ; POO et diagrammes de séquence

Avant de passer à la discussion sur le matériel principal de cette conférence, parlons de la raison pour laquelle construire des diagrammes. Le développement d'un modèle de n'importe quel système (pas seulement un logiciel) précède toujours sa création ou sa mise à jour. Cela est nécessaire au moins pour imaginer plus clairement le problème à résoudre. Des modèles réfléchis sont très importants à la fois pour l'interaction au sein de l'équipe de développement et pour la compréhension mutuelle avec le client. Après tout, cela vous permet de vous assurer que le projet est « architecturalement cohérent » avant qu'il ne soit implémenté dans le code.

Nous construisons des modèles de systèmes complexes car nous ne pouvons pas les décrire complètement, "regardez-les d'un coup d'œil". Par conséquent, nous distinguons uniquement les propriétés du système qui sont essentielles pour une tâche particulière et construisons son modèle qui reflète ces propriétés. La méthode d'analyse orientée objet permet de décrire des systèmes complexes réels de la manière la plus adéquate. Mais à mesure que les systèmes deviennent plus complexes, une bonne technologie de simulation devient nécessaire. Comme nous l'avons dit dans la conférence précédente, un système unifié est utilisé comme une telle technologie "standard". langage de modélisation(Unified Modeling Language, UML), qui est un langage graphique pour la spécification, la visualisation, la conception et la documentation des systèmes. UML peut être utilisé pour développer modèle détaillé du système en cours de création, reflétant non seulement son concept, mais également les caractéristiques spécifiques de sa mise en œuvre. Dans le cadre du modèle UML, toutes les représentations du système sont fixées sous la forme de constructions graphiques spéciales appelées diagrammes.

Note. Nous ne considérerons pas tous, mais seulement certains des types de graphiques. Par exemple, le diagramme de composants n'est pas couvert dans ce cours, qui n'est qu'un bref aperçu des types de diagrammes. Le nombre de types de graphiques pour un modèle d'application particulier n'est en aucun cas limité. Pour des applications simples, il n'est pas nécessaire de construire des schémas de tous types sans exception. Certains d'entre eux peuvent simplement manquer, et ce fait ne sera pas considéré comme une erreur. Il est important de comprendre que la disponibilité des diagrammes d'un certain type dépend des spécificités d'un projet particulier. Des informations sur d'autres types de diagrammes (non abordés ici) peuvent être trouvées dans la norme UML.

Pourquoi avez-vous besoin de plusieurs types de graphiques

Tout d'abord, définissons la terminologie. Dans la préface de ce cours, nous avons utilisé à plusieurs reprises les concepts de système, de modèle et de diagramme. L'auteur est sûr que chacun de nous comprend intuitivement le sens de ces concepts, mais pour le rendre complètement clair, regardons à nouveau le glossaire et lisons ce qui suit :

Système- un ensemble de sous-systèmes gérés unis par un objectif commun de fonctionnement.

Oui, pas très informatif. Qu'est-ce qu'un sous-système alors ? Pour clarifier la situation, tournons-nous vers les classiques :

système appellent un ensemble de sous-systèmes organisés pour atteindre un but précis et décrits à l'aide d'un ensemble de modèles, éventuellement de points de vue différents.

Eh bien, vous ne pouvez rien faire, vous devez rechercher la définition d'un sous-système. Il y est également dit que sous-système est un ensemble d'éléments, dont certains spécifient le comportement d'autres éléments. Ian Sommerville explique le concept de cette façon :

Sous-système est un système dont le fonctionnement ne dépend pas des services d'autres sous-systèmes. Le système logiciel est structuré comme un ensemble de sous-systèmes relativement indépendants. Les interactions entre les sous-systèmes sont également définies.

Pas très clair non plus, mais mieux. S'exprimant en langage "humain", le système est représenté comme un ensemble d'entités plus simples et relativement autosuffisantes. Cela peut être comparé à la façon dont, dans le processus de développement d'un programme, nous construisons une interface graphique à partir de "cubes" standard - des composants visuels, ou à la façon dont le texte du programme lui-même est également divisé en modules contenant des sous-programmes qui sont combinés selon une fonction fonction, et ils peuvent être réutilisés, dans les programmes suivants.

Comprendre le concept de système. Au cours du processus de conception, le système est considéré de différents points de vueà l'aide de modèles dont les différentes représentations apparaissent sous forme de schémas. Encore une fois, le lecteur peut avoir des questions sur la signification des concepts des modèles et diagrammes. Nous pensons une définition belle, mais pas très claire modèles en tant qu'abstraction de système sémantiquement fermé est peu susceptible de clarifier la situation, alors essayons d'expliquer "dans nos propres mots".

Modèle- il s'agit d'un certain objet (matériel ou non) qui affiche uniquement les caractéristiques les plus significatives du système pour cette tâche. Les modèles sont différents - tangibles et intangibles, artificiels et naturels, décoratifs et mathématiques...

Donnons quelques exemples. Les petites voitures en plastique que nous connaissons tous, auxquelles nous avons joué avec tant de passion dans l'enfance, ne sont rien de plus que matériel artificiel décoratif vrai modèle de voiture. Bien sûr, dans une telle "voiture" il n'y a pas de moteur, on ne remplit pas son réservoir d'essence, la boîte de vitesses ne fonctionne pas (d'ailleurs, elle n'existe pas du tout), mais en tant que maquette, ce jouet remplit pleinement ses fonctions : elle donne à l'enfant une idée sur la voiture, car elle affiche ses traits caractéristiques que sont la présence de quatre roues, une carrosserie, des portes, des vitres, la capacité de conduire, etc.

Dans la recherche médicale, les tests sur les animaux précèdent souvent les essais cliniques de médicaments chez l'homme. Dans ce cas, l'animal agit comme matériau naturel modèles humains.

L'équation ci-dessus est également un modèle, mais il s'agit d'un modèle mathématique, et il décrit le mouvement d'un point matériel sous l'action de la gravité.

Il ne reste plus qu'à dire ce qu'est un schéma. Diagramme- c'est représentation graphique de nombreux éléments. Généralement représenté sous la forme d'un graphe avec des sommets (entités) et des arêtes (relations). Il existe de nombreux exemples de diagrammes. Il s'agit d'un schéma fonctionnel que nous connaissons tous depuis les années scolaires, et des schémas d'installation de divers équipements que nous pouvons voir dans les manuels d'utilisation, et une arborescence de fichiers et de répertoires sur un disque, que nous pouvons voir en exécutant la commande tree dans le Console Windows, et bien plus encore. À Vie courante les schémas nous entourent de toutes parts, car l'image nous est plus facile à percevoir que le texte...

Mais revenons à la conception de logiciels (et pas seulement). Dans cette industrie depuis à l'aide de diagrammes, vous pouvez visualiser le système sous différents points de vue. L'un des diagrammes, par exemple, peut décrire l'interaction de l'utilisateur avec le système, l'autre - le changement des états du système pendant son fonctionnement, le troisième - l'interaction entre les éléments du système, etc. Un complexe système peut et doit être représenté comme un ensemble de petits modèles presque indépendants - des diagrammes, et aucun d'entre eux n'est suffisant pour décrire le système et en obtenir une image complète, puisque chacun d'eux se concentre sur un aspect particulier du fonctionnement du système et exprime un autre niveau d'abstraction. En d'autres termes, chaque modèle correspond à un point de vue spécifique et particulier sur le système en cours de conception.

Malgré le fait que dans le paragraphe précédent nous étions très lâches avec le concept de modèle, il faut comprendre que dans le contexte des définitions ci-dessus aucun diagramme n'est un modèle. Les diagrammes ne sont qu'un moyen de visualiser le modèle, et les deux doivent être distingués. Seul un ensemble de diagrammes constitue un modèle de système et le décrit le plus complètement, mais pas un schéma sorti de son contexte.

Types de graphiques

UML 1.5 défini douze types de graphiques divisé en trois groupes :

quatre types de diagrammes représentent la structure statique de l'application ;
cinq représentent les aspects comportementaux du système ;
trois représentent les aspects physiques du fonctionnement du système (schémas de mise en œuvre).

La version actuelle d'UML 2.1 n'a pas apporté trop de modifications. Les diagrammes ont légèrement changé d'apparence (des cadres et d'autres améliorations visuelles sont apparus), la notation s'est légèrement améliorée, certains diagrammes ont reçu de nouveaux noms.

Cependant, le nombre exact diagrammes canoniques cela n'a absolument aucune importance pour nous, car nous ne les considérerons pas tous, mais seulement certains - pour la raison que le nombre de types de diagrammes pour un modèle particulier d'une application particulière n'est pas strictement fixé. Pour des applications simples, il n'est pas nécessaire de construire tous les diagrammes sans exception. Par exemple, pour une application locale, il n'est pas nécessaire de construire un schéma de déploiement. Il est important de comprendre que la liste des diagrammes dépend des spécificités du projet en cours de développement et est déterminée par le développeur lui-même. Si le lecteur curieux veut tout de même connaître tous les diagrammes UML, nous le renverrons au standard UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Rappelons que le but de ce cours n'est pas de décrire absolument toutes les possibilités d'UML, mais seulement d'introduire ce langage, de donner une première idée de cette technologie.

Ainsi, nous examinerons brièvement des types de graphiques tels que :

diagramme de cas d'utilisation;
diagramme de classe ;
diagramme d'objet;
diagramme de séquençage;
diagramme d'interaction ;
diagramme d'état ;
Diagramme d'activité;
schéma de déploiement.

Nous parlerons de certains de ces diagrammes plus en détail dans les prochaines conférences. En attendant, nous ne nous attarderons pas sur les détails, mais nous fixons pour objectif d'apprendre au lecteur à distinguer au moins visuellement les types de schémas, pour donner une première idée de la finalité des principaux types de schémas. . Alors, commençons.

Diagramme de cas d'utilisation

Tous les systèmes (y compris les logiciels) sont conçus en tenant compte du fait qu'au cours de leur travail, ils seront utilisés par des personnes et / ou interagiront avec d'autres systèmes. Les entités avec lesquelles le système interagit au cours de son travail sont appelées acteurs, et chaque acteur s'attend à ce que le système se comporte d'une manière strictement définie et prévisible. Essayons de donner une définition plus rigoureuse d'un secteur. Pour ce faire, nous utilisons un merveilleux vocabulaire visuel pour UML Mentor Zicom:

Hector (acteur)- il s'agit d'un ensemble de rôles logiquement liés exécutés lors de l'interaction avec des précédents ou des entités (système, sous-système ou classe). Un acteur peut être une personne ou un autre système, sous-système ou classe qui représente quelque chose en dehors de l'entité.

Graphiquement, le vecteur est représenté soit " petit homme", semblables à ceux que nous avons dessinés dans l'enfance, représentant des membres de notre famille, ou symbole de classe avec stéréotype correspondant, comme indiqué sur la photo. Les deux formes de présentation ont la même signification et peuvent être utilisées dans des diagrammes. La forme "stéréotypée" est plus souvent utilisée pour représenter les acteurs du système ou dans les cas où l'acteur a des propriétés qui doivent être affichées (Fig. 2.1).

Le lecteur attentif peut immédiatement se poser la question : Pourquoi Hector et pas un acteur ?? On est d'accord, le mot "ektor" coupe un peu l'oreille d'un Russe. La raison pour laquelle nous disons cela est simple - l'ecteur est formé à partir du mot action, ce qui signifie en traduction action. La traduction littérale du mot "ektor" - acteur- trop long et inconfortable à utiliser. Par conséquent, nous continuerons à le dire.

Riz. 2.1.

Le même lecteur attentif a pu remarquer le mot "précédent" clignoté dans la définition de l'ecteur. Qu'est-ce que c'est? Cette question nous intéressera encore plus si nous nous souvenons que nous parlons maintenant de diagramme de cas d'utilisation. Donc,

Précédent (cas d'utilisation)- description d'un aspect particulier du comportement du système du point de vue de l'utilisateur (Butch).

La définition est tout à fait compréhensible et exhaustive, mais elle peut être encore affinée en utilisant le même Mentor Zicom"om :

cas d'utilisation- description de l'ensemble des événements successifs (y compris les variantes) effectués par le système qui conduisent au résultat observé par l'acteur. Un cas d'utilisation représente le comportement d'une entité en décrivant l'interaction entre les acteurs et le système. Un précédent ne montre pas "comment" un certain résultat est atteint, mais seulement "ce qu'il est".

Les précédents sont indiqués de manière très simple - sous la forme d'une ellipse, à l'intérieur de laquelle son nom est indiqué. Les cas d'utilisation et les acteurs sont connectés avec des lignes. Souvent, à une extrémité de la ligne, représentent du riz. 2.3

formation d'exigences générales pour le comportement du système en cours de conception;

développement d'un modèle conceptuel du système pour son détail ultérieur;

préparation de la documentation pour l'interaction avec les clients et les utilisateurs du système.