La matrice qui nous servira de "carte de base" pour placer les activités ou les modèles, sera celle-ci :
Cette matrice permet de situer les différents éléments qui seront vus dans ce cours dans un cadre utile pour comparer ces éléments les uns aux autres. Je vous conseille de vous faire votre propre matrice. L’essentiel est de toujours bien se représenter les différents éléments qu’on aborde dans une carte mentale précise. Cela permet une meilleure mémorisation.
Dans un axe horizontal, j’ai différencié quatre grands points de vue :
- {Requirements}
-
Les exigences et leur prises en compte sont un éléments critique pour le succès du développement de tout système. Sans explorer l’ensemble des activités d’ingénierie système (ce qui nécessiterait tout un volume du type de [reqs]) nous insisterons sur cet aspect.
- {Structure}
-
La description de l’architecture et des éléments constitutifs du système, avec les blocs, leurs relations, organisations internes, etc. constituera un point de vue important. C’est souvent la partie de modélisation qui pose le moins de problème aux débutants.
- {Behavior}
-
Le comportement d’un système est du point de vue de l’utilisateur final beaucoup plus important que la structure elle-même. C’est la partie qu’il est la plus à même d’exprimer, de comprendre (vos modèles) et de valider.
- {Crosscutting}
-
Un certains nombre de concepts sont transverses aux trois points de vue précédents. Il s’agira principalement de parler de cohérence ou de traçabilité entre les phases de développement ou entre les points de vue.
Ces différents points de vue ne doivent pas être confondus avec les différentes phases de développement (cf. devphase). Ils sont plutôt à rapprocher de la notion de préoccupation. C’est ainsi que j’ai choisi de distinguer trois points de vue qui se retrouvent souvent en modélisation : le point de vue des exigences qui permet de se focaliser sur les besoins des clients ; le point de vue structurel qui permet de se focaliser sur les différents composants du système ; et le point de vue comportemental qui permet de se focaliser sur le comportement du système. Ces trois points de vue n’étant pas indépendants les uns des autres, j’ai intégré un quatrième point de vue transversal.
Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :
- {organisation}
-
Une étape indépendante du type de cycle de développement envisagé (en V, agile, etc.) mais qui concerne la mise en place d’un cadre de travail qui permette un développement de qualité (outils, éditeurs, gestionnaire de version, de tâches, etc.).
|
Note
|
On pourrait rapprocher cette étape du "cycle 0" de {scrum}. |
- {analysis}
-
Cette phase vise plutôt à examiner le domaine du problème. Elle se focalise sur les cahiers des charges et les exigences. L’analyse débouche sur un dossier d’analyse qui décrit les grandes lignes (cas d’utilisation, architecture principale) du système.
- {design}
-
Cette phase vise plutôt à examiner le domaine de la solution. Elle débouche sur un dossier de conception qui décrit les détails conceptuels de la solution envisagée (structure détaillée, comportement, etc.)
- {implementation}
-
Cette phase traite des développements finaux (construction ou approvisionnement en matériel, développement de codes, etc.).
Il s’agit ici classiquement des grandes étapes de développement d’un système. On pourrait être surpris par l’étape que j’ai appelé "{organisation}". C’est une étape que je considère importante, particulièrement pour l’enseignement. Avant toute activité de modélisation ou de même de développement, il convient en effet de s’organiser en termes de choix d’outils, choix d’environnement, etc. Cette étape est souvent négligée par les étudiants. C’est pour cela que j’ai décidé de faire figurer cette étape de manière explicite. Bien sûr dans une organisation existante cette étape sera contrainte par les habitudes "maison".
-
Associez les diagrammes suivants avec leurs acronymes (
{sd},{dc},{uc},{pkg},{dss})-
Diagramme de Paquetages
-
Diagramme des Cas d’Utilisation
-
Diagramme de Séquences Système
-
Diagramme de Classes
-
Diagramme de Séquences
-
-
Placez dans la matrice ci-dessous les différents diagrammes {uml} que vous connaissez déjà (
{sd},{dc},{uc},{pkg},{dss})
|
Caution
|
Éléments de correction
|
A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.
The World of Mathematics (1956)
Il existe une notation qui se veut "unifiée" pour les modèles : {uml}. Néanmoins cette notation est peu adaptée pour l'{is} :
-
UML 1.x était complètement inadaptée :
-
Principalement pour les systèmes d’information
-
Peu de liens entre les diagrammes
-
Peu de liens entre les modèles et les exigences
-
-
UML 2.x n’est pas beaucoup mieux si ce n’est :
-
Implication des ingénieurs systèmes pour sa définition
-
Introduction du diagramme de structure composite
-
En conclusion {UML} est une bonne base :
-
Standard De facto en génie logiciel
-
Fournit beaucoup de concepts utiles pour décrire des systèmes (même complexes)
-
Stable et extensible (grâce notamment au mécanisme de profile)
-
Beaucoup d’outils disponibles
Mais…
-
Manque de certains concepts clés d'{is}
-
Vocabulaire beaucoup trop « software » pour être utilisé par les ingénieurs systèmes (concept de classe ou d'héritage par exemple)
-
Trop de diagrammes (13 sortes)
Si vous ne deviez lire qu’un seul chapitre, voilà ce qu’il faudrait retenir.
- Un ensemble de 9 types de diagrammes
-
-
Diagrammes structuraux
-
Diagrammes de définition de blocs ({bdd})
-
Diagrammes internes de blocs ({ibd})
-
Diagrammes paramétriques ({par})
-
Diagrammes de packages (pkg)
-
-
Diagrammes comportementaux
-
Diagrammes de séquence ({seq})
-
Diagrammes d’activité ({act})
-
Diagrammes de cas d’utilisation ({uc})
-
Diagrammes d’états ({stm})
-
-
Diagramme d’exigence ({req})
-
- Un profil {uml}
-
C’est à dire une extension de cette notation, un ensemble de nouveaux concepts et éléments qui sont définis à partir des éléments de base {duml}. Un exemple : le bloc {sysml} n’est qu’une redéfinition de la classe {uml}.
- Une notation
-
Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes.
- Une méthode
-
En effet, contrairement à ce que beaucoup pensent en l’abordant, {sysml} ne propose pas de démarche particulière de développement de système. C’est à la fois sa force (votre méthode existante pourra continuer à être utilisée) comme sa faiblesse car cette absence de guide méthodologique fait souvent défaut à son utilisation.
- Un outil
-
Nous verrons en effet que {sysml} ne fait que ce qu’on veut bien en faire. Comme tout langage il est limité dans son pouvoir d’expression, mais surtout il reste une simple notation qu’il convient d’utiliser avec des outils et des démarches associées.
|
Note
|
Ne dites pas "le SysML" mais tout simplement "SysML". |
La figure suivante, tirée de la spécification, résume bien les liens entre {sysml} et {uml}, à savoir que {sysml} reprend une partie seulement des concepts d'{uml} (appelée UML4SysML) en y ajoutant des concepts nouveaux.
- Industrie
-
American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …
- Vendeurs d’outils
-
Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …
- Autres organisations
-
AP-233, INCOSE, Georgia Institute of Technology, AFIS, …
|
Tip
|
La liste complète des membres de {Lomg} est accessible à l’URL : http://www.omg.org/cgi-bin/apps/membersearch.pl |
{sysml} propose de couvrir la modélisation d’un système en 9 diagrammes. Ces diagrammes couvrent les aspects structurels et comportementaux du système ainsi que les exigences. Le diagramme suivant présente cette organisation en faisant au passage le lien avec ceux d'{uml} :
|
Note
|
Définition :
 Types de diagrammes (OMG SysML v1.3, p. 170)SysML diagram kinds should have the following names or (abbreviations) as part of the heading… |
{SysML} n’est pas une palette de dessins et d’éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en {SysML}. Elle 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} [1], mais d’utiliser des outils dédiés (cf. Outils SysML). Ils respectent en général la norme {norme} (bien qu’il faille se méfier).
|
Note
|
Notez que la norme permet de faire des adaptations graphiques (cf. la discussion http://www.realtimeatwork.com/2011/08/is-sysml-too-abstract/). |
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 dessin n’est pas assez formel (comment être sûr d’avoir correctement utilisé tel ou tel symbole, cf. les deux exemples ci-dessous) ;
-
il est impossible d’assurer la cohérence globale des modèles dans le cas d’un dessin.
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).
Voici deux exemples de non respect de la notation qui illustre le type d’erreur que l’on trouve souvent dans les modèles qui circulent sur Internet ou même parfois dans certains livres.
Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :
Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.
Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d’éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.
|
Warning
|
Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation. |
| {Requirements} | {Structure} | {Behavior} | {Crosscutting} | |
|---|---|---|---|---|
{here} {organisation} |
||||
{analysis} |
||||
{design} |
||||
{implementation} |
Abordons quelques principes généraux de {sysml}, c’est à dire des éléments indépendant d’un diagramme en particulier :
-
Chaque diagramme {SysML} décrit un élément précis (nommé) de modélisation
-
Chaque diagramme {SysML} doit être représenté à l’intérieur d’un cadre (Diagram Frame)
-
L’entête du cadre, appelé aussi cartouche, indique les informations sur le diagramme :
-
le type de diagramme (
{req},{act},{bdd},{ibd},{stm}, etc. en gras) qui donne immédiatement une indication sur le point de vue porté à l’élément de modélisation (comportement, structure, etc.) -
le type de l’élément (par exemple package, block, activity, etc.), optionnel
-
le nom de l’élément (unique)
-
le nom du diagramme ou de la vue, optionnel
-
Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type {bdd}) qui représente un
package, nommé "Context".
|
Note
|
Convention : Utilisation systématique des cartouches
Tout diagramme proposé pour décrire un système (dans une documentation par exemple) devrait posséder un entête précis. |
Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :
| {Requirements} | {Structure} | {Behavior} | {Crosscutting} | |
|---|---|---|---|---|
{organisation} |
|
|
|
|
{analysis}, {design}, {implementation} [2] |
|
|
|
|
On abordera :
-
Le Package Diagram
-
Les différent types de packages
-
Les organisations possibles
-
La notion de Namespaces
-
Les Dependencies
Le diagramme de paquetage permet de représenter l’organisation des modèles en paquetages.
-
Il est identique à {uml}, et classique pour les développeurs (java notamment)
-
Il permet d’organiser les modèles en créant un espace de nommage (cf. La notion de Namespaces)
Les modèles peuvent être organisés selon toutes sortes de considération (cf. Les organisations possibles) :
-
hiérarchie "système" (e.g., entreprise, système, composant)
-
types de diagrammes (e.g., besoins, structure, comportements)
-
par points de vue
-
etc.
Il existe plusieurs types de package :
- models
-
un package "top-level" dans une hiérarchie de packages
- packages
-
le type le plus classique : un ensemble d’éléments de modèles
- model librairies
-
un package prévu pour être réutilisé (importé) par d’autres éléments
- views
-
un package spécial pour représenter les points de vue
|
Tip
|
Un point de vue (viewpoint) est utilisé pour matérialiser une perspective particulière de modélisation.
Il possède des propriétés standardisés (concerns, language, purpose, etc.) et permettent d’indiquer qu’une
vue (un packetage particulier, stéréotypé |
Les modèles peuvent être organisés selon toutes sortes de considération :
-
par hiérarchie "système" (e.g., entreprise, système, composant, …)
-
par types de diagrammes (e.g., besoins, structure, comportements, …)
-
par cycle de vie (e.g., analyse, conception, …)
-
par équipes (e.g., architectes, [IPT], …)
-
par points de vue (e.g., sécurité, performance, …)
-
etc.
|
Tip
|
L’outil {topcased} propose, lors de la création d’un premier modèle, de créer une organisation "type" par défaut.
|
Un package permet de créer un espace de nommage pour tous les éléments qu’il contient. 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 ambiguité.
|
Note
|
Définition : Namespace (OMG SysML v1.3, p. 23)
The package defines a namespace for the packageable elements. |
Pour éviter toute ambiguité, on peut utiliser pour les éléments de modèles leur nom complet (Qualified name),
c’est à dire le nom de l’élément préfixé par son (ou ses) package(s)
(e.g., Structure::Products::Clock).
|
Tip
|
Dans les outils {sysml}, il faut souvent demander explicitement à voir les noms complets (Qualified names) des éléments (la plupart du temps dans les options graphiques). |
Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :
- Dependency
-
une dépendance "générale", non précisée,
représentée par une simple flèche pointillée-----> - Use
-
l’élément "utilise" celui à l’autre bout de la flèche (un type par exemple),
représentée par le stéréotype<<use>> - Refine
-
l’élément est un raffinage (plus détaillé) de celui à l’autre bout de la flèche,
représentée par le stéréotype<<refine>> - Realization
-
l’élément est une "réalisation" (implémentation) de celui à l’autre bout de la flèche,
représentée par le stéréotype<<realize>> - Allocation
-
l’élément (e.g., une activité ou un requirement) est "alloué" sur celui à l’autre bout de la flèche (un block la plupart du temps),
représentée par le stéréotype<<allocate>>
{sysml} propose un certain nombre de mécanismes pour organiser les différents modèles, tirés pour la plupart d'{uml}. Ces mécanismes seront plus faciles à comprendre au travers de leur utilisation concrète dans la suite.
| {Requirements} | {Structure} | {Behavior} | {Crosscutting} | |
|---|---|---|---|---|
{organisation} |
package |
package |
package |
dependencies |
… |
|
Note
|
|