Modélisation SysML

Table des matières

L'Ingénierie Système (IS), ou Systems Engineering en anglais (SE), est une démarche méthodologique
pour répondre à des problèmes complexes par la réalisation de solutions logicielles et matérielles.

L'Ingénierie Système s'adresse aux secteurs suivants de l'activité industrielle :

 Automobile
 Ferroviaire
 Aéronautique
 Espace
 Militaire
 Systèmes embarqués (ex : encodage/décodage vidéo et audio, set top box)
 Télécoms
 Santé/médical
 Production d'énergie, etc.

UML, langage de modélisation très répandu pour les développements logiciels, a été utilisé et adapté
pour définir un langage de modélisation des systèmes : SysML ou Systems Modeling Language. Dans
cet article nous présentons l'Ingénierie Système, un bref historique sur SysML, puis des explications sur
les modèles définis par SysML, illustrés par des exemples.

Le but de cet article est de présenter de façon non-exhaustive le langage SysML. En revanche ce
document ne traite pas des méthodologies à employer.

I. Ingénierie Système▲

Les méthodes de l'Ingénierie Système (IS) reposent sur des approches de modélisation et
de simulation pour valider les exigences, et pour vérifier ou évaluer le système. La modélisation a donc
couramment été utilisée pour l'IS, que ce soit pour des représentations concrètes avec des plans ou
modèles réduits, ou plus abstraites avec des systèmes d'équations.

En général l'IS tend à modéliser les aspects suivants du système: décomposition fonctionnelle, flux de
données, et décomposition structurelle. Exemples de techniques de modélisation employées :

 Le diagramme de flux de données (DFD ou Data Flow Diagram) pour définir les données traversant un système et
leurs traitements éventuels
 Le diagramme de flux fonctionnel de bloc (FFBD ou Functional Flow Block Diagram) proche du diagramme UML
d'activité ou du « flowchart »

Les spécifications issues de l'IS relèvent souvent d'une documentation dense due à une approche
orientée documentation (« document-based approach »), qui comporte généralement une sélection
inconsistante de différents types de diagrammes.

L'alternative consiste à effectuer une transition vers une « approche orientée modèles » (« model-based
systems engineering » ou MBSE), permettant de réaliser un modèle cohérent du système, stocké et géré
dans un référentiel, par exemple avec l'outil AGL Enterprise Architect de Sparx Systems.
Cette approche permet la réalisation d'un ensemble organisé de modèles, s'appliquant à différents
niveaux de granularités tels que l'aspect opérationnel (contexte et utilisation du système), l'aspect
fonctionnel (structure et sous-fonctions du système), et l'aspect physique (architecture). La modélisation
permet de maitriser la complexité du système étudié, car chaque modèle donne accès à une
représentation abstraite de différents aspects du système.

II. SysML : Historique▲

La modélisation avec le langage UML est une pratique bien établie dans l'industrie logicielle. Bien que
le langage UML permette par son caractère à usage général d'adresser de nombreux besoins pour l'IS, il
est nécessaire d'adapter ce langage de modélisation par la définition de « profils UML ». Plusieurs
projets ont été menés pour réaliser des profils UML sur des domaines spécifiques de l'IS :

 MARTE : profil UML pour des systèmes embarqués en temps-réel

 Profil UML SoC (System on a Chip)

Le besoin de définir un langage basé sur UML pour l'IS a été initié en 2001 par l'organisation
internationale de l'ingénierie systèmeINCOSE (International Council on Systems Engineering), qui s'est
mise en relation avec l'OMG (Object Management Group), organisme responsable d'UML, pour créer le
groupe d'intérêt spécialisé dans les domaines de l'IS ou « SE DSIG » (Systems Engineering Domains
Special Interest Group).

Suite à de nombreux ateliers, l'INCOSE et l'OMG ont défini et publié la demande de proposition « UML
pour l'IS » en 2003 (UML for SE RFP - Request For Proposal).

Plusieurs membres de l'industrie (BAE, Motorola, oose, Boeing.), éditeurs d'outils (IBM, Sparx
Systems.), universités et organisations (INCOSE, AP233) ont travaillés sur la définition du langage de
modélisation système SysML (Systems Modeling Language).

 Juillet 2006 : OMG annonce l'adoption de SysML

 Septembre 2007 : spécifications de la version 1.0 rendues officielles
 Décembre 2008 : SysML v1.1
 Juin 2010 : SysML v1.2 (version actuelle)

Les spécifications de SysML, tout comme UML, sont disponibles gratuitement en anglais depuis le site
de l'OMG : www.omg.org ouwww.omgsysml.org.

III. SysML : Présentation▲

SysML (Systems Modeling Language) est basé sur UML et remplace la modélisation de classes et
d'objets par la modélisation deblocs pour un vocabulaire plus adapté à l'Ingénierie Système. Un bloc
englobe tout concept logiciel, matériel, données, processus, et même la gestion des personnes.

Comme représenté sur le diagramme suivant, SysML réutilise une partie d'UML2 (« UML 4 SysML »
ou « UML pour SysML »), et apporte également ses propres définitions (extensions SysML). SysML
n'utilise donc pas les 13 diagrammes définis par UML 2, permettant ainsi d'accéder à un ensemble de
diagrammes accessibles et adaptés à l'IS.

UML4SysML :

 Diagramme de séquences
 Diagramme d'états
 Diagramme de cas d'utilisations
 Diagramme d'activités
 Diagramme de paquetage
 Diagrammes de classe et structure composite (utilisés pour les diagrammes de définitions de blocs et de bloc interne
- BDD & IDB)

Extensions SysML :

 Définitions pour les diagrammes de définitions de blocs et de bloc interne - BDD & IDB
 Modifications dans le diagramme d'activités
 Diagramme d'exigences (requirements) - Nouveau
 Diagramme paramétrique - Nouveau
 Allocations (traçabilité) - Nouveau
Les diagrammes définis sous UML2, et ceux qui constituent SysML sont représentés ci-dessous. Hormis
les nouveautés, la majorité des changements apportés par SysML se trouvent dans les diagrammes
structurels.

UML2 : 13 diagrammes - 6 structurels, et 7 dynamiques

SysML : 9 diagrammes - 4 structurels, 4 dynamiques, et le diagramme d' exigences :

 Structurels
o Le « Block Definition Diagram » (BDD) remplace le diagramme de classes
o L' « Internal Block Diagram » (IBD) remplace le diagramme de structure composite
o Le diagramme de paquetage reste inchangé
o Le diagramme paramétrique est une extension SysML pour l'analyse de paramètres critiques du système
 Dynamiques
o Le diagramme d'activités est légèrement modifié pour SysML
o Les diagrammes de séquence, d'états, et de cas d'utilisations restent inchangés
 Le diagramme d'exigences est une extension SysML
Ainsi SysML permet de fournir un référentiel central qui supporte les analyses du système requises par
l'IS, à savoir la décomposition fonctionnelle, les flux de données, et la décomposition structurelle.

Cet article se poursuit par un aperçu de chacun des 9 diagrammes proposés par SysML, en commençant
par la structure du système, suivi par le comportement du système (modélisation dynamique), et en
terminant par les nouveautés de SysML (i.e. exigences, diagramme paramétrique). Les nouveautés
SysML comprennent également les allocations, qui permettent d'améliorer la traçabilité.

Cet ordre ne définit en aucun cas la méthodologie à suivre pour modéliser un système ; le sujet de cet
article est la présentation du langage SysML et non les méthodologies appliquées aux projets. A noter
que lors du déroulement d'un projet, il est courant que la modélisation structurelle s'effectue en parallèle
avec la modélisation dynamique, souvent par cycles ou itérations. La modélisation du système permet
également de travailler à différents niveaux de granularités. ▲

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 lebloc 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 :
o un échangeur de chaleur (HeatExchanger) qui a un rôle de condensateur (condenser)
o une bouilloire (Boiler) qui a un rôle d'évaporateur (evaporator)
o 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.
o 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
o 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.

IV-B. IBD : Internal Block Diagram▲

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
autre 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'IBDest 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 autre par la complexité et la lourdeur de chaque
diagramme, ainsi que les besoins éventuels de réutilisation des blocs.
 IV-C. Value Types▲

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 celcius et dimension = nulle. L'unit « degrés celcius» 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).

IV-D. Diagramme de paquetage▲

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

V. Modélisation dynamique▲
La modélisation de l'aspect dynamique du système avec SysML repose sur une sélection de quatre
diagrammes UML2 : diagrammes de cas d'utilisations, de séquence, d'activité, et d'états.

Parmi ces diagrammes, seul le diagramme d'activité comporte quelques modifications pour SysML.

V-A. Diagramme de cas d'utilisations▲

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 pre conditions,
post conditions, scénario nominal, scénarios alternatifs et d'erreur.

V-B. Diagramme de séquence▲

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étails 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 vies 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
 V-D. Diagramme d'états▲

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êts 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 des 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 exigencestextuelles, permet une organisation
hiérarchique et l'association avec les éléments du modèle.

SysML définit de nouveaux types de 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é

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 :
 VI-B. Diagramme paramétrique▲

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 desblocs 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 constraint property), 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èmes 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)
o 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 elle (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èmes. Ces expressions et valeurs peuvent être alors exécutées par le module de simulation Enterprise
Architect comme illustré ci-dessous :

VI-C. Allocations▲
Le concept d'allocation est repris du vocabulaire des ingénieurs systèmes, 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 diagramme d'activité et IBD▲

Lors de la modélisation d'un processus, par exemple « purifier l'eau » (ou activité « Distill Water » du
bloc Distiller), les allocations sont utilisées pour associer le flux d'objet entre deux actions ou activités
(modélisation dynamique) avec un connecteur entre deux parties (instances de bloc) d'un diagramme
interne de bloc IBD (modélisation structurelle). En effet un flux d'objet dans un diagramme d'activité
devrait avoir une correspondance avec un des connecteurs d'un diagramme de bloc interne.

Dans l'exemple ci-dessous, chacun des flux d'objets entre actions sont alloués à un connecteur de l'IBD
(ou plus précisément dans ce cas un item flow).

 Le flux d'objet entre le port du bloc Distiller « cold dirty (H2O) » i.e. de l'eau froide et sale, et
l'action pour chauffer l'eau (« a1 : Heat Water ») est alloué au connecteur « main1 : H2O ». Sur
l'IBD, on retrouve en effet main1 comme l'eau qui circule depuis l'entrée du bloc Distiller vers
l'entrée du bloc de l'échangeur de chaleur (Heat Exchanger). Les diagrammes IBD et d'activité sont
ainsi cohérents, et indiquent pour la suite de la modélisation que l'action « Heat Water » devra être
exécutée par le bloc « Heat Exchanger »
VI-C-2. Allocations entre diagramme d'activité et BDD▲
SysML permet d'utiliser les swimlanes d'UML afin d'allouer les actions et activités aux blocs. Le
diagramme d'activité « purifier l'eau » présenté précédemment a été amélioré dans le diagramme ci-
dessous afin de spécifier les swimlanes d'allocations vers des blocs du système :

 Par exemple les actions Heat Water et Condense Steam sont présentes dans le swimlane
d'allocation au bloc HeatExchanger exécutant le rôle « condenser » vis-à-vis du bloc principal, le
Distiller. Ainsi cette allocation devrait donner lieu à une nouvelle opération pour chacune des deux
actions dans le bloc HeatExchanger.

Note : l'outil de modélisation utilisé, par exemple EA, permet de retrouver le bloc depuis le diagramme
d'activité, ou vice versa de retrouver toutes les allocations d'activités ou d'actions pour un bloc du
modèle.. Allocations entre IBDs▲

Le dernier type d'allocation permet la traçabilité entre différents niveaux d'analyse et de conception, par
exemple entre la représentation abstraite d'un bloc, et sa représentation concrète. Ceci est illustré par
l'exemple des spécifications SysML de l'OMG :
 Outils SysML▲

Le langage SysML a été intégré dans de nombreux outils AGL, commerciaux ou open source:

 Sparx Systems Enterprise Architect (plugin SysML ou version Ultimate requise)

 IBM Rational Software Modeler (plugin d'une société tierce disponible)
 Magicdraw (plugin SysML requis)
 Open source : Topcased (environnement Eclipse)

VIII. Pour en savoir plus▲