0. Introduction

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

OMG-SysML-final-sm-c

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ème INCOSE (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 ou www.omgsysml.org.

III. SysML : Présentation

SysML (Systems ModelingLanguage) est basé sur UML et remplace la modélisation de classes et d'objets par la modélisation de blocs 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.

C:\Documents and Settings\Djug\Bureau\UML2-SysML.png


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

image

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

  • Structurels
    • Le « Block Definition Diagram » (BDD) remplace le diagramme de classes
    • L' « Internal Block Diagram » (IBD) remplace le diagramme de structure composite
    • Le diagramme de paquetage reste inchangé
    • Le diagramme paramétrique est une extension SysML pour l'analyse de paramètres critiques du système
  • Dynamiques
    • Le diagramme d'activités est légèrement modifié pour SysML
    • Les diagrammes de séquence, d'états, et de cas d'utilisations restent inchangés
  • Le diagramme d'exigences est une extension SysML
image

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.

IV. Modélisation structurelle

IV-A. BDD : Block Definition Diagram

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.

image

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.

image

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.

image

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] »

image
image
  • 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 : image
  • 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 :
image


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 » :

image

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 :

image

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


IBD Assembly :

image

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

image

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 :
image


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

image

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.

image

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.

V-C. Diagramme d'activité

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.

image

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 :

image image

  • 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
image

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 

:image

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.

VI. Nouveautés SysML

VI-A. Exigences

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 exigences textuelles, 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) :

image


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

image

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 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 :

image

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) :

image

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)
    • 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 :

image

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 »
image
image

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.
image

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.

VI-C-3. 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 :

image

VII. 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

Cet article fait suite aux formations données par Objet Direct  sur la « modélisation des systèmes complexes avec UML2 et SysML ».

(Un descriptif complet de la formation est disponible sur http://www.objetdirect.com/html/formation/catalogue/MODSY.html)