Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

INSA de Lyon TD AUT/Projet AUT/Projet Co 4GI DEMARCHE PROJET D'AUTOMATISME & MO

INSA de Lyon TD AUT/Projet AUT/Projet Co 4GI DEMARCHE PROJET D'AUTOMATISME & MODELISATION SYSML 1 Ingénierie Système..............................................................................................1 1.1 IEEE 1 220 : Standard for Application and Management of the Systems Engineering Process, 1999.................................................................................2 1.2 EIA 632 : Processes for Engineering a System, 1998...................................3 2 Modélisation avec SysML.....................................................................................3 2.1 Pourquoi SysML ?..........................................................................................3 2.2 Les diagrammes de SysML...........................................................................4 3 Modélisation des exigences.................................................................................6 3.1 Définition des exigences..............................................................................6 3.1.1 Diagramme(s) des exigences................................................................6 3.1.2 Intérêt de la définition de ces exigences...............................................7 3.2 Cas d'utilisation............................................................................................8 3.2.1 Représentation graphique ....................................................................8 3.2.2 Description textuelle.............................................................................8 3.2.3 Exemple de description pour une des fonctions d'un MES....................9 3.3 Définition des séquences d'utilisation du système.......................................9 4 Références........................................................................................................12 1 Ingénierie Système L’ingénierie système (IS) est une démarche méthodologique pour maîtriser la conception des systèmes et produits complexes. On peut aussi la définir comme « une approche interdisciplinaire rassemblant tous les efforts techniques pour faire évoluer et vérifier un ensemble intégré de systèmes, de gens, de produits et de solutions de processus de manière équilibrée au fil du cycle de vie pour satisfaire aux besoins client ». Les pratiques de cette démarche sont aujourd’hui répertoriées dans des normes, réalisées à l'aide de méthodes et supportées par des outils. Trois normes générales d’ingénierie système décrivant les processus du métier d’IS sont actuellement disponibles. Elles en définissent les types d’activité à réaliser et les types de résultat produit. Elles recouvrent des champs différents, de manière d’autant plus approfondie que leur champ est limité, et ainsi elles se complètent. • IEEE1220: Standard for Application and Management of the Systems Engineering Process • EIA632: Processes for Engineering a System • ISO15288: Systems engineering – System life cycle processes A.LELEVE 1/24 modelisation-SysML-v2,1.odt INSA de Lyon TD AUT/Projet AUT/Projet Co 4GI 1.1 IEEE 1 220 : Standard for Application and Management of the Systems Engineering Process, 1999 Issue du standard militaire MIL STD 499B, cette norme de l’IEEE, dont la version initiale date de 1994, se focalise sur les processus techniques d’ingénierie système allant de l’analyse des exigences jusqu’à la définition physique du système. A.LELEVE 2/24 modelisation-SysML-v2,1.odt INSA de Lyon TD AUT/Projet AUT/Projet Co 4GI 1.2 EIA 632 : Processes for Engineering a System, 1998 Cette norme de l’EIA complète les processus techniques de définition du système en couvrant la réalisation des produits jusqu’à leur mise en service (transfert vers l’utilisation). De plus, elle incorpore les processus contractuels d’acquisition et de fourniture. Processus techniques et processus contractuels sont encadrés : • par les processus de management (selon leur forme traditionnelle avec les trois sousprocessus de planification, évaluation, pilotage) ; • et par les processus d’évaluation des résultats des activités (processus de vérification s’assurant que l’activité a été bien faite, processus de validation s’assurant que le résultat répond au besoin, les deux justifiant de la conformité, et processus d’analyse système justifiant des choix réalisés tout au long de la définition et donc de l’optimisation du système). 2 Modélisation avec SysML 2.1 Pourquoi SysML ? L’ingénierie système est une démarche méthodologique générale qui englobe l’ensemble des activités adéquates pour concevoir, faire évoluer et vérifier un système apportant une solution économique et performante aux besoins d’un client tout en satisfaisant l’ensemble des parties prenantes. La transformation d’un besoin émergeant en la définition d’un système lui apportant une solution met en oeuvre de multiples activités intellectuelles faisant passer progressivement de concepts abstraits à la définition rigoureuse de produits. Il est nécessaire de s’appuyer sur des représentations tant du problème que de ses solutions possibles à différents niveaux d’abstraction pour appréhender, conceptualiser, concevoir, estimer, simuler, valider, justifier des choix, communiquer. C’est le rôle de la modélisation ! A.LELEVE 3/24 modelisation-SysML-v2,1.odt INSA de Lyon TD AUT/Projet AUT/Projet Co 4GI Les métiers mis en oeuvre en IS ont, de tous temps, utilisé des modèles allant de représentations des plus concrètes, telles que les plans ou modèles réduits, aux plus abstraites, telles que les systèmes d’équations. Le monde du logiciel a fini par se mettre d’accord à la fin des années 90 sur un formalisme de modélisation unifié : UML.Par contre, de leur côté, les ingénieurs système n’ont pas réussi à faire émerger un langage de modélisation uniformisé, malgré les tentatives de standardisation des processus d’ingénierie système évoquées précédemment. L’OMG (Object Management Group : groupement d’industriels (plus de 800 membres) dont l’objectif est de standardiser autour des technologies objet, afin de garantir l’interopérabilité des développements) a annoncé l’adoption de SysML en juillet 2006 et la disponibilité de la première version officielle (SysML v. 1.0) en septembre 2007. Très récemment, une nouvelle spécification SysML v. 1.1 a été rendue publique (décembre 2008). Le groupe de travail pour la révision 1.2 est déjà en action. 2.2 Les diagrammes de SysML 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. Ces types de diagrammes sont répartis par l’OMG en trois grands groupes : • quatre diagrammes comportementaux : 1. diagramme d’activité (montre l’enchainement des actions et décisions au sein d’une activité complexe). Il représente les flots de données et de contrôle entre les actions ; 2. diagramme de séquence il montre la séquence verticale des messages passés entre blocs au sein d’une interaction. Il représente les interactions entre les parties du système qui collaborent ; 3. diagramme d’états il montre les différents états et transitions possibles des blocs dynamiques. Il décrit les transitions entre états et les actions que le système ou ses parties réalisent en réponse aux événements ; 4. diagramme de cas d’utilisation : A.LELEVE 4/24 modelisation-SysML-v2,1.odt INSA de Lyon TD AUT/Projet AUT/Projet Co 4GI il montre les interactions fonctionnelles entre les acteurs et le système à l’étude. Il fournit une description de haut niveau des fonctionnalités du système ; • un diagramme transverse : 1. le diagramme d’exigences : il montre les exigences du système et leurs relations. Il capture les hiérarchies d’exigences, ainsi que leurs relation de dérivation, de satisfaction, de vérification et de raffinement. Ces relations fournissent la capacité de relier les exigences les unes aux autres, ainsi qu’aux éléments de conception et aux cas de tests ; • quatre diagrammes structurels : 1. diagramme de définition de blocs (block definition diagram): il montre les briques de base statiques : blocs, compositions, associations, attributs, opérations, généralisations, etc.). Il décrit ainsi la hiérarchie du système et les classifications système/ composant ; 2. diagramme de bloc interne (internal block diagram) : Il décrit la structure interne du système en termes de parties, ports et connecteurs ; 3. diagramme paramétrique : il représente les contraintes du système, les équations qui le régissent. Il permet de représenter des contraintes sur les valeurs de paramètres système tels que performance, fiabilité, masse, etc. 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 relations mathématiques. Ce nouveau diagramme fournit ainsi un support pour les études d’analyse système ; 4. diagramme de packages il montre l’organisation logique du modèle et les relations entre packages. Il est utilisé pour organiser le modèle ; A.LELEVE 5/24 modelisation-SysML-v2,1.odt INSA de Lyon TD AUT/Projet AUT/Projet Co 4GI SysML inclut également une relation d’allocation pour représenter différents types d’allocation, comme celles de fonctions à des composants, de composants logiques à composants physiques, ainsi que de software à hardware 3 Modélisation des exigences 3.1 Définition des exigences 3.1.1 Diagramme(s) des exigences Il ressemble à celui-ci, dessiné ici pour un radio réveil : Les exigences pouvent être décomposées en sous-exigences : on utilise alors un lien de composition. Elles peuvent également être chfifrées; on établit alors une relation de type « refine ». Il est courant de définir d’autres propriétés pour les exigences, par exemple : • 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, implémentée, testée, livrée, etc.) ; • méthode de vérification (par exemple : analyse, démonstration, test, etc.). A.LELEVE 6/24 modelisation-SysML-v2,1.odt INSA de Lyon TD AUT/Projet AUT/Projet Co 4GI Il est également possible de faire la distinction entre différents types d’exigences, au lieu d’utiliser un unique type banalisé : fonctionnelle (« functional Requirement »), performance (« Perfromance Requirement »), fiabilité, sécurité, volumétrie, • physique, • interface, etc. Pour approfondir, d'autres relations et objets existent... 3.1.2 Intérêt de la définition de ces exigences 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. Elle 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ément SysML par plusieurs relations : • exigence – élément comportemental (cas d’utilisation, diagramme d’états, etc.) : « refine » ; • exigence – bloc d’architecture : « satisfy » ; • exigence – cas de test (test case : ellipse uploads/Industriel/ modelisation-sysml-v2-1-pp12-24.pdf