CI.1. Approche pluri - PTSI Chaptal

Doc. Cours - Ressources SysML.doc Page 1

.

.

.

Compétence(s) : Analyser, Conduire l’analyse fonctionnelle structurelle et comportementale d’un système. Modéliser, Justifier ou choisir les grandeurs nécessaires à la modélisation. Proposer un modèle. Communiquer, Elaborer, rechercher et traiter des informations. Mettre en œuvre une communication.

1. Modélisation des systèmes avec SysML Le langage SysML (Systems Modeling Language) est un langage de modélisation permettant de décrire tout ou partie d'un système technique, d'un point de vue transversal, comportemental ou structurel. Ce langage permet d’unifier la démarche depuis la reprise du cahier des charges jusqu’à l’obtention détaillée d’un système virtuel testable. Le langage SysML s'articule autour de neuf types de diagrammes, chacun d'eux étant dédié à la représentation des concepts particuliers d'un système.

Un diagramme transverse :

Diagramme d’exigences : Montre les exigences du système et leurs relations Quatre diagrammes comportementaux :

Diagramme de cas d’utilisation : Montre les interactions fonctionnelles entre les acteurs et le système à l’étude; Diagramme de séquence : Montre la séquence verticale des messages passés entre blocs au sein d’une interaction; Diagramme d’états : Montre les différents états et transitions possibles des blocs dynamiques; Diagramme d’activité : Montre l’enchaînement des actions et décisions au sein d’une activité complexe;

CPGE - PTSI - Ch. Coeffin

Sciences Industrielles de l’ingénieur

Fiches ressources

CI.1. Approche pluri-technologique des systèmes

Modélisation des systèmes

Le langage SysML

mouzo

Rectangle

mouzo

Rectangle

mouzo

Rectangle


Quatre diagrammes structurels :

Diagramme de définition de blocs : Montre les briques de base statiques : blocs, compositions, associations, attributs, opérations, généralisations, etc; Diagramme de bloc interne : Montre l’organisation interne d’un élément statique complexe; Diagramme paramétrique : Représente les contraintes du système, les équations qui le régissent; Diagramme de packages : Montre l’organisation logique du modèle et les relations entre packages.

2. Ce qu’est SysML

• SysML prend en charge la spécification, l'analyse, la conception, la vérification et la validation des systèmes qui comprennent le matériel, logiciels, données, le personnel, les procédures et les installations.

• SysML permet de décrire un système sous forme de modèle, que ce soit lors de la conception ou une fois que le système existe.

• SysML est un langage de modélisation qui fournit Une sémantique (signification) ainsi qu’une notation (représentation du sens).

• Il n’y a pas d’obligation à tracer tous les diagrammes SysML, c’est une question de choix et de pertinence.

• Le « zoom » utilisé par SysML reste à la discrétion de l’équipe. On peut être précis, ou bien rester sur une description de type « gros grain ». C’est aussi une question de choix et de pertinence.

• SysML ne dit pas dans quel ordre réaliser les diagrammes, chacun d’entre eux est une vision différente d’un même modèle. Ils sont donc réalisables dans l’ordre que l’on souhaite. Par conséquent, SysML n’est pas une méthode.

• La construction des diagrammes SysML s’insère dans une démarche itérative, on n’a pas à les mettre au point en une seule fois. Le travail sur un diagramme entraînera peut-être des modifications dans d’autres diagrammes.

3. SysML dans la formation des CPGE

Dans les programmes de sciences industrielles pour l’ingénieur, tous les diagrammes ne seront pas vus avec le même intérêt. Dans les sujets de concours, les diagrammes devraient être abordés uniquement en lecture, la syntaxe n’a pas à être connue de manière précise par les étudiants. SysML sera exploité au travers d’études de cas lors des activités de travaux dirigés et servira de support à l’analyse et la modélisation des systèmes du laboratoire lors de séances de travaux pratiques. Pour un sujet d’écrit, la terminologie à utiliser est donnée dans le sujet, il ne faut rien inventer hors du cadre défini. Il est vivement recommandé pour préparer les épreuves orales (travaux pratiques sur système) d’utiliser le langage SysML lors de son TIPE afin de bien comprendre l’intérêt de cet outil.

4. Spécification d’un diagramme SysML

Un cartouche (Header) positionné en haut à gauche de chaque diagramme dans un pentagone permet de spécifier le type de diagramme SysML, le type de l’élément concerné, l’élément concerné, et le nom du diagramme. Dans l’exemple suivant, il s’agit d’un diagramme d’exigences (req) nommé « Diagramme initial d’exigences », concernant l’élément RadioRéveil de type Modèle. Le cartouche général du diagramme d’exigences est de la forme :

req [package ou exigence] nom de l’élément [nom du diagramme]


Entête d’un diagramme SysML

Chaque diagramme est ainsi nommé d’une façon bien précise et constitue un élément nommé du modèle.

5. Diagramme SysML des exigences « req » (requirem ent diagram) 5.1 Définition d’une exigence

Une exigence permet de spécifier une capacité ou une contrainte qui doit être satisfaite par un système. Elle peut spécifier une fonction que le système devra réaliser ou une condition de performance, de fiabilité, de sécurité, etc. Les exigences servent à établir un contrat entre le client et les réalisateurs du futur système. Une exigence prescrit donc une propriété jugée nécessaire ; elle peut correspondre à un service ou une fonction, une caractéristique, une aptitude, ou une limitation. Le diagramme des exigences permet de réécrire graphiquement le cahier des charges tout en offrant la possibilité d’une dimension interne que ne propose pas le cahier des charges. Les deux propriétés de base d’une exigence sont :

• Un identifiant unique permettant ensuite de gérer la traçabilité avec l’architecture, • Un texte descriptif.

Il est courant mais pas obligatoire de définir d’autres propriétés ou attributs pour les exigences, par exemple :

Dans l’exemple du radio-réveil (voir étude cas), la première exigence fondamentale concerne la capacité à assurer à l’utilisateur un réveil automatique à l’heure souhaitée avec la radio ou un buzzer. On pourra également lister des exigences sur le réglage de la radio, de l’horloge et de l’alarme, ainsi que sur la nécessité d’un mécanisme de sauvegarde.

• priorité (par exemple : haute, moyenne, basse) ; • source (par exemple : client, marketing, technique, législation, etc.) ; • risque (par exemple : haut, moyen, bas) ; • statut (par exemple : proposée, validée, testée, livrée, ...) ; • méthode de vérification (par exemple : analyse, démonstration, test, ...). Il est également possible de faire la distinction entre différents types d’exigences, au lieu d’utiliser un unique type banalisé :

• fonctionnelle ; • performance ; • fiabilité ; • sécurité ; • physique ; • interface ; • etc.


Il ne faut pas chercher à poser toutes les exigences dans le même diagramme au risque de le rendre illisible. On préfèrera si nécessaire poser plusieurs diagramme en regroupant chaque diagramme par familles d’exigences. On réalisera par exemple un diagramme pour les exigences fonctionnelles et un autre diagramme pour les autres types d’exigences. On propose ci-dessous un diagramme d’exigences fonctionnelles avec attributs issu de l’étude de cas du radio-réveil.

On constate sur le diagramme ci-dessus que l’exigence Projection a comme statut : proposée, au lieu de validée pour les autres.

5.2 Hiérarchisation des exigences Les exigences peuvent être reliées entre elles par des relations de contenance, de raffinement ou de dérivation : La contenance (ligne terminée par un cercle contenant une croix du côté du conteneur) permet de décomposer une exigence composite en plusieurs exigences unitaires, plus faciles ensuite à tracer vis-à-vis de l’architecture ou des tests ;

Le raffinement « refine » consiste en l’ajout de précisions, par exemple de données quantitatives ; La dérivation (« deriveReqt ») consiste à relier des exigences de niveaux différents, par exemple des exigences système à des exigences de niveau sous-système, etc. Elle implique généralement des choix d’architecture. Dans l’étude de cas du Radio-réveil de la page suivante, l’exigence sur la gestion de la radio est exprimée par une phrase contenant une conjonction de coordination « et ». Ceci est souvent le symptôme d’une exigence composite devant être décomposée en exigences unitaires.

Contenu Contenant

« refine »

« derivReqt »


L’exigence sur le réglage de la station peut être raffinée en précisant certaines valeurs. Enfin, on peut considérer que la gestion de l’heure est une exigence qui dérive d’une autre exigence et en ce sens qu’elle implique un niveau d’architecture supplémentaire.

SysML permet d’utiliser des notes graphiques sur tous les types de diagrammes (forme de post-it). Deux mots-clés particuliers ont été définis afin de représenter :

• Des problèmes à résoudre (« problem ») ; • Des justificatifs (« rationale »).

5.3 Tracabilité La gestion des exigences est l’ensemble des activités permettant de définir et de suivre les exigences d’un système au cours d’un projet.

Dans le diagramme ci-contre, on a rajouté une exigence d’interface pour raffiner l’exigence Gestion station radio et d’autre part, l’exigence Fréquences radio a été spécifiée comme étant une exigence physique. On notera aussi la présence de 2 notes graphiques :

Une note « Rationale » pour justifier le raffinement de l’exigence physique Fréquences radio.

Une note « problem » en vue d’un choix fonctionnel non encore réalisé.


Cette gestion des exigences permet :

• De s’assurer de la cohérence entre ce que fait réellement le projet et ce qu’il doit faire ; • De faciliter l’analyse d’impact en cas de changement.

Le diagramme d’exigences permet ainsi tout au long d’un projet de relier les exigences avec d’autres types d’éléments SysML par plusieurs relations :

• Relation entre une exigence et un élément comportemental (cas d’utilisation, diagramme d’états,...) : « refine » • Relation entre une exigence et un bloc d’architecture (ou de structure) : « satisfy » ; • Relation entre une exigence et un cas de test : « verify ».

Si on considère :

- Le cas d’utilisation Écouter la radio (voir le chapitre suivant) qui décrit un comportement du système. - Le bloc d’architecture Radio (voir le chapitre Diagramme de définition des blocs) qui décrit le système ou

un élément de structure du système. - Le cas de testTest radio(1).

En reliant ces nouveaux éléments issus d’autres types de diagrammes SysML, à l’exigence de Gestion radio on obtient les 3 relations de traçabilité ci-dessus.

(1) Un cas de test représente une méthode de vérification de la satisfaction d’une exigence. Il est représenté en SysML par un rectangle avec le mot-clé « Test Case ». Une autre représentation graphique proposée par SysML consiste à faire apparaître les relations de traçabilité par une note attachée à l’exigence, ou encore par des attributs ou des compartiments supplémentaires. Les deux figures qui suivent montrent ces différentes solutions.

Ajout de la traçabilité d’une exigence au moyen d’une note Ajout de la traçabilité à l’intérieur de l’exigence


6. Diagramme SysML des cas d’utilisation « uc » (u se case diagram) 6.1 Notions de base SysML permet de représenter les services attendus du système par un modèle de cas d’utilisation. Ce modèle contient un ou plusieurs diagrammes de cas d’utilisation, montrant les interactions fonctionnelles entre les acteurs et le système à l’étude. Cas d’utilisation

Un cas d’utilisation (use case, ou UC) représente un ensemble de séquences d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier. Chaque cas d’utilisation spécifie un comportement attendu du système considéré comme un tout, sans imposer le mode de réalisation de ce comportement. Il permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera. Un cas d’utilisation doit être relié à au moins un acteur.

Attention : Un cas d’utilisation ne doit donc pas se réduire systématiquement à une simple action. Acteur

Rôle joué par un utilisateur humain ou un autre système qui interagit directement avec le système étudié. Un acteur participe à au moins un cas d’utilisation.

Les acteurs candidats sont systématiquement :

• Les utilisateurs humains directs représentés sous forme de stick man • Les autres systèmes connexes qui interagissent avec le système étudié représentés sous la forme et d’une manière générale tout ce qui est en interaction avec le système. Nous appelons acteur principal celui pour qui le cas d’utilisation produit un résultat observable. Par opposition, nous qualifions d’acteurs secondaires les autres participants du cas d’utilisation. Les acteurs secondaires sont souvent sollicités pour des informations complémentaires ; ils peuvent uniquement consulter ou informer le système lors de l’exécution du cas d’utilisation. Une bonne pratique consiste à faire figurer les acteurs principaux à gauche des cas d’utilisation, et les acteurs secondaires à droite (voir paragraphe suivant). Dans l’étude de cas du Radio-réveil, une première version du diagramme de cas d’utilisation consiste à considérer un seul acteur (l’utilisateur) connecté à un unique cas d’utilisation (être réveillé à l’heure en musique). Ce qui donne la représentation ci-dessous.

Remarque : Il n’est pas nécessaire de placer dans un diagramme des cas d’utilisation tous les interacteurs du système. En effet, pour prendre un exemple simple par rapport au Radio-réveil, la source d’alimentation électrique qui est assimilée à une contrainte n’est pas forcément associée à un résultat observable sur le cas d’utilisation. Par contre, si on considère comme cas d’utilisation Assurer l’autonomie en énergie électrique, la source d’alimentation deviendra alors acteur du système pour le diagramme [uc].

Si on souhaite toutefois représenter l’environnement complet du système en identifiant tous les interacteurs, on utilisera un diagramme de définition de bloc [bdd] particulier nommé diagramme de contexte (voir chapitres suivants).

Acteur principal Cas d’utilisation Association


6.2 Construction du diagramme des cas d’util isation

Le cartouche général du diagramme de cas d’utilisation est de la forme :

uc [package ou bloc] nom de l’élément [nom du diagramme]

Le diagramme de cas d’utilisation est un schéma qui montre les cas d’utilisation du système (ovales) reliés par des associations (lignes) à leurs acteurs (stick man). Chaque association signifie simplement « participe à ».

Par rapport au diagramme de cas d’utilisation du Radio-réveil de la page précédente, on peut se dire que l’utilisateur, alors qu‘il est réveillé, est susceptible d’utiliser le radio-réveil en tant que simple radio ou horloge. Chaque cas d’utilisation doit bien représenter un service autonome rendu par le système et fournissant un résultat observable et intéressant pour l’acteur concerné. Si de plus nous ajoutons les stations radio en tant qu’acteur secondaire pour les cas d’utilisation du radio-réveil liés à la radio, nous obtenons la figure suivante.

Pour affiner le diagramme de cas d’utilisation, SysML définit en plus de la relation d’association, trois types de relations standardisées entre cas d’utilisation :

Dans l’étude de cas du Radio-réveil, le cas d’utilisation Avoir l’heure pourrait se spécialiser suivant que la lecture de l’heure se fait directement sur le radio-réveil ou alors au plafond. Les cas d’utilisation Avoir l’heure et Être réveillé à l’heure en musique incluent tous les deux une capacité de modification des heures et des minutes. On peut donc créer un nouveau cas d’utilisation permettant de ne déclarer et décrire qu’une seule fois un comportement réutilisable. Pour le cas d’utilisation Être réveillé à l’heure en musique on pourrait prendre en compte une fonctionnalité optionnelle, telle que le simulateur d’aube (la lumière augmente progressivement pendant 30 à 90 minutes avant l’heure de réveil).

Une relation d’inclusion, formalisée par le mot-clé « include » : Le cas d’utilisation de base en incorpore explicitement un autre de façon obligatoire.

Une relation d’extension, formalisée par le mot-clé « extend » : Le cas d’utilisation de base en incorpore implicitement un autre de façon optionnelle.

Une relation de généralisation/spécialisation (flèche blanche) : Les cas d’utilisation descendants héritent la description de leur parent commun. Chacun d’entre eux peut néanmoins comprendre des interactions spécifiques supplémentaires. On met en évidence qu’un cas d’utilisation est un cas particulier d’un autre cas d’utilisation (parent).


Toujours dans le cadre de l’étude de cas du Radio-réveil, on pourrait imaginer distinguer les cas d’utilisation du radio-réveil selon que l’utilisateur est endormi ou déjà réveillé. En effet, c’est l’utilisateur endormi qui souhaite être réveillé à l’heure, alors que c’est l’utilisateur éveillé qui va écouter la radio ou regarder l’heure. On pourrait aussi considérer que tout utilisateur peut avoir l’heure, qu’il soit endormi ou réveillé. Mais on peut même aller un peu plus loin : grâce au dispositif de projection au plafond, l’utilisateur (à moitié) endormi peut lui aussi avoir l’heure. SysML permet de créer un acteur généralisé Utilisateur qui factorise les comportements communs aux deux autres acteurs. On dit alors que les acteurs utilisateur endormi et utilisateur éveillé sont des spécialisations de l’acteur Utilisateur. Ils peuvent chacun posséder leurs propres cas d’utilisation spécifiques. La relation de généralisation/spécialisation (flèche blanche) utilisée avec les cas d’utilisation pourra être appliquée aux acteurs du système. Le diagramme des cas d’utilisation ci-dessous construit à partir du diagramme de la page précédente intègre le concept de généralisation/spécialisation des acteurs ainsi que les concepts d’inclusion, d’extension et de généralisation/spécialisation des cas d’utilisation.

Attention : Il ne faut pas abuser pas des relations entre cas d’utilisation (inclusion, extension, généralisation) : elles peuvent rendre les diagrammes de cas d’utilisation trop difficiles à décrypter pour les experts métier qui sont censés les valider. En effet, on pourra considérer que le diagramme de la page précédente est probablement tout à fait suffisant dans cette étude de cas.


7. Diagramme SysML de séquence « sd » (Sequence Di agram) 7.1 Notions de base

Le diagramme de séquence est un diagramme comportemental qui montre chronologiquement la séquence verticale des messages passés entre éléments (lignes de vie) au sein d’une interaction. Ce diagramme décrit les scénarios correspondant aux cas d’utilisation. Un cas d’utilisation étant décrit par au moins un diagramme de séquence. Ligne de vie

Représentation de l’existence d’un élément participant dans un diagramme de séquence. Une ligne de vie possède un nom et un type. Elle est représentée graphiquement par une ligne verticale en pointillés.

Message

Élément de communication unidirectionnel entre lignes de vie qui déclenche une activité dans le destinataire. La réception d’un message provoque un évènement chez le récepteur.

Activation d’une ligne de vie

Les bandes verticales le long d’une ligne de vie représentent des périodes d’activation. Elles sont optionnelles, mais permettent de mieux comprendre la flèche pointillée du message de retour.

• loop : boucle. Le fragment peut s’exécuter plusieurs fois, et la condition de garde explicite l’itération ; • opt : optionnel. Le fragment ne s’exécute que si la condition fournie est vraie ; • alt : fragments alternatifs. Seul le fragment possédant la condition vraie s’exécutera. • par : fragments parallèles. Permet d’exécuter plusieurs opérandes en parallèle. • ref : permet de créer un hyperlien graphique avec un autre diagramme de séquence. . SysML permet d’ajouter des contraintes temporelles sur le diagramme de séquence.

• La contrainte de durée : permet d’indiquer une contrainte sur la durée exacte, la durée minimale ou la durée maximale entre deux événements. • La contrainte de temps : permet de positionner des labels associés à des instants dans le scénario au niveau de certains messages et de les relier ainsi entre eux.

Une flèche pointillée représente un retour ou réponse. Cela signifie que le message en question est le résultat direct du message précédent.

Un message synchrone (émetteur bloqué en attente de réponse) est représenté par une flèche pleine.

Un message asynchrone est représenté par une flèche évidée.

Un message réflexif qui permet de représenter un comportement interne se traduit par une flèche en boucle. SysML propose une notation très utile : le fragment combiné. Chaque fragment possède un opérateur et peut être divisé en opérandes. Les principaux opérateurs sont (voir page suivante) :


7.2 Construction du diagramme de séquence

Le cartouche général du diagramme de séquence est de la forme :

sd [interaction] nom de l’interaction [nom du diagramme] Dans un premier temps, il est préférable de faire un diagramme de séquence « système » (dss), ce dernier étant vu comme une boite noire donc une ligne de vie unique. Dans un deuxième temps, et pour plus de détails, on pourra ensuite montrer les interactions au sein du système en le décomposant en autant de lignes de vie que nécessaire. Pour revenir sur l’étude de cas du Radio-réveil, un premier exemple de dss du cas d’utilisation Être réveillé à l’heure en musique est donné à la figure suivante. On remarquera l’utilisation de notes (post-it) pour mieux documenter le diagramme. Le premier message est un message synchrone, donnant lieu à un retour : l’affichage d’un point à côté de l’heure indiquant que l’alarme est positionnée. Le fait que radio-réveil détecte que l’heure courante devient égale à l’heure d’alarme est représenté par un message réflexif avec le mot-clé when. Le dernier message est un signal asynchrone.

Pour illustrer maintenant la notion de fragment combiné, on se reportera aux deux dss de la page suivante.

Commentaires 1er diagramme:

Le son qui sort de la radio est continu pendant plusieurs minutes, ce n’est pas un simple signal unitaire. Pour le représenter, positionnons un fragment de boucle. En fait, l’utilisateur sera réveillé par la radio ou le buzzer suivant son choix. Nous pouvons donc ajouter un fragment alt avec deux opérandes. Enfin, le premier message n’est pas nécessaire si l’alarme était déjà positionnée la veille : il est donc optionnel. Commentaires 2ème diagramme:

Dans le scénario nominal du cas d’utilisation étudié, l’utilisateur a la possibilité avant de se coucher de modifier les réglages de l’horloge et de la radio. Si nous ne voulons pas décrire le détail de ces interactions dans le même diagramme de séquence, il suffit d’utiliser des cadres ref optionnels. Pour illustrer enfin l’opérateur de fragment combiné par (parallèle), on montre qu’en parallèle de l’activation de la radio, le projecteur est également allumé (sauf bien sûr s’il l’était déjà).



Si on décompose maintenant la ligne de vie représentant le système pour montrer les interactions internes (scénario « boîte-blanche ») le scénario nominal simplifié du cas d’utilisation être réveillé à l’heure sera remplacé par un nouveau scénario dans lequel figureront trois parties que nous avons jugé importantes, à savoir l’horloge, la radio et le projecteur.

On obtiendra ainsi le nouveau diagramme de séquence ci-dessous qui met en évidence une décomposition structurelle du système.


8. Diagramme SysML de définition de blocs « bdd » (block definition Diagram) 8.1 Notions de base

Le bloc SysML (« block ») constitue la brique de base pour la modélisation de la structure d’un système. Il peut représenter un système complet, un sous-système ou un composant élémentaire. Ce diagramme permet donc de représenter la structure interne du système. C’est un diagramme d’architecture. Le bloc permet de représenter plusieurs types d’éléments :

- Entité abstraite, - Élément physique, - Logiciel.

Dans un bdd, un bloc est représenté graphiquement par un rectangle découpé en compartiments. Le nom du bloc apparaît tout en haut, et constitue l’unique compartiment obligatoire. Tous les autres compartiments ont des labels indiquant ce qu’ils contiennent : valeurs, parties, etc. Le mot-clé « block » apparaît par défaut lors de la modélisation, sauf si nous utilisons d’autres mots-clés disponibles tels que « system », « subsystem », etc. Il n'est pas obligatoire de faire apparaître dans un bloc les attributs qui représentent des propriétés qui caractérisent ce bloc ainsi que les opérations qui représentent ce que l’on peut demander au bloc. Dans ce cas le diagramme est relativement pauvre en informations, mais il offre d’un coup d'oeil la structure du système.

Il est possible d’affiner le block par un certain nombre de propriétés dont on retiendra :

- Les valeurs (value properties) qui décrivent des caractéristiques quantifiables, - Les parties (part properties) qui décrivent la hiérarchie de décomposition du bloc en termes d’autres blocs, - Les références (references) qui caractérisent l’association entre plusieurs blocs, - Les éventuelles contraintes (constraints) qui caractérisent une condition portant sur un ou plusieurs

éléments du modèle qui doit être vérifiée par les éléments concernés, - Les opérations qui représentent ce que l’on peut demander au bloc, tout bloc possédant également des

propriétés comportementales, - Les réceptions ou messages asynchrones (signal). - Les ports (port) qui définissent les points d’interaction offerts (provided) et requis (required) entre blocs.

Dans l’exemple ci-dessous la modélisation du système voiture a été complétée par un certain nombre de propriétés.

L’exemple ci-contre propose une modélisation structurelle basique d’une voiture sous forme d’un « block système »

Caractéristiques quantifiables

Propriétés comportementales

Décomposition hiérarchique

Référence à la route (Relation d’association)

Bloc système


8.2 Construction du diagramme de définition de blocs

Le cartouche général du diagramme de définition de blocs est de la forme :

bdd [modèle] nom de l’élément [nom du diagramme] Le diagramme de définition de blocs (ou bdd) doit permettre de modéliser l’architecture structurelle d’un système ou d’un sous-système en reliant entre eux de manière hiérarchique les différents blocs identifiés. Le bdd montre ainsi le système d'un point de vue composé/composant en répondant à la question "qui contient quoi " Il s’agit donc d’établir des relations entre les différents blocs. On retiendra 3 types de relations :

- La relation de composition (1) dans laquelle un bloc représente le tout et les autres ses parties, peut également être représentée graphiquement. Le côté du tout est indiqué par un losange plein.

- La relation d’agrégation représentée par un losange vide (2) qui est une relation de contenance beaucoup moins forte que la relation de composition. L’agrégation est utile : pour représenter le fait que la contenance n’est pas vraiment structurelle et obligatoire, mais plus conjoncturelle.

- La relation d’association (3) qui est une relation n’impliquant pas de contenance, comme la composition ou l’agrégation, mais une relation d’égal à égal. Les associations donnent lieu à des références dans les deux blocs reliés.

Pour reprendre la notion d’association, dans l’exemple ci-dessous on considère que la voiture roule habituellement sur une route (au sens large) et qu’elle est la propriété d’une personne (le propriétaire). La voiture possèdera ainsi une référence supplémentaire appelée propriétaire, de type Personne, et une référence optionnelle anonyme de type Route. Les blocs Personne et Route ont pour leur part une référence multiple de type Voiture.

La modélisation avec SysML n’est pas une méthode, cependant une modélisation structurelle basée sur le concept de chaîne d’énergie – chaîne d’information peut être envisageable. Toutefois, pour pouvoir évoluer vers les diagrammes SysML de bloc interne (voir chapitre ibd) une hiérarchisation des blocs organisée par rapport à la notion de chaîne fonctionnelle peut paraître plus cohérente. Quoi qu’il en soit, le concepteur est libre de sa modélisation et de sa gestion du ‘’zoom’’ à condition de rester cohérent.

possède Roule sur

(2) Agrégation

(3) Association

(1) Composition


8.3 Etude de cas du Radio-réveil Pour reprendre l’étude de cas du Radio-réveil, nous allons considérer que le système (le Radio-réveil) contient deux blocs principaux : un réveil et une radio. Ces blocs de premier niveau représentent des concepts logiques, des fonctionnalités, mais pas encore des composants physiques. Si nous commençons à répartir les propriétés et les opérations, en fonction des responsabilités que nous décidons d’attribuer aux différents blocs, nous obtenons un premier bdd comme indiqué sur la figure suivante.

Les exigences précisent la nécessité d’un dispositif de sauvegarde pour conserver en mémoire les réglages en cas de coupure de courant. Pour cela, nous choisissons de pouvoir intégrer une ou plusieurs piles amovibles. La note avec le mot-clé « rationale » explique ce choix. Les piles sont récupérables en fin de vie du radioréveil : nous utiliserons plutôt une relation d’agrégation ; Le réveil contient un bloc afficheur, un bloc projecteur, et un bloc horloge. En fait, selon les radio-réveils, il y a un soit un unique bloc horloge garantissant l’affichage d’une heure cohérente sur le radio-réveil et au plafond, ou bien deux horloges différentes : une pour l’afficheur standard, une autre pour le projecteur. Le problème dans ce cas étant le risque d’incohérence entre l’heure projetée au plafond et l’heure du radio-réveil qui est la référence vis à vis de l’alarme, La note avec le mot-clé « problem » permet d’expliquer ces deux possibilités.


D’un point de vue méthodologique, il peut être intéressant de remonter d’un cran et de modéliser le contexte du bloc principal (celui qui porte le mot-clé « system »). On peut ainsi représenter l’environnement du système, avec dans notre exemple, non seulement les utilisateurs humains et les stations de radio, mais également l’environnement physique composé de la chambre avec son plafond sur lequel sera projetée l’heure la nuit, ainsi que ses prises électriques. Ces éléments externes ne sont pas des acteurs à proprement parler dans la mesure où ils n'interviennent pas dans les cas d’utilisation. Ce type de diagramme de définition de blocs sera parfois appelé diagramme de contexte.

9. Diagramme SysML de bloc interne « ibd » (intern al block Diagram) 9.1 Notions de base

Le diagramme de bloc interne (internal block diagram ou ibd) comme le diagramme bdd décrit la structure interne du système mais il permet de plus de définir les différents flux entre les composants du système en termes de parties, ports et connecteurs. Il permettra ainsi de représenter les échanges de type matière – information - énergie (MEI) entre blocs de même niveau grâce aux ports de flux (petit carré avec une flèche) ainsi que les services invoqués par un autre bloc grâce aux ports standards (petit carré sans flèche), et par extension toute entrée, sortie de contrôle ou commande.

Éléments graphiques

• Les parties (parts en anglais) : Les différentes parties du système étudié sont représentées sous forme de blocs muni ou non de ports.

• Les ports : représentés par des petits carrés à la frontière des blocs, ils peuvent contenir ou non des flèches indiquant le sens de la relation.

• Les connecteurs : ce sont des traits continus reliant des ports. Ils peuvent porter un commentaire indiquant la nature du flux.

Les ports définissent les points d’interaction offerts (provided) et requis (required) entre les blocs. Un bloc peut avoir plusieurs ports qui spécifient des points d’interaction différents.


Dans l’exemple de radio-réveil, les boutons de marche-arrêt du projecteur et de la radio sont typiquement des ports standards. L’entrée d’énergie électrique comme les ondes radio, la projection de lumière ou la diffusion de son sont typiquement des ports de flux (flow ports).

Les ports de type « flux » sont soit atomiques (un seul flux), soit composites (agrégation de flux de natures différentes). Dans l’exemple précédent, les flow ports Projection, Réception radio et Alimentation sont tous atomiques. Cela signifie qu’ils ne spécifient qu’un seul type de flux en entrée ou en sortie (ou les deux), la direction étant simplement indiquée par une flèche à l’intérieur du carré représentant le port. Pour leur part, les ports standards sont simplement représentés par des carrés.

9.2 Construction du diagramme de bloc intern e

Le cartouche général du diagramme de bloc interne est de la forme :

ibd [bloc] nom du bloc [nom du diagramme] L’intérêt principal de l’ibd consiste à pouvoir décrire les connexions entre les ports de différents blocs au moyen de connecteurs, alors que le bdd ne permet que de définir éventuellement les ports sans les connecter. Nous allons ainsi dans le cadre du Radio-réveil pouvoir connecter la projection au plafond de la chambre, la réception radio aux stations, etc.

Il faut bien retenir que les liens se représentent entre blocs de même niveau, ils ne se contiennent pas. Chaque bloc du bdd contenant d'autres blocs peut être représenté par un ibd.

Le cadre de l’ibd représente le bloc englobant. Il fournit le contexte pour tous les éléments du diagramme. Le connecteur est un concept structurel utilisé pour relier deux parties et leur fournir l’opportunité d’interagir, Les éléments de flot représentés par une flèche noire nommée sur le connecteur (item flows) permettent de décrire ce qui circule réellement sur les connecteurs, alors que les flow ports définissent ce qui peut circuler. La distinction n’est pas toujours utile, mais peut se révéler néanmoins très pratique dans certains cas.


Pour décrire un comportement basé sur l’invocation de services, le port standard est tout à fait adapté. Mais au lieu d’assigner directement des opérations aux ports, il est plus intéressant de les regrouper en ensembles cohérents appelés interfaces. Une interface fournie (provided interface) sur un port spécifie les opérations que le bloc fournit. Une interface requise (required interface) spécifie les opérations dont le bloc a besoin pour réaliser son comportement. Pour le radio-réveil, nous pouvons par exemple commencer à définir (dans un bdd) des interfaces pour la gestion du volume de la radio, le réglage et la mémorisation des stations, la mise à jour des heures et des minutes, etc.

Dans l’étude de cas du Radio-réveil ci-dessous, il a été choisi de représenter seulement un sous-ensemble pour ne pas surcharger le diagramme.

On notera le rôle central de l’horloge qui active la radio et le projecteur (à l’heure d’alarme), et qui fournit aussi l’horodatage à l’afficheur et au projecteur. Pour donner une autre illustration des ressources de SysML, et la possibilité de réaliser plusieurs diagrammes complémentaires, à la manière de calques superposables, nous avons dessiné un autre ibd en nous focalisant uniquement sur l’alimentation électrique du Radio-réveil. Un nouveau bloc t : Transformateur, dont le rôle est de transformer le courant alternatif fourni par la prise de courant en courant continu a été introduit. Le transformateur alimente ainsi toutes les parties du radio-réveil. Du coup, il apparaît clairement que la pile de secours n’alimente que la partie horloge, conformément aux exigences initiales.


ibd du radio-réveil concernant l’alimentation électrique

On notera la représentation du bloc pile de secours est en pointillé ce qui rend traçable la relation d’agrégation entre la pile et le Radio-réveil mise en évidence dans le bdd (voir page 16).

10. Diagramme SysML paramétrique « par » (parametr ic Diagram)

Le diagramme paramétrique permet de représenter des contraintes sur les valeurs de paramètres système tels que performance, fiabilité, masse, etc. Le diagramme paramétrique ressemble graphiquement au diagramme de blocs internes mais n’est pas une évolution de celui-ci. Il s’agit d’une spécialisation du diagramme de bloc interne où les seuls blocs utilisables sont des contraintes entre paramètres permettant de représenter graphiquement des équations et des relations mathématiques. Il faut donc préalablement déclarer les contraintes dans un bdd, comme pour les blocs plus classiques. Un exemple donnant la déclaration de deux lois électriques, la loi d’Ohm et l’effet Joule, est montré dans l’exemple qui suit.


Les paramètres formels des équations sont représentés par des ports et peuvent ainsi être connectés les uns aux autres.

L’intérêt du diagramme paramétrique tient des capacités que commencent à offrir les éditeurs SysML d’injecter des données dans d’autres outils d’analyse qui permet d’effectuer des simulations à partir des contraintes du diagramme paramétrique, Ce diagramme doit donc à terme déboucher sur de la simulation. Toutefois, la mise en œuvre est longue et demande une préparation rigoureuse du modèle par une identification des paramètres, etc. De par sa difficulté de mise en œuvre, il ne doit pas se substituer dans le cadre de notre formation (en tout cas dans un 1er temps) à des outils plus adaptés et ergonomiques disponibles dans nos laboratoires.

11. Diagramme SysML d’états « stm » (State Machine Diagram)

11.1 Notions de base

Les systèmes à événements discrets se caractérisent par leurs états internes. Le diagramme d’états (stm) issu du concept de machine à états finis représente pour une partie (un bloc ou un sous-système ou un cas d’utilisation) du système, le comportement de celui-ci à partir de ses états internes et des événements ou transitions auxquels il réagit.

Le diagramme d’état décrit les différents états pris par le bloc ainsi que les transitions possibles entre ces différents états. Chaque bloc d’un bdd ou d’un ibd ne conduit pas nécessairement à un diagramme d’état. En effet, certains blocs dont le comportement est statique ne requièrent pas nécessairement un diagramme d’état. Seuls ceux qui ont un comportement dynamique complexe nécessiteront une description poussée par diagramme d’état.

Le diagramme de la page suivante décrit le fonctionnement d’un système de vidéosurveillance. On trouve dans ce diagramme les différents éléments graphiques et textuels qui le caractérisent.

- Les états, - Les pseudo-états, - Les évènements et conditions de garde, - Les transitions, - Les effets comportementaux (actions, activités).

Dans cet exemple, la représentation du comportement est fonctionnelle.


Aucune information technique sur la manière dont sont transmises les informations, ni sur la façon dont sont réalisées les activités, n’est précisée.

11.2 Etat

11.2.1 Définition

Un état représente une situation durant la vie d’un bloc pendant laquelle :

• il satisfait une certaine condition • il exécute une certaine activité ; • ou bien il attend un certain événement.

Un bloc passe par une succession d’états durant son existence. Un état a une durée finie, variable selon la vie du bloc, en particulier en fonction des événements qui lui arrivent. Cet élément se représente graphiquement par un rectangle à coin arrondi. Un état est associé à un identifiant et peut posséder dans sa partie inférieure des transitions internes. 11.2.2 Pseudo-états

En plus de la succession d’états « normaux » correspondant au cycle de vie d’un bloc, le diagramme d’états peut éventuellement comprendre des pseudo-états : Le terme pseudo-état est utilisé pour indiquer qu’il ne peut pas y avoir d’activités associées, ce sont essentiellement des éléments de liaisons.

Le pseudo-état initial est unique et obligatoire. Il est activé au lancement de la machine à états et marque le début de l’exécution du diagramme d’état. Il n’a aucune transition entrante.

Le pseudo-état final est optionnel. Il signe la fin de l’exécution du diagramme d’état. Lorsque cet état est activé, la machine à états s’arrête. Il n’a donc aucune transition sortante. Il peut y en avoir plusieurs car différents scénarios peuvent être possibles pour mettre fin à un comportement.

Le pseudo-état de jonction est utilisé pour regrouper des conditions de franchissement de transitions, en particulier des gardes communes à un événement. Cela permet de partager des segments de transition et d’aboutir à une notation plus lisible des chemins alternatifs. L’évaluation des conditions de garde en aval du pseudo-état est réalisée avant qu’il ne soit atteint. Par exemple, ici : on passe de l’état 10 à l’état 13 si l’événement 1 apparait et que la condition 2 est vrai.


Par exemple, ici, dès que l’évènement apparaît, le pseudo-état de choix est atteint. Si la condition est vraie, c’est l’état 3 qui devient actif, sinon, c’est l’état 2. 11.2.3 Etat composite

Une autre façon de représenter un état composite consiste à ajouter un symbole en forme d’haltère en bas à droite du rectangle à coins arrondis, puis à décrire les transitions entre ses sous-états dans un autre diagramme. On peut ainsi faire de la décomposition hiérarchique d’états, en gardant chaque niveau lisible et relativement simple. Dans la représentation ci-dessous, le diagramme précédent a été repris en transformant Radio AUTO en sous machine à états représentée dans un second diagramme.

Le pseudo-état de choix est utilisé dans deux cas : sélection et convergence de séquences exclusives. Contrairement à un point de jonction, les gardes situées après le point de décision sont évaluées au moment où il est atteint. Cela permet de baser le choix sur des résultats obtenus en franchissant le segment avant le point de choix, en particulier lorsqu’un effet (activité) est placée dans celui-ci. Les conditions de gardes doivent être exclusives. L'utilisation d'une clause [else] est recommandée après un point de décision, car elle garantit un modèle correct en englobant tout ce qui n’est pas décrit dans les autres expressions booléennes et en assurant ainsi qu’un moins un segment en aval est franchissable.

Un état composite, appelé aussi super-état, décrit les évolutions internes d’un état à l’aide d’un autre diagramme d’état. Cette structure qui permet d’englober plusieurs sous-états exclusifs qui sont considérés comme hiérarchiquement inférieur au diagramme principal, permet de rendre ce dernier plus lisible en entrant séparément dans le détail des évolutions interne du système.

Pour modéliser le comportement plus détaillé du radio réveil, une première solution consiste à transformer l’état Radio AUTO en état composite (encore appelé super-état), et à dessiner les nouveaux états à l’intérieur. On notera qu’il faut ajouter un sous-état initial pour indiquer que lorsque le bloc passe dans l’état Radio AUTO, il rentre en fait directement dans le sous état Silencieuse.


L’utilisation d’un état composite s’avère indispensable lorsque le comportement à décrire comprend des diagrammes s'exécutant en parallèle Dans un état composite orthogonal (voir ci-dessous l’exemple d’un distributeur de boissons), plusieurs graphes d'états peuvent évoluer simultanément dans des régions séparées par des pointillés. Les différentes régions de l’état orthogonal fonctionnent en parallèle sans aucune influence les unes sur les autres. Dans ce cas de figure plusieurs états sont actifs en même temps.

Chaque région peut posséder un état initial et final. Une transition qui atteint la bordure d’un état composite orthogonal est équivalente à une transition qui atteint les états initiaux de toutes ses régions. Toutes les régions d’un état composite orthogonal doivent atteindre leur état final pour que l’état composite soit considéré comme terminé. La synchronisation est alors automatique et la transition de sortie de l'état composite est déclenchée. 11.2.4 Historique d’un état composite

L’état actif au moment de la sortie d’un état composite peut être mémorisé par l’indication historique . Lors de la désactivation de l’état composite, l’état actif situé au même niveau hiérarchique est mémorisé. Lors de la réactivation de l’état composite, la machine d’état se réactive au niveau de l’état composite.

L’historique est particulièrement utilisé pour permettre à un système de recommencer en cours de cycle lors du redémarrage après un appui sur stop ou l’arrêt d’urgence (voir exemple ci-dessous).

11.3 Evènements et conditions de garde

L’évolution des états d’un système est conditionnée dans le temps à des évènements et des conditions de garde. Ces évènements et conditions de garde sont modélisés par des grandeurs logiques. 11.3.1 Evènement

Un événement est daté dans le temps et il est traité instantanément lors de son occurrence (apparition) : appui sur un bouton, arrivée en fin de course d’un mécanisme, dépassement d’une valeur seuil…


Sauf indication contraire, c’est le front montant de l’évènement qui est considéré. Il n’est pas caractérisé par une durée, c’est à dire qu’il a lieu ou non. L’événement est le déclencheur de l’évolution du système. On distingue trois types d’évènement :

- l’événement de signal prend en compte l’envoi ou la réception d’un signal : appui sur un bouton, arrivée en fin de course d’un mécanisme ;

- l’événement de changement prend en compte le changement d’une valeur interne du modèle. Il se modélise avec le mot clé when suivi d’une expression booléenne concernant une variable interne : compteur when(N=3) ;

- l’événement temporel relatif : after (T) se déclenche après une durée T passé dans l’état d’amont. Il s’agit d’une temporisation ;

- l’évènement temporel absolu : at(D) se déclenche à la date D dans un référentiel de temps dont l’origine correspond généralement au démarrage du fonctionnement du système.

11.3.2 Condition de garde

La garde est une condition d’évolution du système. C’est une condition supplémentaire à l’événement déclencheur, mais optionnelle. Elle se note entre crochets C’est une condition booléenne. Contrairement à l’événement qui lui est localisé dans le temps, elle traduit une condition qui dure dans le temps et qui doit persister : vitesse non nulle, température >20°…. Par exemple, lors de l’appui d’un bouton :

- L’événement modélise le fait de savoir s’il vient d’être enfoncé ; - La garde modélise le fait de savoir s’il est enfoncé.

La syntaxe d’une condition de garde vérifiant l'activité de l’état TOTO est : [in TOTO].

11.4 Transition

Une transition modélise la possibilité d'un passage instantané d'un état vers un autre. Elle est : orientée, n'a pas de durée et n'est évaluée que si l'état source est actif. Le franchissement de la transition est conditionné par des évènements déclencheurs et des conditions de garde. Ces événements et conditions de franchissement ainsi que l’éventuel effet associé à la transition sont indiqués le long de la flèche qui la symbolise suivant la notation :

Plusieurs transitions avec le même événement doivent avoir des conditions de garde différentes.

11.5 Activités - Effets

La gestion des activités liées à un état est organisée à partir de mots clés spécifiques au diagramme d’états.

Une activité durable introduite par le mot-clé do / à l’intérieur du symbole d’un état représente une activité qui s’exécute durant l’état associé. Un effet d’entrée (activité instantanée) introduit par le mot-clé entry / à l’intérieur du symbole d’un état représente un effet qui est exécuté chaque fois que l’on entre dans cet état. Cela permet de factoriser un même effet qui sera déclenché par toutes les transitions qui entrent dans l’état. L’effet de sortie (activité instantanée) introduit par le mot-clé exit / est l’effet symétrique en sortie de l’état.


Une transition peut spécifier un comportement optionnel réalisé par le bloc lorsque la transition est déclenchée. Ce comportement est appelé « effet » : cela peut être une simple action ou une séquence d’actions. Une action peut représenter la mise à jour d’une valeur, un appel d’opération, ainsi que l’envoi d’un signal à un autre bloc. Les activités associées aux effets sont considérées instantanées. Une transition peut ne pas avoir d’effet.

11.6 Transition interne- Transition propre

SysML propose aussi le concept de transition interne (internal transition) et de transition propre. Une transition interne représente un couple (événement/effet) qui n’a aucune influence secondaire sur l’état courant. Elle est notée simplement à l’intérieur du symbole de l’état.

Dans le cas d’une transition propre, l’élément quitte son état de départ pour y retourner aussitôt. Mais cela peut avoir des effets secondaires non négligeables comme l’interruption puis le redémarrage d’une activité durable, Commentaires sur le diagramme stm ci-dessus :

La notation de base du diagramme d’états est donnée par l’exemple de la figure de la page précédente. L’état initial est État 1, l’état final est atteint à partir de État 3 suite à l’événement destruction. La transition déclenchée par opération11 définit un effet appelé effet1. Dans l’état 2, événement 2 peut arriver et déclencher alors uniquement effet2. État 3 possède une activité durable appelée activité1. Dans l’état 3, par contre, événement 2 déclenche successivement : action de sortie, effet2, puis action d’entrée. De plus, activité 1 est interrompue, puis redémarrée.

11.7 Démarche de modélisation du comportement séque ntiel par diagramme d’états

Le cartouche général du diagramme d’états est de la forme :

stm [machine à états] nom de la machine à états [nom du diagramme]

Une bonne modélisation du comportement séquentiel d’un système, en vue de programmer son unité de commande nécessite de respecter la démarche de la page suivante :


12. Diagramme SysML d’activité « act » (Activity D iagram) Le diagramme d’activité n’est pas explicitement au programme des CPGE, toutefois, en raison des liens qu’il peut avoir avec le diagramme d’état, on peut juger nécessaire de faire une rapide présentation de ce diagramme SysML. Le diagramme d’activité est un diagramme comportemental appelé Activity Diagram (act) qui permet de représenter le déroulement d’un processus sous la forme d’une activité correspondant à une décomposition séquentielle d’actions appelées aussi tâches. Dans sa forme la plus restreinte, ce diagramme peut être comparé à un algorigramme.

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

• des actions ; • des flots de contrôle entre actions ; • des décisions (aussi appelées branchements conditionnels) ; • un début et une ou plusieurs fins possibles.

Le diagramme d’activité permet ainsi de décrire un comportement basé sur des flux associés à un traitement par tâches. Les éléments graphiques utilisés dans ce diagramme ressemblent fortement à ceux du diagramme d’états avec un rôle différent. On notera qu’il n’y a pas d’évènement associé aux transitions. Quand une tâche est finie, on passe à la suivante alors que dans le diagramme d’états on associe des événements aux transitions. Pour illustrer un exemple d’application, on donne en page suivante le diagramme d’activité d’une séquence de retrait de billets ou de dépôt d’argent sur un GAB (Guichet Automatique Bancaire)


Les éléments graphiques utilisés dans ce diagramme ressemblent fortement à ceux du diagramme d’états avec un rôle différent. On notera qu’il n’y a pas d’évènement associé aux transitions. Quand une tâche est finie, on passe à la suivante alors que dans le diagramme d’états on associe des événements aux transitions.

mouzo

Machine à écrire

Ressource : https://cahier-de-prepa.fr/CoeffinPTSI/download?id=957

Documents

CI.1. Approche pluri - PTSI Chaptal