Modélisation SysML

Le diagramme de définition de bloc (BDD, ou Block Definition Diagram en anglais) représente la vue boîte noire d'un bloc. Ainsi le bloc principal et la hiérarchie des blocs qui le composent, qu'ils soient logiciels ou matériels, sont spécifiés dans ce diagramme.

Le BDD est similaire à la première page d'une notice de montage d'un meuble, indiquant la liste des éléments et des pièces à assembler avec leurs quantités respectives.

Par rapport à UML, le BDD de SysML redéfinit le diagramme de classe en remplaçant les classes par des blocs. Le diagramme BDD ci-dessous provient de l'exemple OMG du purificateur d'eau.

Informations liées au diagramme de définition de bloc (BDD) :

• Les blocs sont représentés par des classes UML stéréotypées « block ».
• Le bloc principal définit le purificateur d'eau (bloc Distiller) composé de 3 blocs :
  • un échangeur de chaleur (HeatExchanger) qui a un rôle de condensateur (condenser)
  • une bouilloire (Boiler) qui a un rôle d'évaporateur (evaporator)
  • une soupape (Valve) qui a un rôle de drain
• Les trois blocs font physiquement partie du bloc principal (le purificateur d'eau), car les liens utilisés sur le diagramme sont des agrégations fortes ou compositions, représentées par un losange plein. Si un bloc n'en faisait pas physiquement partie, on parlerait alors d'une référence, et l'association utilisée serait une agrégation simple, représentée par un losange vide.
• Il est également possible d'employer des liens de généralisation (héritage) sur un BDD.
• On peut voir que certains aspects dynamiques du système ont déjà été modélisés en raison de la présence d'opérations (ex : l'opération 'boil water' dans le bloc Boiler).
• Les ports de flux (flow ports) est une nouveauté SysML ; les « flow ports » représentent ce qui peut circuler en entrée et/ou en sortie d'un bloc, que ce soit des données, de la matière ou de l'énergie.
  • Ainsi le bloc « Distiller » utilise en entrée de l'eau froide et de la chaleur externe, et produit en sortie de l'eau purifiée, du résidu, et de l'eau pour le bypass
  • Les ports des blocs qui composent le Distiller sont également représentés, indiquant comment ceux-ci peuvent être connectés lors de leur assemblage (modélisé dans le diagramme interne de bloc, l'IBD, traité dans le chapitre suivant)

Note : il est également possible de spécifier des « ports standards UML » qui exposent une ou plusieurs interfaces comme illustré ci-dessous.

Le diagramme de bloc interne (IBD, ou Internal Block Diagram) décrit la vue interne d'un bloc ou vue boîte blanche, et se base sur le BDD pour assembler les blocs qui composent le bloc principal.

Le bloc principal peut être représenté comme conteneur sur l'IBD ou être absent de ce diagramme. Les blocs qui le composent, définis dans le BDD, sont instanciés en parties (tout comme les parties dans un diagramme de structure composite avec UML2). Ces parties sont assemblées par des connecteurs qui relient leurs ports (ports standards avec interfaces exposées et/ou ports de flux).

Il est également possible de relier des parties directement entre elles, l'utilisation des ports étant optionnelle.

Par rapport à UML2, l'IBD de SysML redéfinit le diagramme de structure composite en ajoutant entre autres les ports de flux (« flow ports » en anglais).

Le diagramme IBD ci-dessous provient de l'exemple OMG du purificateur d'eau, et correspond au diagramme de définition de bloc BDD précédent.

Informations liées au diagramme int e rne de bloc ( I BD) :

• Le bloc principal du BDD est copié sur ce diagramme (Distiller est un bloc et non une partie) pour définir les parties qui le composent et les relier à ses ports.
• Les blocs du BDD qui composent le bloc principal sont instanciés en parties sur l'IBD, et sont de type Boiler, HeatExchanger et Valve. Ces parties sont stéréotypées « block ». La partie est intitulée comme suit : « rôle  :  nom du Bloc ». Le rôle d'une partie doit être cohérent avec les associations d'agrégation du BDD ; ainsi on retrouve le rôle « drain » défini dans le BDD avec l'agrégation entre les blocs Distiller et Valve sur la partie de l'IBD intitulée « drain : Valve ».

Note [1] : les parties sont représentées avec un rectangle en trait plein, indiquant qu'elles font physiquement partie du bloc principal, comme spécifié dans le diagramme BDD par le lien de composition. Si un lien d'agrégation simple est employé sur le diagramme BDD, on parle alors de référence, qui serait représentée en pointillés sur le diagramme IBD.

Note [2]: la multiplicité spécifiée sur une agrégation du diagramme BDD peut apparaitre sur l'IBD de façon cohérente comme illustré ci-dessous :

Le BDD a été modifié pour que le bloc Distiller contienne 2 instances du bloc Boiler, tous deux ayant le rôle d' evaporator . L'IBD est alors mis à jour pour indiquer la nouvelle multiplicité, par exemple «  evaporator : Boiler [2] »

• Tous les ports du bloc principal sont reliés par des connecteurs sur les ports des parties internes. Par exemple l'eau froide (port de flux cold dirty) est transmise en entrée à l'échangeur de chaleur (Heat Exchanger), dont la sortie h out est elle-même transmise à la sortie d'eau purifiée du Distiller (pure).
• La direction d'un flow port peut être définie en entrée, sortie, ou entrée/sortie. L'outil de modélisation représente cette direction par une flèche, par exemple pour une entrée :
• Alors que les ports indiquent ce qui peut passer par un bloc, les flux d'éléments ou « item flows » définissent ce qui passe entre deux blocs reliés par un connecteur. Par exemple l'IBD précédent spécifie que l'élément « externalHeat » circule entre le port d'entrée du Distiller et le port d'entrée du Boiler. externalHeat  est une instance du bloc Heat, défini comme suit :

Il est possible de spécifier plusieurs niveaux de compositions de bloc. Aussi dans le diagramme de définition de bloc BDD on peut par exemple rajouter un bloc « Assembly » lui-même comprenant un bloc « Valve » et un bloc « Tee Fitting » :

cliquez ici pour voir l'image en taille réelle

Lors de la modélisation interne des blocs par les diagrammes IBD, il y a alors deux possibilités :

1- Un diagramme pour chaque niveau : l'IBD du bloc Distiller et l'IBD du bloc Assembly

IBD Distiller :

cliquez ici pour voir l'image en taille réelle

IBD Assembly :

2- Un seul diagramme IBD pour bloc Distiller, avec les détails des sous-parties de la partie Assembly

cliquez ici pour voir l'image en taille réelle

Le choix entre ces diagrammes sera déterminé entre autres par la complexité et la lourdeur de chaque diagramme, ainsi que les besoins éventuels de réutilisation des blocs.

Les Value Types sont une nouveauté SysML pour définir des types de valeurs réutilisables pour des propriétés du modèle, par exemple des blocs. De façon similaire à la modélisation UML où les attributs de classes peuvent être typés par d'autres classes, SysML permet de définir des propriétés de blocs typées avec des Value Type.

La Value Type a la particularité de contenir 2 propriétés optionnelles : une unité et une dimension. Les unités et dimensions sont des classes spécialisées et définies dans le modèle, par exemple :

• Value Type « Distance » avec unit = mètres et dimension = longueur. L'unit « mètres » est définie avec dimension = nulle.
• Value Type « °C » avec unit = degrés Celsius et dimension = nulle. L'unit « degrés Celsius» est définie avec dimension = température :

L'exemple ci-dessous montre l'utilisation de la value type « °C » par une propriété du bloc H2O (waterTemp : °C).

Le diagramme de paquetage (ou package diagram en anglais) permet de structurer le modèle tout comme avec UML.

Tout comme avec UML, on utilise les diagrammes de cas d'utilisations :

• Basé sur les interactions acteurs/système, pour identifier les acteurs et les cas d'utilisations d'un point de vue utilisation du système
• Pour choisir et identifier les frontières, le périmètre fonctionnel du système

Une description textuelle pour chacun des cas d'utilisations peut être rédigée avec les préconditions, post conditions, scénario nominal, scénarios alternatifs et d'erreur.

Un cas d'utilisation représente les interactions entre un acteur et le système d'un point de vue « boite noire », et comprend l'ensemble des scénarios identifiés (nominal, alternatifs, et d'erreurs). Ces scénarios peuvent être détaillés par une description textuelle et/ou par un diagramme de séquence.

Le diagramme de séquence représente les éléments intervenant dans le scénario, ainsi que les messages échangés dans un ordre chronologique.

Dans un premier temps, on peut choisir de représenter les interactions entre l'acteur et le système (vue boite noire). Par la suite il est possible de rentrer en détail avec un diagramme de séquence qui représente les blocs internes du système intervenant dans un scénario (pour un message émis par l'acteur, le diagramme décrit l'enchainement des messages échangés entre les blocs internes du système) ; on parle ainsi de la vue boite blanche (comportement du système).

Les éléments intervenant sont représentés par des lignes de vie (lifetime en anglais).

Ces lignes de vie peuvent être des instances de blocs, établissant un lien avec la modélisation structurelle du système, permettant ainsi d'établir une cohérence dans le modèle :

• On peut accéder aux propriétés du bloc d'une ligne de vie (et également aux diagrammes de BDD et d'IBD de ce bloc)
• Chaque message échangé peut être utilisé pour l'identification des opérations de blocs

L'ensemble des propriétés du diagramme de séquence utilisées en UML sont également disponibles avec SysML : messages synchrones ou asynchrones, opérateurs (ex : alt, loop, opt, par), références vers d'autres diagrammes de séquence (ex : naviguer de la vue boite noire du scénario vers la vue boite blanche), etc.

Le diagramme d'activité est utilisé pour représenter les étapes d'un traitement. Avec SysML, les « input et output pins » sont particulièrement utilisés pour représenter le type d'élément qui est requis en entrée d'une activité ou action, et ce qui est généré en sortie.

Si une action ou activité représente l'opération d'un bloc, on peut garantir la cohérence du modèle en s'assurant que ce qui est défini en entrée d'une activité corresponde à la signature de l'opération du bloc ou de son interface.

Toutes les propriétés des diagrammes d'activités UML sont également disponibles avec SysML.

SysML a rajouté quelques spécificités :

• Notion de contrôle pour activer ou désactiver les actions en cours, comme illustré ci-dessous :

• Spécification de la nature du débit sur le flot : système continu ou discret
• Définition de taux et de probabilité sur les flots

Le diagramme d'états est utilisé avec SysML de la même manière qu'avec UML2, c'est-à-dire qu'il permet de représenter le cycle de vie auquel doivent se conformer toutes les instances d'un bloc donné, ce au travers de la modélisation de tous les états possibles.

Seuls les blocs qui sont importants d'un point de vue métier, ou qui sont de nature complexe, possèdent un diagramme d'état. Le diagramme suivant indique les états possibles pour le bloc H2O 

:

Les propriétés du diagramme d'état UML sont également disponibles avec SysML : conditions sur évènements, effets, activité durable, transitions, états composites, modularité, régions concurrentes, etc.

Que ce soit pour l'ingénierie système ou pour des réalisations logicielles, les exigences sont couramment utilisées pour formaliser les prérequis du système, se traduisant par des fonctionnalités ou conditions qui doivent ou devraient être satisfaites par le système (selon les éventuelles priorités associées aux exigences).

Pour la maîtrise d'ouvrage (MOA), les exigences ont pour objectif d'assurer l'adéquation de la solution (le système réalisé) avec les besoins. Les exigences peuvent être formalisées et catégorisées par centre d'intérêt ou aspects, par exemple différenciant les exigences fonctionnelles des exigences techniques (performance, fiabilité, ergonomie, etc.).

La formalisation des exigences peut être effectuée avec une feuille Excel, ou avec un outil spécialisé tel que DOORS ou CaliberRM. L'intérêt qu'offrent ces outils est la gestion des exigences dans une organisation structurée. Les exigences sont également utilisées pour la modélisation, par la création d'associations entre exigences et cas d'utilisations, blocs ou tout type d'élément du modèle, établissant une traçabilité. Il est possible avec l'outil Enterprise Architect de définir les exigences ou de les importer depuis un outil tel que DOORS, et de les associer avec les éléments du modèle.

SysML formalise les exigences et leur représentation, s'inspirant des fonctionnalités des outils actuellement disponibles sur le marché, par exemple EA, DOORS, CaliberRM. Ainsi SysML définit une représentation graphique et visuelle des exigences textuelles, permet une organisation hiérarchique et l'association avec les éléments du modèle.

SysML définit de nouveaux types d'associations (liens de dépendance stéréotypés) :

• Derive : une ou plusieurs exigences sont dérivées d'une exigence
• Satisfy: un ou plusieurs éléments du modèle (par exemple un bloc) permettent de satisfaire une exigence
• Verify: un ou plusieurs éléments du modèle (par exemple un « test case ») permettent de vérifier et valider une exigence
• Refine: un ou plusieurs éléments du modèle, par exemple un cas d'utilisation, redéfinit une exigence

SysML définit de nouveaux commentaires stéréotypés permettant d'associer une explication à des associations ou éléments du modèle :

• Problem: commentaire dont la description pose le problème ou le besoin qui a donné lieu à la création de l'association ou de l'élément associé
• Rationale: commentaire dont la description indique la raison ou la justification par rapport à l'élément ou l'association associés

Exemple d'associations et de commentaires des spécifications officielles de SysML (OMG) :

Exemple de représentation des exigences sous EA pour le système de purificateur d'eau :

Le diagramme paramétrique est une nouveauté SysML qui redéfinit le diagramme interne de bloc SysML (lui-même basé sur le diagramme de structure composite UML2), et permet d'intégrer des analyses systèmes (performance, fiabilité, etc.) avec des blocs de contrainte.

Un bloc de contrainte représente une expression mathématique dont les paramètres peuvent faire référence à des éléments du système, par exemple des propriétés de blocs.

Exemples de blocs de contraintes : {F=m*a}, {a=dv/dt}

Dans un premier temps, de façon similaire à la création du diagramme BDD, les blocs de contraintes sont définis dans un diagramme de classe, et représentés comme suit :

Après avoir défini les blocs de contrainte, il faut générer un diagramme paramétrique :

• Des blocs de contraintes sont instanciés, donnant lieu aux propriétés de contrainte (ou constraintproperty), héritant ainsi des paramètres du bloc de contrainte (note : il n'y a pas de différentiation entre paramètres d'entrée et paramètres de sortie)
• Des propriétés systèmes (optionnellement liées à des blocs)
• Des connecteurs reliant les propriétés systèmes aux paramètres des propriétés de contrainte, ou reliant uniquement des paramètres des propriétés de contrainte

Diagramme paramétrique basé sur un exemple de lecteur MP3 proposé par l'éditeur Sparx Systems (Enterprise Architect) :

cliquez ici pour voir l'image en taille réelle

Informations liées au diagramme paramétrique  :

• Le diagramme comporte six propriétés de contrainte, dont deux propriétés instanciées du même bloc de contrainte : Buffer.
• Les paramètres système sont catégorisés entre entrées et sorties (ex : amplitude et fréquence en entrée, output en sortie). Ces paramètres sont associés aux paramètres de propriétés de contrainte (par exemple la fréquence d'entrée f est reliée au paramètre f de la propriété de contrainte SineWave)
  • Note : dans ce diagramme les paramètres ne font pas référence aux blocs du modèle.
• Certaines propriétés de contrainte sont reliées entre elles (ex. : le paramètre SineWave.output est relié à Buffer.input et à Add.a)

Avec certains outils, ce diagramme peut être exécuté dans le cadre de simulation du système.

Il est possible sous Enterprise Architect de saisir des expressions pour chacun des blocs de contraintes (par exemple en VBScript ou JavaScript), ainsi que de renseigner différentes valeurs pour les paramètres système. Ces expressions et valeurs peuvent être alors exécutées par le module de simulation Enterprise Architect comme illustré ci-dessous :

Le concept d'allocation est repris du vocabulaire des ingénieurs système, indiquant un ensemble d'éléments associés dans un environnement structuré. La modélisation système implique des tentatives d'allocations entre éléments du système. Cet ensemble d'allocations est utilisé pour générer une matrice permettant de vérifier que plusieurs parties du système sont correctement intégrées.

La création d'allocations dans le modèle permet de maintenir une cohérence entre les éléments du système, en particulier entre les modèles dynamiques et les modèles structurels.

Plusieurs types d'allocations sont possibles :

VI-C-1. Allocations entre diagrammes d'activité et IBD▲

VI-C-2. Allocations entre diagrammes d'activité et BDD▲

VI-C-3. Allocations entre IBD▲