Présentation des modèles, des classes et des relations
Un langage dédié (DSL) est défini par son fichier de définition DSL, ainsi que tout code de programme personnalisé que vous pouvez écrire. La majeure partie du code de programme dans la solution DSL est générée à partir de ce fichier.
Cette rubrique explique les fonctionnalités centrales de la définition DSL.
Définition DSL
Quand vous ouvrez Dsl\DslDefinition.dsl, votre fenêtre Visual Studio ressemble à l’image suivante.
Les informations les plus importantes de la définition DSL sont affichées dans le diagramme de définition DSL. Des informations supplémentaires, qui font également partie de DslDefinition.dsl, sont affichées dans l’Explorateur DSL, qui s’affiche généralement sur le côté du diagramme. Vous utilisez le diagramme pour les tâches les plus fréquentes et l’Explorateur DSL pour des personnalisations plus avancées.
Le diagramme de définition DSL montre les classes de domaine qui définissent les éléments de modèle et les relations qui définissent les liens entre les éléments de modèle. Il affiche également les formes et les connecteurs utilisés pour montrer les éléments de modèle à l’utilisateur.
Quand vous sélectionnez un élément dans la définition DSL, dans le diagramme ou dans l’Explorateur DSL, les informations le concernant s’affichent dans la fenêtre Propriétés. Des informations supplémentaires peuvent être affichées dans la fenêtre Détails DSL.
Les modèles sont des instances des DSL
Un modèle est une instance de votre DSL créée par un utilisateur. Un modèle contient des éléments de modèle, qui sont des instances des classes de domaine que vous définissez, et des liens entre les éléments, qui sont des instances des relations de domaine que vous définissez. Un modèle peut également avoir des formes et des connecteurs, qui affichent les éléments de modèle et les liens dans un diagramme. La définition DSL comprend les classes de forme, les classes de connecteur et une classe pour le diagramme.
Une définition DSL est également appelée modèle de domaine. Une définition DSL ou modèle de domaine est la représentation au moment de la conception du langage dédié, tandis que le modèle est l’instanciation au moment de l’exécution du langage dédié.
Les classes de domaine définissent les éléments de modèle
Les classes de domaine sont utilisées pour créer les différents éléments dans le domaine, et les relations de domaine sont les liens entre les éléments. Il s’agit de la représentation au moment de la conception des éléments et des liens que les utilisateurs du langage dédié vont instancier quand ils créent leurs modèles.
Cette illustration montre un modèle qui a été créé par l’utilisateur d’une bibliothèque de musique DSL. Les albums musicaux sont représentés par des zones qui contiennent des listes de chansons. Les artistes sont représentés par des boîtes arrondies, et sont reliés aux albums auxquels ils ont contribué.
La définition DSL sépare deux aspects. L’apparence des éléments de modèle sur le diagramme de modèle est définie avec des classes de forme et des classes de connecteur. Les informations contenues dans le modèle sont définies avec des classes de domaine et des relations de domaine.
L’illustration suivante montre les classes et les relations de domaine dans la définition DSL de la bibliothèque de musique.
L’illustration montre quatre classes de domaine : Music, Album, Artist et Song. Les classes de domaine définissent des propriétés de domaine comme Name, Title, etc. Dans le modèle d’instance, les valeurs de certaines de ces propriétés sont affichées sur le diagramme.
Entre les classes se trouvent des relations de domaine : MusicHasAlbums, MusicHasArtists, AlbumbHasSongs et ArtistAppearedOnAlbums. Les relations ont des multiplicités de type 1..1, 0..*. Par exemple, chaque chanson (Song) doit être liée à un seul Album à travers la relation AlbumHasSongs. Chaque Album peut avoir n’importe quel nombre de chansons (Songs).
Réorganisation du diagramme de définition DSL
Notez qu’une classe de domaine peut apparaître plusieurs fois dans le diagramme de définition DSL, comme c’est le cas d’Album dans cette image. Il existe toujours une vue principale, et il peut y avoir des vues de référence.
Pour réorganiser le diagramme de définition DSL, vous pouvez :
Échangez les vues principales et de référence en utilisant les commandes Déplacer l’arborescence ici et Fractionner l’arborescence. Cliquez avec le bouton droit sur une seule classe de domaine pour voir ces commandes.
Réorganisez les classes de domaine et les classes de forme en appuyant sur Ctrl+Haut et Ctrl+Bas.
Réduisez ou développez des classes en utilisant l’icône située en haut à droite de chaque forme.
Réduisez des parties de l’arborescence en cliquant sur le signe moins (-) en bas d’une classe de domaine.
Héritage
Les classes de domaine peuvent être définies avec l’héritage. Pour créer une dérivation d’héritage, cliquez sur l’outil Héritage, sur la classe dérivée, puis sur la classe de base. Un élément de modèle a toutes les propriétés définies sur sa propre classe de domaine, ainsi que toutes les propriétés héritées de la classe de base. Il hérite également de ses rôles dans les relations.
L’héritage peut également être utilisé entre les relations, les formes et les connecteurs. L’héritage doit rester dans le même groupe. Une forme ne peut pas hériter d’une classe de domaine.
Relations de domaine
Les éléments de modèle peuvent être liés par des relations. Les liens sont toujours binaires, ils lient exactement deux éléments. Toutefois, n’importe quel élément peut avoir de nombreux liens vers d’autres objets, et il peut même y avoir plusieurs liens entre la même paire d’éléments.
Tout comme vous pouvez définir différentes classes d’éléments, vous pouvez définir différentes classes de liens. La classe d’un lien est appelée relation de domaine. Une relation de domaine spécifie les classes d’élément que ses instances peuvent connecter. Chaque extrémité d’une relation est appelée rôle, et la relation de domaine définit des noms pour les deux rôles, ainsi que pour la relation elle-même.
Il existe deux types de relations de domaine : les relations d’imbrication et les relations de référence. Dans le diagramme de définition DSL, les relations d’imbrication ont des lignes pleines au niveau de chaque rôle, et les relations de référence ont des lignes en pointillés.
Relations d’imbrication
Chaque élément d’un modèle, à l’exception de sa racine, est la cible d’un lien d’imbrication. Par conséquent, l’ensemble du modèle forme une seule arborescence de liens d’imbrication. Une relation d’imbrication représente une autonomie ou une propriété. Deux éléments de modèle qui sont liés de cette façon sont également appelés parent et enfant. L’enfant est imbriqué dans le parent.
Les liens d’imbrication ne sont généralement pas affichés explicitement comme des connecteurs sur un diagramme. À la place, ils sont généralement représentés par une autonomie. La racine du modèle est représentée par le diagramme, et les éléments imbriqués sont affichés comme des formes sur le diagramme.
Dans l’exemple, la classe racine Music a une relation d’imbrication MusicHasAlbums vers Album, qui a une imbrication AlbumHasSongs vers Song. Les chansons (Songs) sont affichées comme des éléments dans une liste à l’intérieur de chaque Album. Music a également une relation d’imbrication entre MusicHasArtists et la classe Artist, dont les instances apparaissent également comme des formes dans le diagramme.
Par défaut, les éléments imbriqués sont automatiquement supprimés quand leurs parents sont supprimés.
Quand un modèle est enregistré dans un fichier au format XML, les éléments incorporés sont imbriqués à l’intérieur de leurs parents, sauf si vous avez personnalisé la sérialisation.
Notes
L'incorporation n'est pas la même chose que l'héritage. Les enfants d’une relation d’imbrication n’héritent pas les propriétés du parent. Une imbrication est un type de lien entre des éléments de modèle. L’héritage est une relation entre des classes et ne crée pas de liens entre les éléments de modèle.
Règles d’imbrication
Chaque élément d’un modèle d’instance doit être la cible d’un seul lien d’imbrication, à l’exception de la racine du modèle.
Par conséquent, chaque classe de domaine qui n’est pas une classe abstraite, sauf la classe racine, doit être la cible d’au moins une relation d’imbrication ou doit hériter une imbrication d’une classe de base. Une classe peut être la cible de deux imbrications ou plus, mais ses éléments de modèle d’instance peuvent avoir un seul parent à la fois. La multiplicité de la cible à la source doit être 0..1 ou 1..1.
L’Explorateur affiche l’arborescence d’imbrication
Votre définition DSL crée également un explorateur, que les utilisateurs voient à côté de leur diagramme de modèle.
L’explorateur affiche tous les éléments du modèle, même ceux pour lesquels vous n’avez défini aucune forme. Il montre les éléments et les relations d’imbrication, mais pas les relations de référence.
Pour voir les valeurs des propriétés de domaine d’un élément, l’utilisateur sélectionne un élément, dans le diagramme de modèle ou dans l’Explorateur de modèles, puis ouvre la fenêtre Propriétés. Il affiche toutes les propriétés de domaine, y compris celles qui ne sont pas affichées dans le diagramme. Dans l’exemple, chaque Song a à la fois un Title et un Genre, mais seule la valeur du Title est affichée dans le diagramme.
Relations de référence
Une relation de référence représente tous les types de relation qui ne sont pas une imbrication.
Les relations de référence sont généralement affichées dans un diagramme comme des connecteurs, qui sont des lignes entre des formes.
Dans la représentation XML du modèle, un lien de référence entre deux éléments est représenté avec des monikers. Autrement dit, les monikers sont des noms qui identifient de manière unique chaque élément du modèle. Le nœud XML de chaque élément de modèle contient un nœud qui spécifie le nom de la relation et le moniker de l’autre élément.
Rôles
Chaque relation de domaine a deux rôles, un rôle source et un rôle cible.
Dans l’image suivante, la ligne entre la classe de domaine Publisher et la relation de domaine PublisherCatalog est le rôle source. La ligne entre la relation de domaine et la classe de domaine Album est le rôle cible.
Les noms associés à une relation sont particulièrement importants quand vous écrivez du code de programme qui traverse le modèle. Par exemple, quand vous générez la solution DSL, la classe Publisher générée a une propriété Catalog qui est une collection d’Albums. La classe Album a une propriété Publisher qui est une seule instance de la classe Publisher.
Quand vous créez une relation dans une définition DSL, les noms de propriété et de relation reçoivent des valeurs par défaut. Toutefois, vous pouvez les changer.
Multiplicités
Les multiplicités spécifient le nombre d’éléments pouvant avoir le même rôle dans une relation de domaine. Dans l’exemple, le paramètre de multiplicité zéro-à-plusieurs (0..*) sur le rôle Catalog spécifie que n’importe quelle instance de la classe de domaine Publisher peut avoir autant de liens de relation PublisherCatalog que vous souhaitez.
Configurez la multiplicité d’un rôle en tapant dans le diagramme ou en modifiant la propriété Multiplicity dans la fenêtre Propriétés. Le tableau suivant décrit les paramètres de cette propriété.
| Type de multiplicité | Description |
|---|---|
| 0..* (Zéro à plusieurs) | Chaque instance de la classe de domaine peut avoir plusieurs instances de la relation ou aucune instance de la relation. |
| 0..1 (Zéro à un) | Chaque instance de la classe de domaine peut avoir une seule instance de la relation ou aucune instance de la relation. |
| 1..1 (Un) | Chaque instance de la classe de domaine peut avoir une instance de la relation. Vous ne pouvez pas créer plusieurs instances de cette relation à partir d’une instance de la classe de rôle. Si la validation est activée, une erreur de validation s’affiche quand une instance de la classe de rôle n’a aucune instance de la relation. |
| 1..* (Un à plusieurs) | Chaque instance de la classe sur le rôle qui a cette multiplicité peut avoir plusieurs instances de la relation, et chaque instance doit avoir au moins une instance de la relation. Si la validation est activée, une erreur de validation s’affiche quand une instance de la classe de rôle n’a aucune instance de la relation. |
Relations de domaine sous forme de classes
Un lien est représenté dans le magasin comme une instance de LinkElement, qui est une classe dérivée de ModelElement. Vous pouvez définir ces propriétés dans le diagramme de modèle de domaine sur les relations de domaine.
Vous pouvez également faire d’une relation la source ou la cible d’autres relations. Dans le diagramme de modèle de domaine, cliquez avec le bouton droit sur la relation de domaine, puis cliquez sur Afficher comme une classe. Une zone de classe supplémentaire s’affiche. Vous pouvez ensuite y connecter des relations.
Vous pouvez définir une relation en partie par héritage, comme pour les classes de domaine. Sélectionnez la relation dérivée et définissez Relation de base dans la fenêtre Propriétés.
Une relation dérivée spécialise sa relation de base. Les classes de domaine qu’elle lie doivent être dérivées des classes liées par la relation de base ou les mêmes que ces classes. Quand un lien de la relation dérivée est créé dans un modèle, il s’agit d’une instance des relations dérivées et de base. Dans le code du programme, vous pouvez accéder à l’extrémité opposée du lien en utilisant les propriétés générées par la classe de base ou la classe dérivée.