Autres Relations Bloc

Les blocs sont les éléments structurels clés du SysML et peuvent participer à une variété de relations, dont certaines ont été abordées dans les sections précédentes du Guide lorsque nous parlions des associations. Il existe un certain nombre d'autres relations qui peuvent être utilisées lors de la définition des blocs.

Généralisation d'une relation de famille

Dans une section précédente, nous avons parlé de l'association de parties comme étant le type de relation d'association le plus fort, mais il existe une autre relation - la généralisation - qui est également très forte et est essentiellement utilisée pour modéliser le fait que les blocs (et d'autres classificateurs) appartiennent à la même famille. Le mot « classificateur » vient de nos langues naturelles, telles que le chinois et le thaï, qui ont une manière abstraite de classer ou de regrouper des classes de noms qui ont des caractéristiques similaires ; par exemple, une ceinture et une route sont des choses longues et minces, tandis qu'une baie et une balle sont des choses round . De même avec le SysML, la relation de généralisation est utilisée pour classer les choses et la structure peut avoir une profondeur arbitraire. À bien des égards, il est plus naturel pour les ingénieurs de lire la relation à l'envers et de dire que quelque chose est une version spécialisée de quelque chose.

Enterprise Architect permet à un ingénieur de créer ces hiérarchies de classification pour les blocs, les types de valeur, les signaux, les interfaces, les activités et plus encore. Un diagramme contient généralement une seule famille.

La relation peut être tracée en sélectionnant d'abord l'icône « Généralisation » dans la boîte à outils, puis en effectuant un glisser-déposer de l'élément le plus spécialisé vers l'élément le plus général. Alternativement, cela peut être fait en utilisant le Quick Linker.

Lorsqu'un Bloc participe à une hiérarchie de généralisation et possède plusieurs spécialisations, les connecteurs émanant du Bloc peuvent devenir désordonnés. Enterprise Architect fournit un mécanisme pour changer le style de ligne en l'un des nombreux styles, mais le style le plus utile est probablement le style d'arbre orienté verticalement, qui regroupe les têtes de la relation et permet à leurs queues d'être alignées en parallèle .

L'un des mécanismes de langage utiles qui résulte de la généralisation est que les éléments spécialisés héritent des fonctionnalités structurelles et comportementales de l'élément généralisé. Jusqu'à présent, dans les diagrammes d'exemple, l'ingénieur a choisi de ne pas afficher ces fonctionnalités héritées, mais elles peuvent être définies pour être affichées à l'aide des sections de compartiments de la feuille de propriétés de l'élément.

Le résultat sera que les blocs spécialisés afficheront les attributs et les opérations qui ont été hérités du Bloc parent. Ceux-ci seront affichés groupés par le nom du Bloc parent. Ce mécanisme est largement utilisé en génie logiciel mais est également utile pour l'ingénieur système où le Bloc spécialisé hérite automatiquement des fonctionnalités de son parent en vertu d'être un «membre de la famille». Tout comme dans une famille humaine, un Bloc spécialisé (enfant) peut remplacer les fonctionnalités structurelles ou comportementales héritées d'un parent.

Les blocs appartiennent à des familles basées sur certains critères, et cela peut être modélisé à l'aide de l'ensemble de généralisation, qui est un mécanisme utilisé pour définir la base de l'appartenance à une famille.

Dépendance

La dépendance est une relation utile mais sémantiquement faible. C'est le « pion » de la boîte à outils de relations des ingénieurs, souvent utilisé au début du processus de modélisation lorsque les détails des relations entre les éléments du système n'ont pas été analysés ou ne sont tout simplement pas connus. Il modélise le fait que l'élément (Client) à la fin de la relation s'appuie d'une certaine manière sur l'élément (Fournisseur) à la pointe de la flèche de la relation. On peut pardonner aux modélisateurs novices d'établir cette relation dans le sens inverse, car on pense souvent, de manière anecdotique, que le matériel passe dans le sens du fournisseur au client. Une fois que la sémantique de la relation est comprise et qu'il est réalisé que la relation ne dit rien sur la direction du flux, l'erreur ne sera pas commise.

Il existe un certain nombre de types de dépendances, qui sont tous pris en charge par Enterprise Architect . Le connecteur peut être créé en sélectionnant l'icône 'Dépendance' dans la page ' Relations du Bloc SysML' de la boîte à outils, puis en cliquant sur l'élément client (extrémité arrière) et en faisant glisser le curseur jusqu'à l'élément fournisseur (extrémité de la flèche). Le connecteur peut également être créé à l'aide de la flèche Quick Linker dans le coin supérieur droit d'un élément de diagramme sélectionné. Une fois la relation créée, un stéréotype peut être choisi dans la fenêtre Propriétés du connecteur pour préciser la dépendance. Cette capture d'écran montre tous les stéréotypes disponibles, dont certains sont utilisés entre différents types d'éléments autres que les blocs ; par exemple, Paquetages et Exigences .

Allocation entre blocs et activités

La relation d'allocation peut être utilisée dans diverses circonstances, mais elle est particulièrement utile pour exprimer une relation fondamentale entre les deux éléments Comportementale et structurels les plus canoniques, à savoir l'activité et le Bloc . Ceci est similaire à nos langues naturelles, où un verbe n'a pas de sens sans la présence d'un nom qui effectue l'action décrite par le verbe. Ce type d'allocation est appelé allocation fonctionnelle, et l'ingénieur comble le fossé entre ces deux aspects d'un système en trouvant un Bloc qui peut exécuter le comportement décrit par une activité.

Dans ce diagramme , l'ingénieur a créé deux relations d'allocation fonctionnelle qui décrivent comment le travail spécifié dans l'Activité Vérifier l'entrant sera effectué. Une relation cible le système de caméra qui est utilisé pour capturer la plaque d'immatriculation du véhicule afin de déterminer si le véhicule particulier a été autorisé à entrer. L'autre relation cible le Bloc lecteur de carte qui est utilisé pour déterminer que le propriétaire de la carte a une relation avec la station de stationnement.