SysML par la pratique avec Papyrus

Il n’est pas dans les objectifs de ce livre d’explorer cette vaste question (voir [Jézéquel] ou [Cabot]), mais disons simplement que nous considérons la définition ci-dessus comme essentielle. Les modèles permettent de communiquer (entre personnes, entre outils) et d’appréhender la complexité des véritables systèmes en développement.

Ne considérez pas SysML® comme une palette de dessins et d’éléments de base servant à faire des diagrammes. SysML® permet de définir des éléments conceptuels et d’en faire une représentation graphique. Cette dernière est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus.

C’est pourquoi nous vous recommandons de ne jamais "dessiner" des diagrammes SysML® ^[2], mais d’utiliser des outils dédiés comme Papyrus-SysML. Ils respectent en général la norme SysML® 1.6.

Un des intérêts de la modélisation est de faciliter la communication, notamment au travers des diagrammes et leur aspect graphique et synthétique. Un dessin est donc un plus par rapport à du texte. Néanmoins, il ne faut pas se contenter d’un simple dessin pour au moins deux raisons importantes :

Un modèle est une sorte de base de donnée qui regroupe des éléments issues de différents points de vue (saisis le plus souvent au travers de diagrammes). Un diagramme est une vue partielle du modèle (donc incomplète). Le modèle est la vraie plus value car il va permettre de détecter les incohérences sur les exigences, les problèmes de complétude, lancer des analyses, faire des transformations vers d’autres langages ou formats, etc. Par exemple dans un outil de modélisation il y a une grande différence entre supprimer un élément d’un diagramme (on parlera alors de "masquer" un élément d’un diagramme) et supprimer un élément de modèle (ce qui aura pour effet de supprimer cet élément de tous les diagrammes où il était présent).

Dans un axe horizontal, nous avons différencié quatre grands points de vue :

Ces différents points de vue ne doivent pas être confondus avec les différentes phases de développement (cf. paragraphe suivant). Ils sont plutôt à rapprocher de la notion de préoccupation.

Dans un axe vertical, nous différencions cinq grandes phases du cycle de vie du développement :

Il s’agit ici classiquement des grandes étapes de développement d’un système. On pourrait être surpris par l’étape que nous avons appelé "Organisation". C’est une étape que nous considérons importante, particulièrement pour pour le travail en équipe (ou pour l’enseignement). Avant toute activité de modélisation ou même de développement, il convient en effet de s’organiser en termes de choix d’outils, choix d’environnements, conventions, etc. Cette étape est souvent négligée par les étudiants. C’est pour cela que nous avons décidé de faire figurer cette étape de manière explicite.

Comme n’importe quel autre logement, la Maison Intelligente de Blagnac doit être sécurisée. Notre système à concevoir doit donc fournir un certain niveau de protection contre les intrus et les voleurs. Ce niveau doit même être renforcé du fait de la vulnérabilité induite par l’ultra-connectivité du système. On profitera donc avantageusement du niveau d’équipement pour mettre en place les réponses adaptées (alarmes, alertes automatiques, etc.) sans pour autant oublier de donner un accès privilégié aux différents acteurs de la supervision (pompiers, médecins, etc.). L’accès aux données personnelles, notamment de santé, via les différents dispositifs connectés sera fortement contrôlé. Les notions d’identification, de certification ou de cryptage seront donc primordiales.

Le système à concevoir doit également pouvoir s’adapter aux conditions physiques et mentales de l’occupant^[3]. Par exemple, la hauteur des équipements de cuisine (meubles, éviers) s’abaisse automatiquement si l’occupant est en fauteuil roulant. Un autre exemple, qui concerne les personnes atteintes de troubles cognitifs, est la possibilité de guider l’occupant par la voix ou par un signal lumineux au sol, d’un point à un autre de la maison, par exemple le matin pour guider l’habitant(e) de son lit à la salle de bain. Le système doit également permettre de configurer les nombreux équipements en fonction des préférences de l’occupant (par exemple, heure de fermeture des volets ou du réveil, etc.).

Une des caractéristiques des maisons intelligentes modernes est leur prise en compte de l’environnement et donc des consommations énergétiques. L’objectif peut être économique, légal (conformité à une norme ou un label), ou simplement social. Par exemple le système pourra abaisser la température de la maison à certains moments (programmés ou opportuns). Les dispositifs inutiles à certains moments de la journée pourront être mis en sommeil sommeil à certains moments de la journée, ou bien encore les débits Internet réduits. La maison pourra aussi être autonome en énergie, ou tout le moins, produire dans une certaine mesure sa propre énergie (éolienne, panneaux solaires, etc.).

Vérifiez que vous possédez bien sur votre machine : Papyrus-SysML 2019-09 (ou une version supérieure).

Si ce n’est pas le cas, installez-le ou mettez-le à jour. Nous vous conseillons d’installer Papyrus-SysML de cette façon plutôt que de le rajouter comme un plugin de votre installation eclipse.

Il vous faut ensuite installer le profil SysML® (version 1.6). Pour cela, deux possibilités :

Si vous souhaitez travailler avec Git pour versionner vos modèles ou travailler de manière collaborative, ou si vous souhaitez utiliser des éléments avancés de Papyrus-SysML, rendez-vous au Chapitre 11.

Voici à quoi pourrait ressembler la fiche d’identité de SysML® :

Comme toutes les spécifications issues de l’OMG™, SysML® est sujet à des évolutions incrémentales qui permettent d’améliorer constamment le langage au travers de ce que l’on appelle des RTF (Revision Task Force). Les évolutions de SysML® sont pilotées par deux consortiums : l’OMG™ d’une part pour les liens avec UML® et l’INCOSE d’autre part pour les liens avec l’ingénierie système.

Il est intéressant de rappeler que SysML® est un standard qui vient des utilisateurs, qui participent à sa définition et à ses évolutions. Voici une liste non exhaustive des entreprises et des acteurs qui participent à son évolution :

Sachez que vous aussi vous pouvez participer à l’effort de normalisation et améliorer ainsi la spécification. En effet, il vous suffit pour cela de lever une issue via ce service fournit par l’OMG™ : https://issues.omg.org/issues/create-new-issue. Et c’est l’objet des groupes de travail précédemment mentionnés (RTF) que de répondre à ces rapports de bugs en modifiant le cas échéant la spécification si elle est jugée pertinentes par l’équipe. Donc, si quelque chose ne va pas du côté de SysML®, n’hésitez pas à remonter l’information, c’est la meilleure des façons de faire avant les choses. Enfin, si vous souhaitez faire avancer encore plus vite des changements, vous pouvez également participer à cette aventure de normalisation en devenant membre de l’OMG™.

Nous l’avons déjà évoqué, mais il convient d’insister, SysML® n’est pas :

La Figure 7, extraite de la spécification officielle, résume bien les liens entre SysML® et UML®, à savoir que SysML® d’une part du point de vue sémantique reprend une partie seulement des concepts d’UML® (appelée UML4SysML), en exclue en certain nombre et en ajoute d’autre. D’autre part du point de vue syntaxique, SysML® reprend une partie des diagrammes, en propose des spécialisations et en ajoute un nouveau.

SysML® et UML® sont parfois utilisés de manière complémentaire, mais la plupart du temps, UML® est utilisé pour modéliser les aspects logiciels et SysML® pour modéliser les systèmes.

Il va de soit que le meilleur outil SysML® à ce jour est Papyrus-SysML^[7]. Ce livre vous en détaille l’utilisation, mais il existe un certain nombre d’autres outils permettant de réaliser des modèles SysML®. En voici une liste non exhaustive (ils sont pour la plupart payants) :

Les ingénieurs systèmes ont l’habitude d’utiliser des représentations graphiques comme des plans et des graphiques. SysML® propose de couvrir la modélisation d’un système au travers de 9 diagrammes permettant d’aborder les aspects structurels et comportementaux du système ainsi que les exigences. La Figure 8 présente cette organisation en faisant, en même temps, le lien avec ceux d’UML® :

Le nom de ces diagrammes revenant souvent dans ce document, nous utiliserons souvent leur version abrégée (uc pour "diagramme des cas d’utilisation" par exemple). Ces abréviations, sont définies dans la spécification.

Abordons quelques principes généraux de SysML®, c’est-à-dire des éléments indépendants d’un diagramme en particulier :

Dans l’exemple illustré par la Figure 10, le diagramme nommé "Context_Overview" est un diagramme de type Block Definition Diagram (type bdd) et il représente un package, nommé "Context".

Comme nous l’avons vu précédemment les deux grandes catégories de diagrammes SysML® sont les diagrammes structuraux et les diagrammes comportementaux. Mis à part les deux diagrammes des exigences (req, représentation visuelle des exigences) et de paquetages (pkg, représentation visuelle des packages), les autres diagrammes nécessitent de préciser l’utilisation que nous préconisons d’en faire.

Pour les diagrammes structuraux (souvent aussi qualifiés de statiques), il s’agira de les utiliser pour représenter des préoccupations de nature architecturale statique. Plus précisément, quand il s’agit d’illuster des principes architecturaux d’un système, nous utiliserons volontiers les diagrammes de définition de blocs (bdd), et pour représenter les détails de l’intérieur d’un sous-système, nous utiliserons alors plus naturellement les diagramme de blocs internes (ibd). Enfin, nous utiliserons le diagramme paramétrique (par) – qui au passage n’est qu’un diagramme de blocs internes dédié aux relations entre valeurs – pour représenter des contraintes entre les propriétés des différents éléments qui constitue un système.

Pour les diagrammes comportementaux (souvent aussi appelés dynamiques), nous faisons la distinction entre un comportement global et un comportement local, comme illustré dans la Figure 11. Ainsi les diagrammes des cas d’utilisation (uc) et de séquences (sd) seront plutôt utilisés pour représenter le comportement global d’un système tel qu’attendu par les parties prenantes du système. Tandis que les diagrammes d’activité (act) et les diagrammes de machines à états (stm) seront plutôt utilisés en phase de conception pour détailler le comportement d’un block système. On utilisera volontiers les diagrammes de machine à états pour décrire un comportement logique où l’historique de l’objet est important par rapport à son comportement et on utilisera les diagrammes d’activité pour décrire un comportement de type algorithmique.

Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan des sections qui suivent (nous utilisons ici le "plan" vu lors de l’introduction de la Section 2.3) :

Ce diagramme permet de représenter graphiquement les exigences et leurs relations. Il sera vu plus en détail dans la section Section 9.1, mais en voici un exemple appliqué à la Maison Intelligente de Blagnac : une exigence (Security) est complsée de plusieurs sous-exigences.

Il est souvent plus pratique de lister les exigences sous forme de table.

Tous ces éléments seront détaillés à la Section 9.1.

Le diagramme de séquences permet de représenter les différents participants (dont la ligne de vie représente une chronologie des événements) et les échanges de messages entre eux.

Les éléments graphiques utilisés dans ce diagramme sont principalement :

Tous ces éléments seront détaillés à la [seq].

Les diagrammes de séquences système (dss) sont des diagrammes de séquences classiques où seul le système est représenté comme une boîte noire en interaction avec son environnement (les utilisateurs ou les périphériques généralement).

Il permet de décrire les scénarios des cas d’utilisation sans entrer dans les détails. Il convient donc mieux à l’ingénierie système qu’un diagramme de séquences classique.

xxx à refaire à partir de SHS xxx

Commençons à manipuler Papyrus-SysML avec un premier diagramme…​

Pour notre modélisation du SmartHomeSystem, nous utilisons l’organisation suivante^[9] :

Comme vous pouvez le constater, nous annotons les éléments de modèles avec des commentaires, et pas seulement parce qu’il s’agit d’un exemple illustratif pour un livre, comme nous le détaillons dans la section suivante.

Il est important de documenter les modèles. Si vous souhaitez ensuite pouvoir générer une documentation intéressante (cf. section [Gen2Doc]) ou analyser automatiquement les commentaires.

Si vous souhaitez simplement obtenir des figures à partir de vos diagrammes :

Le meilleur moyen de générer une documentation à partir des modèles Papyrus-SysML est d’utiliser le complément Model2Doc. Pour cela installez le complément eclipse en utilisant le site suivant : https://download.eclipse.org/modeling/mdt/papyrus/components/model2doc/.

Blabla sur cette partie en générale.

Nous proposons d’organiser le modèle en 2 packages séparant clairement les aspects développement (projet) et les aspects produit (système), conformément aux préconisations de CESAM.

Pour réaliser ce diagramme en Papyrus-SysML :

Suite de l’organisation …​

Parlez de l’organisation des stakeholders en packages (Key blabla). TIP: Parler des ElementGroup ⇒ organisation logique (adopté par SysML 2.0)

Blabla sur cette partie en générale.

Les acteurs sont bien connus de SysML® / UML®. Nous allons donc utilise un diagramme des cas d’utilisation pour lister les parties prenantes et leur hiérarchie éventuelle. Nous placerons ensuite dans un Block Definition Diagrams le système (le SmartHomeSystem dans notre exemple) et ses interactions avec les parties prenantes. Pour représenter les flux, SysML® possède le concept d'Item Flow, qui correspond parfaitement à ce besoin.

Blabla sur cette partie en générale.

Blabla sur cette partie en générale.

Blabla sur cette partie en générale.

Les exigences sont prises en compte à différent niveaux en SysML®. Nous aborderons :

Il ne s’agit pas ici de revenir sur les exigences elles-même, mais plutôt de voir comment SysML® permet de les exprimer, de les manipuler et surtout de les lier avec le reste du système.

Il est possible d’indiquer un certain nombre de propriétés sur un requirement :

Les principales relations entre requirement sont :

Il existe ensuite les relations entre les besoins et les autres éléments de modélisation (les block principalement) comme <<satisfy>> ou <<verify>>, mais nous les aborderons dans la partie transverse.

Voici un exemple de req un peu plus étoffé, extrait de http://www.uml-sysml.org/sysml (voir aussi Figure 71) :

Tout comme pour n’importe quel bloc, il est possible de stéréotyper les requirements. Ceci permet de se définir ses propres priorités et classifications. Quelques exemples de stéréotypes utiles :

Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).

Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases (en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci sera abordé dans la partie sur les concepts transverses.

Bien que nous traitions les cas d’utilisation dans la partie interface, nous les abordons ici du fait de leur proximité avec les requirements.

Ce diagramme est exactement identique à celui d’UML®.

Les exigences sont très importantes en ingénierie système, plus en tout cas qu’en ingénierie logiciel, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences. Il n’est donc pas étonnant qu’un diagramme et des mécanismes dédiés aient été prévus en SysML®.

En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. Figure 74).

Un ibd décrit la structure interne d’un bloc sous forme de :

Nous aborderons les concepts du niveau initial (Model User) de la certification Certified Systems Modeling Professional™: use case, actor, subject, association, include, extend, et generalization.

…​

On abordera :

En terme d’organisation, le mécanisme clef est celui de package. Celui-ci va permettre d’organiser les modèles, pas le système lui-même. Nous aborderons plus en détail cette organisation en étudiant le diagramme de packages.

Pour l’organisation du système, on trouve le plus souvent :

Afin de capturer de manière précise les contraintes entre valeurs, ou encore les liens entre les sorties et les entrées d’un bloc, SysML® utilise trois concepts clefs :

En résumé, il existe plusieurs diagrammes permettant d’exprimer la structure du système à concevoir. En fonction du niveau de détail nécessaire on peut voir les sous-systèmes comme des boîtes noires (des blocs) ou comme des boîtes blanches (grâce à l'`ibd` correspondant).

Le diagramme d’activité est étudié dans ce livre plus en détail au chapitre Section 9.5.3, dans la partie sur les interactions. Il s’agit d’un diagramme souvent utilisé pour représenter le comportement du système, notamment des scénarios des cas d’utilisation. Nous revoyons le lecteur au chapitre Section 9.5.3 pour plus de détails.

…​

On abordera :

Le diagramme d’activité (Activity Diagrams) permet de décrire les traitements. Il sert très souvent à décrire plus en détail les cas d’utilisation. Il est utilisé pour représenter les flots de données et de contrôle entre les actions. Il est utilisé en général pour détailler un cas d’utilisation. Il est utilisé pour l’expression de la logique de contrôle et d’entrées/sorties. Le diagramme d’activité sert non seulement à préciser la séquence d’actions à réaliser, mais aussi ce qui est produit, consommé, ou transformé, au cours de l’exécution de cette activité.

Les éléments de base du diagramme d’activité sont :

Les activités peuvent être réutilisées à travers des actions d’appel (callBehaviorAction). L’action d’appel est représentée graphiquement par une fourche à droite de la boîte d’action, ainsi que par la chaîne : nom d’action : nom d’activité. SysML® propose encore bien d’autres concepts et notations, comme la région interruptible, la région d’expansion ou encore les flots de type stream qui sortent du cadre de ce livre d’introduction.

Il existe de nombreux diagrammes pour exprimer les comportements. Ces modèles sont importants dans la mesure où ils peuvent servir à valider le futur système vis-à-vis de ces comportements exprimés. Ils ne sont donc véritablement utiles que lorsqu’ils sont couplés à des outils de simulation ou d’analyse (cf. Section 11.2.8).

On abordera :

Le diagramme de paquetages (Package Diagram) permet de représenter l’organisation des modèles en paquetages. Nous dirons plus volontiers 'diagramme de package' dans cet ouvrage. Le terme "paquetage" est en effet très peu utilisé dans les communautés de développement et de modélisation.

Il existe plusieurs types de packages :

Les modèles peuvent être organisés selon toutes sortes de considération :

Un package permet de créer un espace de nommage pour tous les éléments qu’il contient. En effet une hiérarchie de packages est basée sur la notion d’appartenance (ou de contenance, containment), c’est-à-dire de possession (ownership). Ainsi dans un package on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguïté.