REUNION NATIONALE DES CHEFS DES TRAVAUX STI2D et les modèles pour « l’ingénierie système » Lycée Diderot 17-03--2011 Jacques PERRIN - IGEN STI

Plan de l’intervention Voir « les concepts clés V2 » Principes d’usage des modèles en STI2DD SysML® version light 1er février 2011 Jacques PERRIN - IGEN

Ingénierie systèmes le programme d’enseignement transversal STI2D, place résolument l’élève dans une démarche d’ingénierie système. 1er février 2011 Jacques PERRIN - IGEN

Ingénierie systèmes Problème particulier Solutions générales Méthode Outils 1er février 2011 Jacques PERRIN - IGEN

Principes d’usage des modèles Les modèles sont utilisés en analyse « systémique ». IL NE S’AGIT PAS DE CONSTRUIRE DES MODELES Mais de structurer une démarche avec des modèles cohérents entre eux. 1er février 2011 Jacques PERRIN - IGEN

Principes d’usage des modèles A chaque problème posé un modèle adapté; Des modèles qui découlent les un des autres, c’est le principe de l’HERITAGE qui donne la cohérence dynamique de la démarche. 1er février 2011 Jacques PERRIN - IGEN

SysML® version STI2D De quoi parle-t-on ? 1er février 2011 Jacques PERRIN - IGEN

Ici on ne s’en sert pas pour spécifier SysML® version light L’ensemble des représentations abstraites utilisées ici constitue le modèle théorique unique du système. Ce modèle est utilisé et évolue progressivement dans toutes les phases d’une démarche de conception. Attention Ici on ne s’en sert pas pour spécifier Mais pour analyser 1er février 2011 Jacques PERRIN - IGEN

SysML® version light 6 Diagrammes 3 Besoins en STI2D Modélisation des exigences Modélisation structurelle comportementale 1er février 2011 Jacques PERRIN - IGEN

SysML® version light Exemple : 1er février 2011 Jacques PERRIN - IGEN Station Borne Vélo « Pass » à puce Fiche code 1er février 2011 Jacques PERRIN - IGEN

Diagramme des exigences Une exigence exprime une capacité ou une contrainte à satisfaire par un système. Elle peut exprimer une fonction que le système devra réaliser (exigence fonctionnelle) ou une condition de performance, de fiabilité, de sécurité, etc. Ce dernier type d’exigence est complémentaire aux exigences fonctionnelles. Les liens observés sur ce diagramme ont plusieurs significations : Les « raffinements » sont des éléments qui précisent ou complètent les exigences auxquelles ils sont reliés (notamment des données quantitatives) ; Les contenances permettent de décomposer une exigence en plusieurs exigences élémentaires, plus faciles à quantifier tout au long du développement du projet. L’exigence « 3 - Gestion par code » est ici identifiées comme une exigence « composite », ce qui signifie qu’elle est, en réalité, composée de plusieurs exigences élémentaires qui peuvent être décomposées par des relations de contenance, comme sur la figure 3. Comme sur tous les diagrammes on a la possibilité de porter des commentaires. Ici on note deux types de commentaires : Les problèmes (« Problem ») qui pointent un ou des problèmes restant à résoudre ; Les justifications (« Rationale ») qui permettent de justifier certains choix. Cette déclinaison des commentaires n’a rien d’obligatoire, un « commentaire » n’a pas besoin d’être typé « Cartouche » : Indique le type de diagramme (req), le type de l’élément concerné, l’élément concerné, et le nom du diagramme « Exigence » : (fonctionnelle) « Raffinement» : Permet de préciser les exigences (détails, ajouts de données, etc.) « Contenance » : Permet de décomposer l’exigence. « Commentaire » 1er février 2011 Jacques PERRIN - IGEN

SysML® version light La modélisation des exigences pour définir les objectifs et les contraintes Le diagramme des exigences («requirements ») permet de répertorier et d’analyser les contraintes et performances du système. Ce diagramme est un outil de représentation des fonctionnalités du système. 1er février 2011 Jacques PERRIN - IGEN

Diagramme des cas d’utilisations «Ce diagramme est une représentation des fonctionnalités du système. Il indique dans quel cas ce système est utilisé et par qui. Un tel diagramme dépend à la fois du point de vue de son rédacteur et de l’objectif de modélisation. C’est à partir de ces « cas d’utilisation » que l’ensemble de la description fonctionnelle se décline. Un diagramme des cas d’utilisation peut se compléter au fur et à mesure que l’analyse du problème se précise. C’est notamment le rôle des « extensions » (extend) et des « inclusions » (include). Enfin, il est toujours possible de commenter le graphe à l’aide de « notes ».  Extension » : Précise le comportement d’un cas d’utilisation. « Acteur » : Personne ou composant à l’origine d’une interaction « Association » : Peut être renseigné par sa nature. « Inclusion » : Cas d’utilisation inclus dans le précédent. « Cas d’utilisation » : Objectif du système pour répondre à un besoin de(s) utilisateur(s). « limite du système » : Délimite les cas d’utilisation du système ou sous-système représenté. 1er février 2011 Jacques PERRIN - IGEN

Diagramme de séquences Ordre chronologique vers le bas Temps Ce diagramme décrit le scénario des interactions dans le temps entre les acteurs et les objets Il montre sous forme de scénario la chronologie des échanges issus d’un cas d’utilisation. Chaque élément actif du système est représenté par un rectangle doté d’une « ligne vie » verticale. La chronologie des événements se lit de haut en bas. Des rectangles verticaux étroits représentent les périodes d’activité de l’élément actif d’une ligne de vie. Cette notation n’est pas indispensable mais facilite la compréhension du diagramme. Un message représenté par une flèche pleine indique que l’émetteur attend une réponse (reste inactif). Une flèche pointillée représente un retour direct du message précédent. « Ligne de vie » : Représente l’existence d’un élément actif. « Message » : Déclenche un évènement chez le récepteur. « Opération interne » : traitement interne au système (sans échanges avec les acteurs et autres objets) 1er février 2011 Jacques PERRIN - IGEN

Diagramme d’états Le diagramme d’états décrit les états successifs d’un « objet » (système, sous-système, composant, …) en réaction à des «événements », les transitions. Il permet de montrer les événements qui provoquent un changement. Il est possible de représenter des évolutions d’états en parallèle en utilisant les symboles de bifurcation et d’union. « État initial » « Évènement » (condition) « État courant » Bifurcation Union 1er février 2011 Jacques PERRIN - IGEN

Diagramme de définition de blocs  Ce diagramme défini les éléments de structure d’un système, sous-système ou constituant et leurs propriétés. Les « blocs » représentent des éléments physiques (cas de la figure ) ou des entités logiques. Les « valeurs » décrivent les caractéristiques des éléments (valeurs, dimensions, niveau, …). Les blocs qui le composent en « héritent ». On peut aussi mentionner les « parties » (parts) quand un bloc est composé d’autres blocs (exemple : alimentation de la borne). « Bloc » et son identification « Composition » : Indique que les blocs du dessous font partie du bloc marqué par un losange plein. « Valeurs » : Indique les propriétés du bloc. 1er février 2011 Jacques PERRIN - IGEN

Diagramme de blocs internes Ce diagramme décrit, outre l’architecture matérielle d’un système, les échanges internes entre ses éléments ou avec l’extérieur. Les blocs qui le constituent peuvent décrire un système complet, un sous-système ou un composant élémentaire. Ils sont décomposables tant en structure qu’en comportement. Ils représentent des entités physiques, mais aussi des entités logiques. Les ports décrivent les points d’interaction entre blocs. Il y a deux sortes de ports : Les ports de flux qui expriment la circulation de flux physiques entre les blocs (énergie, fluides, données, …) ; Les ports standard qui expriment des échanges logiques entre blocs. Les ports standards ne peuvent être connectés aux ports de flux. Port de flux bidirectionnel (données) Bloc interne Port standard (information logique) Port de flux Unidirectionnel (physique) Bloc 1er février 2011 Jacques PERRIN - IGEN

Merci de votre attention 1er février 2011 Jacques PERRIN - IGEN