Les diagrammes Uml permettent de décrire lors de la modélisation. Caractéristiques générales du langage UML

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. En utilisant UML, vous pouvez développer un modèle détaillé système créé, qui reflète non seulement son concept, mais également des caractéristiques de mise en œuvre spécifiques. 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.

Noter. Nous ne considérerons pas tous, mais seulement certains des types de graphiques. Par exemple, le diagramme de composants n'est pas couvert dans cette leçon, qui est seulement Aperçu types de graphiques. Nombre de types de graphiques pour modèle spécifique les applications ne sont en aucun cas limitées. Pour applications simples il n'est pas nécessaire de construire des diagrammes 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 contrôlés interconnecté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 d'élaboration d'un programme, nous construisons interface graphiqueà partir de "cubes" standard - composants visuels, ou comment le texte du programme lui-même est également divisé en modules contenant des sous-programmes, combinés selon une caractéristique fonctionnelle, 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 modèle ce jouet remplit pleinement ses fonctions : il donne à l'enfant une idée sur la voiture, car il 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 diagramme. Diagramme- ce 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 divers équipements, que nous pouvons voir dans les manuels d'utilisation, et l'arborescence des fichiers et répertoires sur le disque, que nous pouvons voir en exécutant la commande tree dans la console Windows, et bien plus encore. Au quotidien, les schémas nous entourent de toutes parts, car une image nous est plus facile à percevoir qu'un 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. Seulement 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 changements. 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é;
diagramme de déploiement.

Nous parlerons de certains de ces diagrammes plus en détail dans les prochaines conférences. Pour l'instant, 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 le merveilleux vocabulaire visuel par 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 (Figure 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. Alors,

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 Exigences générales au comportement du système conçu ;

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.

11.1. Structure du langage de modélisation unifié

Langage de modélisation unifié (UML) est actuellement la norme de facto pour décrire (documenter) les résultats de la conception et du développement de systèmes orientés objet. Le développement d'UML a commencé en 1994 par Grady Booch et James Rumbaugh chez Rational Software. À l'automne 1995, Ivar Jakobson les rejoint et en octobre de la même année, une version préliminaire de la méthode unifiée 0.8 est publiée. Depuis, plusieurs versions de la spécification UML ont été publiées, dont deux ont le statut de norme internationale :

UML 1.4.2 - "ISO/CEI 19501:2005. Informatique. Traitement de la distribution ouverte. Langage de modélisation unifié (UML). Version 1.4.2" (Eng. "Technologies de l'information. Traitement distribué ouvert. Langage de modélisation unifié (UML). Version 1.4.2");

UML 2.4.1 - "ISO / IEC 19505-1: 2012. Technologies de l'information. Langage de modélisation de groupe de gestion d'objets unifié (OMG UML). Partie 1. Infrastructure" (Eng. "Technologies de l'information - Langage de modélisation unifié du groupe de gestion d'objets (OMG UML) - Partie 1 : Infrastructure ») et « ISO/CEI 19505-2 : 2012. Technologies de l'information. Langage de modélisation de groupe de gestion d'objets unifié (OMG UML). Partie 2. Superstructure » (Anglais « Technologies de l'information - Groupe de gestion d'objets Unified Modeling Langage (OMG UML) - Partie 2 : Superstructure").

La dernière spécification de langue officielle peut être consultée sur www.omg.org.

La structure générale d'UML est présentée dans la figure suivante.

Riz. 11.1. Structure UML

11.2. Sémantique et syntaxe d'UML

Sémantique - une section de linguistique qui étudie le sens des unités d'une langue, principalement ses mots et ses phrases.

Syntaxe - façons de relier les mots et leurs formes en phrases et en phrases, de relier les phrases en phrases complexes, de créer des déclarations dans le cadre du texte.

Ainsi, par rapport à UML, la sémantique et la syntaxe déterminent le style de présentation (modèles de construction), qui combine les langages naturels et formels pour représenter les concepts de base (éléments du modèle) et les mécanismes de leur extension.

11.3. Notation UML

La notation est une interprétation graphique de la sémantique pour sa représentation visuelle.

L'UML définit trois type d'entité :

Structurel - une abstraction qui est le reflet d'un objet conceptuel ou physique ;

Regroupement - un élément utilisé pour une association sémantique d'éléments de diagramme ;

Explicative (annotation) - un commentaire à un élément de diagramme.

Le tableau suivant fournit une brève description des principales entités utilisées en notation graphique et des principaux moyens de les afficher.

Tableau 11.1. Essences

Taper	Nom	La désignation	Définition (sémantique)
De construction	(classer)		Un ensemble d'objets qui partagent une structure et un comportement communs
	(objet)		Une abstraction d'une entité réelle ou imaginaire avec des limites conceptuelles, une individualité (identité), un état et un comportement bien définis. Du point de vue UML, les objets sont des instances de classe (instances d'entité)
	(acteur)	Ingénieur services de chemin	Une entité externe au système qui interagit avec et utilise le système Fonctionnalité pour atteindre certains objectifs ou résoudre des problèmes particuliers. Ainsi, un acteur est une source externe ou un récepteur d'informations.
	(cas d'utilisation)		Description des actions réalisées par le système, qui aboutissent à un résultat significatif pour l'acteur
	(Etat)		Description du moment dans la vie d'une entité où elle satisfait à une condition, exécute une activité ou attend qu'un événement se produise.
	La coopération (collaboration)		Description d'un ensemble d'instances d'acteurs, d'objets et de leur interaction dans le processus de résolution d'un certain problème
	(composant)		La partie physique du système (fichier), y compris les modules système qui fournissent la mise en œuvre d'un ensemble cohérent d'interfaces
	(interface)	iCalcul	Un ensemble d'opérations qui définit un service (ensemble de services) fourni par une classe ou un composant
	(nœud)		La partie physique du système (ordinateur, imprimante, etc.) qui fournit des ressources pour résoudre un problème
Regroupement	(emballer)		Mécanisme général de regroupement d'éléments. Contrairement à un composant, un package est un concept purement conceptuel (abstrait). Les cas particuliers d'un package sont le système et le modèle
	(fragment)		Zone d'interaction spécifique des instances d'acteur et d'objet
	(partition d'activité)		Un groupe d'opérations (domaine de responsabilité) effectuées par une seule entité (acteur, objet, composant, nœud, etc.)
	(région d'activité interruptible)		Groupe d'opérations dont la séquence normale d'exécution peut être interrompue à la suite d'une situation inhabituelle
explicatif	Noter (commenter)		Commentaire d'élément. Attaché à l'élément commenté par une ligne pointillée

Certaines sources, notamment [ , ], distinguent également des entités comportementales interactions Et machines d'état, mais d'un point de vue logique, ils doivent être classés comme des diagrammes.

Certaines des entités ci-dessus impliquent leur description détaillée dans des diagrammes de décomposition. Sur le diagramme de niveau supérieur, ils sont signalés par une icône ou une étiquette spéciale.

Le tableau suivant décrit chaque type rapports UML utilisé dans les diagrammes pour indiquer les relations entre les entités.

Tableau 11.3. Rapports

Nom	La désignation	Définition (sémantique)
Association		Une relation qui décrit une relation significative entre deux ou plusieurs entités. Plus Forme générale rapports
Agrégation		Un sous-type d'une association qui décrit une relation « partie » – « tout », dans laquelle la « partie » peut exister séparément du « tout ». Le losange est indiqué du côté "tout". Une relation est spécifiée uniquement entre des entités du même type
Composition		Une sous-espèce d'agrégation dans laquelle les "parties" ne peuvent pas exister séparément du "tout". En règle générale, les "parties" sont créées et détruites simultanément avec le "tout"
Dépendance		Une relation entre deux entités dans laquelle un changement dans une entité (l'indépendante) peut affecter l'état ou le comportement de l'autre entité (la dépendante). Une entité indépendante est indiquée à côté de la flèche
Généralisation		Relation entre une entité généralisée (ancêtre, parent) et une entité spécialisée (enfant, fille). Le triangle est indiqué du côté du parent. Une relation est spécifiée uniquement entre des entités du même type
La concrétisation		Relation entre entités dans laquelle une entité spécifie une action qu'une autre entité s'engage à effectuer. Les relations sont utilisées dans deux cas : entre interfaces et classes (ou composants), entre cas d'utilisation et collaborations. Le côté de la flèche indique l'entité qui définit l'action (interface ou cas d'utilisation)

Pour l'association, l'agrégation et la composition, vous pouvez spécifier multiplicité (multiplicité anglaise), qui caractérise le nombre total d'instances d'entités participant à la relation. En règle générale, il est indiqué de chaque côté de la relation près de l'entité correspondante. La multiplicité peut être spécifiée des manières suivantes :

- * - n'importe quel nombre d'exemplaires, y compris aucun ;

Entier non négatif - la multiplicité est strictement fixe et égale au nombre spécifié (par exemple : 1, 2 ou 5) ;

Plage d'entiers non négatifs "premier nombre.. deuxième nombre" (par exemple : 1..5, 2..10 ou 0..5) ;

Une plage de nombres allant d'une valeur initiale spécifique à un "premier nombre..*" final arbitraire (par exemple : 1..*, 5..* ou 0..*) ;

Enumération d'entiers non négatifs et de plages séparées par des virgules (par exemple : 1, 3..5, 10, 15..*).

Si la multiplicité n'est pas spécifiée, sa valeur est supposée être 1. La multiplicité des instances d'entité impliquées dans la dépendance, la généralisation et l'implémentation est toujours supposée être 1.

Le tableau suivant fournit une description mécanismes d'expansion utilisé pour affiner la sémantique des entités et des relations. En général, le mécanisme d'expansion est une chaîne de texte entre parenthèses ou guillemets.

Tableau 11.4. Mécanismes d'extension

Nom	La désignation	Définition (sémantique)
Stéréotype (stéréotype)	« »	Une désignation qui spécifie la sémantique de l'élément de notation (par exemple : une dépendance avec le stéréotype "include" est considérée comme une relation d'inclusion, et une classe avec le stéréotype "limite" est une classe limite)
état de garde (condition de garde)		Condition booléenne (par exemple : ou [identification effectuée])
Limitation (contrainte)	{ }	Une règle qui restreint la sémantique d'un élément de modèle (par exemple, (temps d'exécution inférieur à 10 ms))
Valeur marquée (valeur taguée)	{ }	Une propriété d'élément de notation nouvelle ou qualificative (par exemple : (version = 3.2))

Outre les stéréotypes spécifiés sous forme de chaîne de texte entre guillemets, les stéréotypes graphiques peuvent être utilisés dans les graphiques. La figure suivante montre des exemples de mappage standard et de stéréotype.


a) désignation standard		b) désignation standard avec stéréotype de texte		c) stéréotype graphique

Riz. 11.2. Exemples de mappage de classe standard et stéréotypé

Diagramme est un groupement d'éléments de notation pour afficher certains aspects du développement Système d'Information. Les diagrammes sont généralement un graphe connexe dans lequel les entités sont des sommets et les relations sont des arcs. Le tableau suivant donne une brève description des diagrammes UML.

Tableau 11.5. Diagrammes

Diagramme			But
				selon le degré d'implantation physique	en affichant la dynamique	par aspect affiché
(cas d'utilisation)			Affiche les fonctions du système, l'interaction entre les acteurs et les fonctions	logique	statique	fonctionnel
(classer)			Affiche un ensemble de classes, d'interfaces et de relations entre elles	Booléen ou physique	statique	Informations fonctionnelles
(emballer)			Affiche un ensemble de packages et leurs relations	Booléen ou physique	statique	Composant
comportement (comportement)	(ordinateur d'état)		Affiche les états de l'entité et les transitions entre eux au cours de son cycle de vie	logique	Dynamique	comportemental
	(activité)		Affiche les processus métier dans le système (description des algorithmes de comportement)
	Interactions (interaction)	(séquence)	Affiche la séquence de message passant entre les objets et les acteurs
		(la communication)	Similaire à un diagramme de séquence, mais l'accent est mis sur la structure de l'interaction entre les objets
Implémentations (la mise en oeuvre)	(composant)		Affiche les composants du système (programmes, bibliothèques, tables, etc.) et les liens entre eux	Physique	statique	Composant
	(déploiement)		Affiche le placement des composants par nœuds de réseau, ainsi que sa configuration

La norme UML 2.x définit également des diagrammes supplémentaires hautement spécialisés :

Diagramme d'objets (diagramme d'objets) - similaire, mais les objets sont affichés à la place des classes ;

Chronogramme - décrit l'état de l'objet au fil du temps ;

Diagramme de structure composite (diagramme de structure composite) - décrit les ports (y compris les interfaces) de la classe pour l'interaction avec d'autres classes ;

Diagramme de profil (diagramme de profil) - similaire à la description des classes qu'ils contiennent;

Diagramme d'aperçu des interactions - similaire, mais avec des fragments d'interaction cachés (fragments avec une étiquette de référence). Il s'agit d'un contexte (conceptuel) dont les éléments seront précisés sur des schémas de décomposition séparés.

Afin d'élargir la représentation conceptuelle de l'architecture interne du système, la majeure partie de la construction permet l'utilisation de stéréotypes graphiques bien établis pour le soi-disant. Un tel diagramme est appelé 1 , mais n'appartient pas à la liste des diagrammes définis par la norme UML.

Lors du développement d'un modèle de système séparé, plusieurs types de diagrammes sont créés. De plus, lors du développement d'un modèle d'un système complexe, en règle générale, plusieurs diagrammes du même type sont construits. Dans le même temps, vous n'avez pas besoin de créer des vues de graphique distinctes si vous n'en avez pas besoin. Par exemple, les diagrammes et sont interchangeables ; ils sont construits uniquement pour des objets au comportement complexe. Le tableau suivant fournit des recommandations sur la nécessité de développer (affiner) des diagrammes pour les modèles de système.

Tableau 11.6. Liaison de modèles et de diagrammes

Le tableau ci-dessus ne montre pas le modèle de test, car dans le cadre de sa construction, les diagrammes ne sont pas développés, mais sont vérifiés (testés) pour leur exhaustivité et leur cohérence.

Une partie des diagrammes après leur construction nécessite un développement et un raffinement dans le cadre du développement du modèle suivant (processus technologique). Ainsi, par exemple, doit être clarifié lors du développement. dans les modèles.

4. Définissez le terme "".

Le diagramme UML est un langage de description graphique spécialisé conçu pour la modélisation d'objets dans le développement de divers Logiciel. Ce langage a un profil large et est une norme ouverte qui utilise diverses notations graphiques pour créer un modèle abstrait d'un système. L'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 un code séparé basé sur celui-ci.

Pourquoi est-elle nécessaire?

L'utilisation d'UML ne s'arrête pas à la modélisation de toutes sortes de logiciels. En outre, ce langage est activement utilisé aujourd'hui pour la modélisation de divers processus métier, la conception de systèmes et l'affichage de structures organisationnelles.

Avec l'aide d'UML, les développeurs de logiciels peuvent garantir un accord complet sur les conventions graphiques utilisées pour représenter concepts généraux, tels que : composant, généralisation, classe, comportement et agrégation. Cela permet d'obtenir une plus grande concentration sur l'architecture et le design.

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

diagramme de classe

Un diagramme de classes UML est un diagramme de structure 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 le fait qu'il existe plusieurs points de vue sur la construction de tels diagrammes, 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 ne fournit que 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 qui sont directement utilisées dans le code du programme.

Diagramme des composants

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

Schéma de structure composite/composite

Le 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 des éléments qui se trouvent dans la structure interne de la classe.

Une sous-espèce de ceux-ci est le diagramme de collaboration UML, qui est utilisé pour démontrer les rôles et les interactions des différentes classes dans le cadre d'une collaboration. Ils sont très pratiques si vous avez besoin de modéliser des modèles de conception.

Il convient de noter que les diagrammes de classes UML et les diagrammes de structure composite peuvent être utilisés en même temps.

Diagramme 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 principalement utilisé pour la seconde version.

Une dépendance de manifestation est formée entre un 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 certain moment. Il affiche entièrement toutes les instances des classes d'un système particulier, indiquant les valeurs actuelles de leurs paramètres, ainsi que les relations entre eux.

Schéma de l'emballage

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

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

Diagramme d'activité

Le diagramme d'activité UML affiche la décomposition d'une activité particulière en plusieurs parties constitutives. Dans ce cas, le concept d '"activité" fait référence à la spécification d'un certain comportement exécutable sous la forme d'une exécution parallèle, ainsi que d'une exécution séquentielle coordonnée de divers éléments subordonnés - types imbriqués d'activités et d'actions diverses, unis par des flux allant du sorties d'un certain nœud aux entrées d'un autre.

Le diagramme d'activités UML est souvent utilisé pour modéliser divers processus métier, parallèles et calcul séquentiel. Ils modélisent entre autres toutes sortes de procédés technologiques.

diagramme d'automate

Cette vue s'appelle et quelque peu différemment - le diagramme d'état UML. Il a une machine à états présentée 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 une interaction en réponse à certains événements de sa vie, ainsi que la réponse de l'objet à de tels événements. La machine d'état utilisée par le diagramme d'état UML est attachée à l'élément d'origine et utilisée pour définir le comportement de ses instances.

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

Diagrammes de cas d'utilisation

Le diagramme de cas d'utilisation UML affiche toutes les relations qui se produisent entre les acteurs, ainsi que les différents cas d'utilisation. Sa tâche principale est de fournir un moyen à part entière par lequel le client, l'utilisateur final ou un développeur peut discuter conjointement du comportement et des fonctionnalités d'un système particulier.

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

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 sa fonctionnalité attendue.
Définir dans le glossaire comme sujet divers concepts liés à Description détaillée fonctionnalité de ce système.

Si un diagramme d'utilisation est en cours d'élaboration dans l'UML, la procédure commence par une description textuelle, qui est obtenue lors de la collaboration avec le client. Dans le même temps, il convient de noter le fait que diverses exigences non fonctionnelles sont complètement omises dans le processus de compilation du modèle de cas d'utilisation, et un document séparé sera déjà formé pour elles.

Communication

Le diagramme de communication, tout comme le diagramme de séquence UML, est transitif, c'est-à-dire qu'il exprime l'interaction, mais en même temps la démontre. différentes façons, et si nécessaire, avec le degré de précision requis, vous pouvez convertir l'un à l'autre.

Le schéma 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. Sa principale différence avec le diagramme de séquence est qu'il indique clairement la relation entre plusieurs éléments et que le temps n'est pas utilisé comme une dimension distincte.

Ce type se distingue par un format absolument libre consistant à ordonner plusieurs objets et relations 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 chronologiquement. La lecture de ce schéma commence par le message initial 1.0, et se poursuit ensuite dans le sens de transmission des messages d'un objet à l'autre.

Pour la plupart, ces diagrammes montrent exactement les mêmes informations qu'un diagramme de séquence nous fournit, mais parce qu'il utilise une manière différente de présenter les informations, certaines choses dans un diagramme deviennent beaucoup plus faciles à déterminer 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 sont effectuées.

diagramme de séquençage

Le diagramme de séquence UML montre les interactions entre plusieurs objets, qui sont ordonnés selon le moment de leur occurrence. Un tel diagramme montre une interaction ordonnée dans le temps entre plusieurs objets. En particulier, il affiche tous les objets qui participent à l'interaction, ainsi que la séquence complète des messages échangés par eux.

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

Diagramme de coopération

Ce type de diagramme permet de montrer les interactions entre plusieurs objets, en faisant abstraction de la séquence de traduction des messages. Ce type de diagrammes sous une forme compacte affiche 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 les diagrammes de communication sont simplement des vues différentes des mêmes procédures, Rational Rose offre la possibilité de créer un diagramme de séquence de communication à partir d'un diagramme de séquence ou vice versa, et les synchronise également de manière entièrement automatique.

Diagrammes de présentation des interactions

Ce sont des graphiques Langage UML, qui font référence à une variété de diagrammes d'activité et incluent à la fois des éléments de séquence et des constructions de flux de contrôle.

Il convient de noter le fait que ce format combine la collaboration et le diagramme de séquence, qui offrent la possibilité de considérer l'interaction entre plusieurs objets du système en cours de formation à partir de différents points de vue.

Chronogramme

Représente une version alternative du diagramme de séquence, qui montre explicitement le changement d'état sur la ligne de vie avec une certaine échelle de temps. Cela peut être très utile dans diverses applications en temps réel.

Quels sont les bénéfices?

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 de description des résultats de l'analyse et de la conception effectuées sont sémantiquement proches des méthodes de programmation dans toutes sortes de langages orientés objet de type moderne.
Avec de l'aide langue donnée le 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 familiarisation relativement rapide avec sa syntaxe.
UML vous permet d'étendre, ainsi que d'introduire vos propres stéréotypes graphiques et textuels, ce qui contribue à son utilisation non seulement en génie logiciel.
La langue est devenue assez répandue et se développe également assez activement.

désavantages

Malgré le fait que la construction des diagrammes UML a beaucoup d'avantages, on leur reproche souvent les défauts suivants :

redondance. Dans la grande majorité des cas, les critiques disent que l'UML est trop grand et complexe, et souvent cela est injustifié. Il comprend un grand nombre de constructions et de diagrammes redondants ou presque inutiles, et le plus souvent, ces critiques vont à la deuxième version, et non à la première, car dans les révisions plus récentes, il y a davantage de compromis "conçus par le comité".
Diverses inexactitudes dans la sémantique. Comme UML est défini par une combinaison de lui-même, de l'anglais et d'OCL, il lui manque la rigidité inhérente aux langages définis avec précision par des techniques de description formelles. Dans certaines situations, les syntaxes abstraites d'OCL, d'UML et de l'anglais commencent à se contredire, alors que dans d'autres cas, elles sont incomplètes. L'inexactitude de la description du langage lui-même affecte à la fois les utilisateurs et les fournisseurs d'outils, entraînant éventuellement des incompatibilités d'outils en raison de la manière unique dont les différentes spécifications sont traitées.
Problèmes dans le processus de mise en œuvre et d'étude. Tous les problèmes ci-dessus créent certaines difficultés dans le processus de mise en œuvre et d'apprentissage d'UML, et cela est particulièrement vrai lorsque la direction oblige les ingénieurs à l'utiliser alors qu'ils manquent de compétences 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 qui fonctionnent directement, 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 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 être suffisant, car le langage manque de propriétés de complétude de Turing, et chaque code généré sera éventuellement limité par ce que l'outil d'interprétation UML peut supposer 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 la sortie d'un autre. Comme pour toute notation standard, l'UML peut représenter certains systèmes de manière plus efficace et concise que d'autres. Ainsi, le développeur est plus enclin aux solutions les plus confortables pour imbriquer toutes forces UML, ainsi que d'autres langages de programmation. Ce problème est plus évident si le langage de développement ne suit pas les principes de base de la doctrine orthodoxe orientée objet, c'est-à-dire s'il n'essaie pas de fonctionner conformément aux principes de la POO.
Essaie d'être polyvalent. L'UML est un langage de modélisation à usage général qui cherche à être compatible avec n'importe quel langage de traitement existant actuellement. Dans le cadre d'un projet particulier, pour que l'équipe de conception atteigne l'objectif final, il est nécessaire de choisir les fonctionnalités applicables de ce langage. De plus, les moyens possibles de limiter la portée de l'utilisation d'UML dans un domaine particulier passent par un formalisme qui n'est pas complètement formulé, mais qui fait lui-même l'objet de critiques.

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

Le diagramme UML est un langage de description graphique spécialisé conçu pour la modélisation d'objets dans le développement de divers logiciels. Ce langage a un profil large et est une norme ouverte qui utilise diverses notations graphiques pour créer un modèle abstrait d'un système. L'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 un code séparé basé sur celui-ci.

Pourquoi est-elle nécessaire?

Avec l'aide d'UML, les développeurs de logiciels peuvent garantir un accord complet dans la notation graphique utilisée pour représenter des concepts communs tels que : composant, généralisation, classe, comportement et agrégation. Cela permet d'obtenir une plus grande concentration sur l'architecture et le design.

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

diagramme de classe

Il convient de noter le fait qu'il existe plusieurs points de vue sur la construction de tels diagrammes, 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 ne fournit que 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 qui sont directement utilisées dans le code du programme.

Diagramme des composants

Le 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 relations entre eux. Un diagramme de composants UML peut utiliser toutes sortes de modèles, bibliothèques, fichiers, packages, exécutables et de nombreux autres éléments en tant que tels.

Schéma de structure composite/composite

Il convient de noter que les diagrammes de classes UML et les diagrammes de structure composite peuvent être utilisés en même temps.

Diagramme de déploiement

Une dépendance de manifestation est formée entre un artefact et le composant qu'il implémente.

Diagramme d'objets

Schéma de l'emballage

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

Diagramme d'activité

Le diagramme d'activité UML affiche la décomposition d'une activité particulière en plusieurs composants. Dans ce cas, le concept d '"activité" fait référence à la spécification d'un certain comportement exécutable sous la forme d'une exécution parallèle, ainsi que d'une exécution séquentielle coordonnée de divers éléments subordonnés - types imbriqués d'activités et d'actions diverses, unis par des flux allant du sorties d'un certain nœud aux entrées d'un autre.

Le diagramme d'activité UML est souvent utilisé pour modéliser divers processus métier, l'informatique parallèle et séquentielle. Ils modélisent entre autres toutes sortes de procédés technologiques.

diagramme d'automate

Cette vue s'appelle et quelque peu différemment - le diagramme d'état UML. Il a une machine à états présentée avec des états simples et composites, ainsi que des transitions.

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

Diagrammes de cas d'utilisation

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

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 sa fonctionnalité attendue.
Définissez dans le glossaire comme sujet divers concepts liés à une description détaillée de la fonctionnalité de ce système.

Communication

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

diagramme de séquençage

Les principaux éléments dans ce cas sont les désignations de divers objets, ainsi que des lignes verticales qui affichent le passage du temps et des rectangles qui représentent l'activité d'un objet particulier ou l'exécution d'une fonction par celui-ci.

Diagramme de coopération

Diagrammes de présentation des interactions

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

Chronogramme

Quels sont les bénéfices?

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 de description des résultats de l'analyse et de la conception effectuées sont sémantiquement proches des méthodes de programmation dans toutes sortes de langages orientés objet de type moderne.
En utilisant ce langage, le 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 familiarisation relativement rapide avec sa syntaxe.
UML vous permet d'étendre, ainsi que d'introduire vos propres stéréotypes graphiques et textuels, ce qui contribue à son utilisation non seulement en génie logiciel.
La langue est devenue assez répandue et se développe également assez activement.

désavantages

Malgré le fait que la construction des diagrammes UML a beaucoup d'avantages, on leur reproche souvent les défauts suivants :

redondance. Dans la grande majorité des cas, les critiques disent que l'UML est trop grand et complexe, et souvent cela est injustifié. Il comprend un grand nombre de constructions et de diagrammes redondants ou presque inutiles, et le plus souvent, ces critiques vont à la deuxième version, et non à la première, car dans les révisions plus récentes, il y a davantage de compromis "conçus par le comité".
Diverses inexactitudes dans la sémantique. Comme UML est défini par une combinaison de lui-même, de l'anglais et d'OCL, il lui manque la rigidité inhérente aux langages définis avec précision par des techniques de description formelles. Dans certaines situations, les syntaxes abstraites d'OCL, d'UML et de l'anglais commencent à se contredire, alors que dans d'autres cas, elles sont incomplètes. L'inexactitude de la description du langage lui-même affecte à la fois les utilisateurs et les fournisseurs d'outils, entraînant éventuellement des incompatibilités d'outils en raison de la manière unique dont les différentes spécifications sont traitées.
Problèmes dans le processus de mise en œuvre et d'étude. Tous les problèmes ci-dessus créent certaines difficultés dans le processus de mise en œuvre et d'apprentissage d'UML, et cela est particulièrement vrai lorsque la direction oblige les ingénieurs à l'utiliser alors qu'ils manquent de compétences 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 qui fonctionnent directement, 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 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 être suffisant, car le langage manque de propriétés de complétude de Turing, et chaque code généré sera éventuellement limité par ce que l'outil d'interprétation UML peut supposer 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 la sortie d'un autre. Comme pour toute notation standard, l'UML peut représenter certains systèmes de manière plus efficace et concise que d'autres. Ainsi, le développeur est plus enclin aux solutions plus confortables pour tisser toutes les forces de l'UML, ainsi que d'autres langages de programmation. Ce problème est plus évident si le langage de développement ne se conforme pas aux grands principes de la doctrine orthodoxe orientée objet, c'est-à-dire s'il n'essaie pas de fonctionner conformément aux principes de la POO.
Essaie d'être polyvalent. L'UML est un langage de modélisation à usage général qui cherche à être compatible avec n'importe quel langage de traitement existant actuellement. Dans le cadre d'un projet particulier, pour que l'équipe de conception atteigne l'objectif final, il est nécessaire de choisir les fonctionnalités applicables de ce langage. De plus, les moyens possibles de limiter la portée de l'utilisation d'UML dans un domaine particulier passent par un formalisme qui n'est pas complètement formulé, mais qui fait lui-même l'objet de critiques.

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

Tous les diagrammes UML peuvent être conditionnellement divisés en deux groupes, le premier étant les diagrammes généraux. Les diagrammes généraux sont pratiquement indépendants du sujet de la modélisation et peuvent être utilisés dans n'importe quel projet logiciel sans tenir compte du domaine, du domaine de décision, etc.

1.5.1. Diagramme d'utilisation

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

Le schéma d'utilisation est destiné à répondre aux question principale simulation : que fait le système dans le monde extérieur ?

Dans le diagramme d'usage, deux types d'entités principales sont utilisés : les cas d'usage 1 et les acteurs 2, entre lesquels s'établissent les principaux types de relations suivants :

association entre acteur et cas d'utilisation 3 ;
généralisation entre acteurs 4 ;
généralisation entre cas d'utilisation 5 ;
dépendances ( divers types) entre les cas d'utilisation 6 .

Un schéma d'utilisation, comme tout autre, peut avoir des commentaires 7 . De plus, il est fortement recommandé de le faire pour améliorer la lisibilité des cartes.

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

1.5.2. diagramme de classe

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

Ce n'est pas surprenant, puisque l'UML est principalement un langage orienté objet, et les classes sont le principal (sinon le seul) bloc de construction.

Sur le diagramme de classes, un type principal d'entités est utilisé : les classes 1 (dont de nombreux cas particuliers de classes : interfaces, types primitifs, classes d'association, et bien d'autres), entre lesquelles s'établissent les principaux types de relations suivants :

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

Certains éléments de la notation utilisée dans le diagramme de classes sont présentés ci-dessous. Une description détaillée est donnée au chapitre 3 .

1.5.3. diagramme d'automate

diagramme d'automate(diagramme de machine d'état) est l'un des moyens de décrire en détail le comportement dans l'UML basé sur l'allocation explicite d'états et la description des transitions entre états.

En substance, les diagrammes d'automates, comme leur nom l'indique, sont un graphe de transition d'état (voir le chapitre 4), chargé de nombreux détails et détails supplémentaires.

Dans le diagramme de l'automate, un type principal d'entités est utilisé - les états 1 et un type de relations - les transitions 2 , mais pour les deux, de nombreuses variétés, des cas particuliers et des désignations supplémentaires sont définis. Les énumérer tous dans une revue introductive n'a pas de sens.

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'automates.

1.5.4. Diagramme d'activité

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

Un diagramme d'activité est une autre façon de décrire un comportement qui ressemble visuellement à un bon vieux diagramme de flux. Cependant, en raison de la notation modernisée, cohérente avec l'approche orientée objet, et surtout, en raison de 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.

Dans le diagramme d'activité, un type principal d'entités est utilisé - action 1 , et un type de relation - transitions 2 (transferts de contrôle et de données). Sont également utilisées des constructions telles que les fourches, les fusions, les connexions, les branches 3 , qui sont similaires aux entités, mais en fait elles ne le sont pas, mais représentent manière graphique images de quelques cas particuliers de relations à plusieurs endroits. La sémantique des éléments du diagramme d'activité est discutée en détail au chapitre 4. Les principaux éléments de notation utilisés dans le diagramme d'activité 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 du 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 particulière du système (ou un fragment d'un tel protocole). Dans la programmation orientée objet, la chose la plus essentielle à l'exécution est la transmission de messages entre des objets coopérants. C'est la séquence d'envoi des messages qui est affichée sur ce diagramme, d'où le nom.

Dans le diagramme de séquence, un type principal d'entités est utilisé - des instances de classificateurs en interaction 1 (principalement des classes, des composants et des acteurs) et un type de relation - des connexions 2 à travers lesquelles des messages sont échangés 3 . Il existe plusieurs manières d'envoyer des messages, qui en notation graphique se différencient par la forme d'une flèche correspondant à une relation.

Un aspect important du diagramme de séquence est l'affichage explicite du passage du temps. Contrairement à d'autres types de diagrammes, sauf peut-être pour les diagrammes de synchronisation, dans un diagramme de séquence, non seulement la présence de liens graphiques entre les éléments est importante, mais aussi la position relative des éléments sur le diagramme. A savoir, on considère qu'il existe un axe de temps (invisible), par défaut dirigé de haut en bas, et le message qui est envoyé plus tard est dessiné en dessous.

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

La figure suivante montre les principaux éléments de notation utilisés dans un diagramme de séquence. Pour désigner les objets en interaction eux-mêmes, la notation standard est utilisée - un rectangle avec le nom d'une instance de classificateur. Ligne pointillée, en sortant, s'appelle la ligne de vie (lifeline) 4 . Il ne s'agit pas de la désignation d'une relation dans le modèle, mais d'un commentaire graphique destiné à orienter le lecteur du diagramme dans la bonne direction. Les figures en forme de bandes étroites superposées à la ligne de vie ne sont pas non plus des images d'entités simulées. Il s'agit d'un commentaire graphique montrant la durée pendant laquelle un objet possède une occurrence d'exécution 5 ou en d'autres termes une activation d'un objet a lieu. Les étapes d'interaction composées (fragment combiné) 6 permettent au diagramme de séquence de refléter les aspects algorithmiques du protocole d'interaction. Voir le chapitre 4 pour plus de détails sur la notation des diagrammes de séquence.

1.5.6. Diagramme de communication

Diagramme de communication(diagramme de communication) - une manière de décrire le comportement, 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 de classificateurs en interaction, 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és 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 relations entre des instances spécifiques.

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

1.5.7. Diagramme des composants

Diagramme des composants(diagramme de composants) - montre la relation entre les modules (logiques ou physiques) qui composent le système simulé.

Le principal type d'entités dans le 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 le diagramme de composants :

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

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

1.5.8. Diagramme d'emplacement

Diagramme d'emplacement(diagramme de déploiement), en plus d'afficher la composition et les relations des éléments du système, montre comment ils sont physiquement situés sur les ressources informatiques pendant l'exécution.

Ainsi, dans le diagramme de placement, par rapport au diagramme de composants, deux types d'entités sont ajoutés : l'artefact 1 , qui est l'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), comme ainsi qu'une relation d'association entre nœuds 4, indiquant que les nœuds sont physiquement liés à l'exécution.

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