Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Introduction à Sysml
Similaire à Introduction à Sysml (20)
Dernier
Dernier (15)
Introduction à Sysml
- 1. Exposé: Ingénierie logiciel Sujet: Introduction à SysML RÉALISÉ PAR: YASSINE SIDKI HAMZA CHETTOUR NOAMANE ELFARTAKH YASMINE SLAOUI KAOUTAR LAGDANI SALSABIL ADLY PROPOSÉ PAR: M. ALEXIS TODOSKOFF 1
- 3. Ingénierie Système Etude DCNS : Comparer entre Arbre de défaillance et modélisation formelle Les résultats obtenus avec la modélisation systémique est plus représentatif de l’exploitation réelle du système, ceci montre que la méthode classique peut présenter un résultat optimiste par rapport à la réalité. 3
- 4. Plan Introduction Historique C’est quoi SysML? Pourquoi nous utilisons SysML ? Différence entre UML et SysML Les 9 diagrammes Application 4
- 5. Historique Initiation du besoin en Janvier 2001 par INCOSE (international Council on System Engineering) Juillet 2001: INCOSE et OMG (Object Management Group), créent un groupe d’intérêt spécifique dans le domaine de l’ingénierie système. Novembre 2005 : OMG annonce l'adoption de SysML Septembre 2007 : spécifications de la version 1.0 rendues officielles 3 Décembre 2008 : SysML v1.1 8 Septembre 2010: Possibilité d’être « OMG Certified Systems Modeling Professional » 16 Juin 2010 : SysML v1.2 8 Juin 2012: SysML v1.3 (version actuelle) Mars 2014: SysML v1.4 (version beta) 5
- 6. C’est quoi SysML ? SYSTEMS MODELING LANGUAGE OU SYSML EST UN LANGAGE DE MODÉLISATION GRAPHIQUE DÉRIVÉ D'UML MAIS QUI VA BIEN AU DELÀ DES PROBLÉMATIQUES DE L'INFORMATIQUE. C’EST UN LANGAGE DE MODÉLISATION SPÉCIFIQUE AU DOMAINE DE L'INGÉNIERIE SYSTÈME. 6
- 7. Spécifier les systèmes Analyser la structure et le fonctionnement des systèmes Décrire les systèmes et concevoir des systèmes composés de sous-systèmes Vérifier et valider la faisabilité d'un système avant sa réalisation En utilisant SysML on peut : 7
- 8. Durant le cycle de vie : 8
- 9. SysML peut intégrer : Les composants physiques de toutes technologies Les programmes Les données et les énergies Les personnes Les procédures et flux divers 9
- 11. Systèmes de plus en plus complexe 11
- 12. 12
- 13. Même exigences, même problématique, différents points de vues, différentes modélisations !!! 13
- 14. Sommation pas évidente !!! 14
- 15. Solution : Modélisation unifié du probléme Compréhension généralisée des exigences Prendre en considération les relations interdisciplinaires Faciliter l’intégration des solutions Faciliter la validation généralisée sur toute les parites Etude de faisabilité étendue est généralisée sur toutes les parties prenantes Bref, la solution est SysML 15
- 16. Différence entre SysML et UML La communauté de l’Ingénierie Système a voulu définir un langage commun de modélisation pour les ingénieurs système, comme UML l’est devenu pour les informaticiens. SysML représente un sous-ensemble d'UML2, avec des extensions pour représenter : Les exigences d'un système. Les éléments non-logiciels . Les équations physiques . Les flux continus. 16
- 17. Différence entre SysML et UML Le SysML utilise des « Block » alors que l’UML utilise des « Class ». Le bloc est utilisé pour représenter : Le bloc peut contenir de nombreux compartiments : 17
- 18. Différence entre SysML et UML SysML UML 2 Non requit par SysML Partie réutilisée par SysML Diagrammes ajoutés Les diagrammes sont moins nombreux et le SysML réutilise une bonne partie des diagrammes utilisé déjà en UML. 18
- 19. Diagramme des exigences Diagrammes paramétriques Diagramme de blocs internes Diagramme de définition de bloc Diagramme d’activité Diagramme de paquetage Diagramme de séquence Diagrammes d’état Diagrammes de cas d’utilisation Différence entre SysML et UML Diagrammes SysML 19
- 20. Diagrammes adaptés Block Definition Diagram (BDD) Internal Block Diagram (IBD) 20
- 21. Block Definition Diagram (BDD) Il est utilisé pour décrire l’architecture matérielle du système. Un bloc est une entité bien délimitée qui encapsule principalement des attributs, des opérations ,des contraintes, des ports et des parts. Un bloc peut modéliser tout le système, un élément matériel ou logiciel. • Principe : 21
- 22. Block Definition Diagram (BDD) Etude de cas : Amplificateur de guitare • Le Bloc : 22
- 23. Block Definition Diagram (BDD) 6 1 1 1 Composition Association • Les relations : 23
- 24. Internal Block Diagram (IBD) Le diagramme de bloc interne (IBD, ou Internal Block Diagram) décrit la vue interne d'un bloc. Il permet en plus de représenter les ports, les connections et les échanges entre les différents acteurs/parties du système . Il utilise le DDB pour assembler les blocs qui composent le bloc principal. • Principe : 24
- 25. Internal Block Diagram (IBD) • Les parties : 25
- 26. Internal Block Diagram (IBD) • Les ports : 26
- 28. Diagramme des exigences Enumérer les exigences auxquelles le système est soumis Découper les exigences afin d’avoir une vue plus précise et plus logique Améliorer la communication entre différents services (Technique, Marketing…) 28
- 29. Diagramme des exigences « Requirement » 29
- 30. Diagramme des exigences 30
- 31. Diagramme des exigences 31
- 32. Diagramme des exigences 32
- 33. Diagramme paramétrique Intégrer des analyses systèmes avec des blocs de contraintes 33
- 34. Diagramme paramétrique Exemple : Etude de la dynamique de véhicule instanciation 34
- 35. Spot Motorisé Application Dans une galerie d’art 35
- 36. Application Eclairer Commander les mouvements Régler l’orientation de la lumière Réaliser la maintenance Utilisateur Acteur Principal Installeur Installer Respecter les normes Milieu Ambiant Energie Tableau Support : - Plafond - Mur Marché Mettre sur le marché Recycleur Recycler Acteurs Secondaires Acteurs Matériels Diagramme des cas d’utilisation 36
- 37. Application : Diagramme d’exigences Orienter Facilement Fonction Exigence <<requirement>> Réglage de l’Orientation ID : <<001>> Text : << On doit pouvoir Facilement orienter le Spot >> 37
- 38. Application : Diagramme d’exigences <<requirement>> Réglage de l’Orientation ID : <<001>> Text : << On doit pouvoir Facilement orienter le Spot >> <<requierement>> Gestion de l’élévation •ID : <<002>> •Text : << On doit pouvoir régler l’élévation du spot>> X <<requierement>> Gestion de l’angle •ID : <<003>> •Text : << On doit pouvoir régler l’angle du spot>> X <<requierement>> Gestion de l’angle •ID : <<004>> •Text : << L’amplitude de l’angle sera de 180°>> 38 Inclus dans Ajouts (compléments)
- 39. Application : Diagramme de bloc interne 39
- 40. Application : Diagramme de bloc interne <<system>> : Spot Lumineux m/a Lumière Port Standard <<external>> : Prise éléctrique Alimentation : Electricité Prise : Electricité <<external>> : Plafond / Mur Maintien : Flux d’actions mécaniques <<external>> : Tableau Projection : Lumière : Utilisateur 40
- 41. Questions ? Merci pour votre attention 41
Notes de l'éditeur
- Object Management Group (OMG): est une association américaine à but non lucratif créée en 1989 dont l’objectif est de standardiser et promouvoir le modèle objet sous toutes ses formes. L'initiative SysML est issue d'une décision de janvier 2001 du groupe de travail sur la modélisation des systèmes pilotés par les modèles de l'International Council on Systems Engineering (INCOSE), afin de modifier UML pour les applications d'ingénierie système. Suite à cette décision, l'INCOSE et l'Object Management Group(OMG), qui maintient la spécification UML, ont créé conjointement un groupe d'intérêt spécifique dans le domaine de l'ingénierie système (OMG Systems Engineering Domain Special Interest Group ou bien OMG SE DSIG)) en juillet 2001. Le SE DSIG, avec le soutien d'INCOSE et du groupe de travail ISO AP 233, a développé les spécifications du langage de modélisation, qui fut repris ensuite par l'OMG en tant que UML for Systems Engineering Request for Proposal (UML for SE RFP; document OMG ad/03-03-41) en mars 20032. En 2003, Cris Kobryn et Sanford Friedenthal organisèrent et dirigèrent conjointement les "Partenaires SysML" (SysML Partners) au sein d'une association informelle des acteurs majeurs de l'industrie et des vendeurs d'outils3, qui initièrent un projet open source de spécification pour développer SysML en réponse au RFP UML pour l'ingénierie des systèmes1. Les Partenaires SysML distribuèrent leur premier brouillon de la spécification open source SysML en 2004, et soumirent SysML 1.0a à l'OMG qui l'adopta en novembre 2005.
- Les flux continus (matière, énergie, etc.) Les éléments non-logiciels (mécanique, hydraulique, capteur…) UML: langage de modélisation unifié , est un langage de modélisation graphique qu’on utilise dans les projets logiciels
- Une classe représente une catégorie d'objets L'UML est un langage permettant de modéliser les classes et leurs interactions, alors que le SysML permet de modéliser les blocks et leurs interactions. Le bloc est l'élément structurel de base en SysML, La propriété de type « Part » qui est une partie intégrante du bloc elle même caractérisée par un bloc. Par exemple : « roueAvantDroite:Roue » La propriété de type « Reference » qui décrit un bloc qui ne fait pas partie intégrante du bloc. Toutes les propriétés qui ne sont pas des compositions. La propriété de type « Value » qui définit une valeur quantifiable avec son unité, sa dimension, ou sa distribution statistique comme par exemple : pressionPneu:psi=30 ou « uniform » {min=28,max32}pressionPneu:psi
- Le passage d’UML à SysML est très simple. SysML est un langage plus réduit qu'UML ce qui facilite son apprentissage et son utilisation. SysML supprime beaucoup de concepts d'UML trop liés à sa vision centrée sur le logiciel. L'ensemble du langage SysML est plus petit, tant en nombre de types de diagrammes qu'en nombre de concepts . SysML est une extension de UML 2
- Ce nouveau langage, nommé SysML, est fortement inspiré de la version 2 d’UML, tout en essayant d'être plus concis et mieux adapté aux problématiques de l'ingénierie des systèmes complexes. Sysml a réutilisé sept de treize diagrammes d’UML. il ajoute deux diagrammes spécifiques plus les tableaux d'allocations. Les changements sont : Diagrammes supprimés : 6 diagrammes Diagrammes ajoutés : 2 diagrammes Diagrammes adaptés : 2 diagrammes Diagrammes conservés : 5 diagrammes
- attributs (variables d’état), opérations (procédures comportementales) des ports (échange de flux avec l’extérieur) des parts (sous-blocs internes).
- Pour aborder,ce diagramme de definition de bloc , nous allons utiliser, comme exemple un amplficateur de guitare : Un bloc est représenté graphiquement par un rectangle comportant plusieurs compartiments. Le compartiment supérieur contient le nom du bloc le compartiment constraint permet de définir les contraintes de la fonction. Le compartiment Operations détaille les actions réalisées par le bloc. Le compartiment inférieur contient les paramètres qui définissent les instances du bloc : les parties, les références, les valeurs et/ou les propriétés. Dans l'exemple ci-dessus, l'amplificateur converti un signal électrique en signal sonore tout en assurant une amplification et une correction de tonalité. Son fonctionnement est conditionné par l'alimentation en énergie électrique. Les différents réglages constituent les différents paramètres.
- La composition, Le bloc « cordes » entre dans la composition de la guitare électrique et lui est indispensable. Exemplela guitare et les cordes de guitare : Sans cordes, la guitare n'a pas de sens mais les cordes sont contenues dans la guitare. Une relation de composition est représentée par un losange plein. L'association représentée par un trait simple. Elle lie deux blocs égaux. Si on prend comme exemple, l'ensemble guitare + amplificateur, chaque sous-système est indépendant, mais ils sont liés. L'agrégation est identique à la composition, à la différence prêt que le contenu a une existence sans le contenant. Par exemple une salle de classe est composée de tables et de chaises mais sans tables ni chaise la salle peut encore être utilisée. Une relation d'agrégation est représentée par un losange vide. Les lignes de relation sont associées à des numéros. Dans l'exemple ci-dessus, il y a 6 cordes sur la guitare électrique (dans la cas d'une guitare basse on mettrait généralement 4 cordes ou 12 pour une guitare 12 cordes). Le bloc CORDES est donc associé à 6 et le bloc guitare à 1. Dans le cas de l'amplificateur pris comme exemple seule une guitare peut être racordée à son entrée d'où le chiffre "1" des deux cotés de la ligne. Dans le cas où le nombre est indéterminé, on peut mettre une étoile (cas des tables dans une salle de classe.)
- On reconnait le diagramme de bloc interne par les trois lettres ibd qui surplombent le diagramme.
- Je ne vais pas rentré dans les détails , mais je vais juste parcourir les notions de base de ce diagramme : Les « parts » ou « properties » d'un bloc du diagramme de définition de bloc peuvent devenir des parties du diagramme de bloc interne.
- Les ports sont des "points d'interaction" de la partie. Ils peuvent être de deux natures : *les ports standards pour exposer des interfaces, et les ports de flux (flow ports) pour représenter ce qui peut circuler en entrée et/ou en sortie d’un bloc, que ce soit des données, de la matière ou de l’énergie. Seuls les ports de même type peuvent être reliés entre eux. Comme le montre la figure ci-dessus, les ports de type flux ont une direction (d'un port OutFlow vers InFlow) mais il existe également des ports d'entrée/sortie InOutFLow.