1 / 30

SysML Langage de modélisation pour l’ingénierie système

SysML Langage de modélisation pour l’ingénierie système. Bruno Tatibouet & Ahmed HAMMAD LIFC bruno.tatibouet@lifc.univ-fcomte.fr ahmed.hammad@lifc.univ-fcomte.fr. What is SysML?.

dafydd
Télécharger la présentation

SysML Langage de modélisation pour l’ingénierie système

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SysMLLangage de modélisation pour l’ingénierie système Bruno Tatibouet & Ahmed HAMMAD LIFC bruno.tatibouet@lifc.univ-fcomte.fr ahmed.hammad@lifc.univ-fcomte.fr

  2. An Introduction to SysML What is SysML? • A graphical modeling language in response to the UML for Systems Engineering RFP developed by the OMG, INCOSE, and AP233 • a UML Profile that represents a subset of UML 2 with extensions • Supports the specification, analysis, design, verification and validation of systems that include hardware, software, data, personnel, procedures, and facilities • Supports model and data interchange via XMI and the evolving AP233 standard (in-process) SysML is a Critical Enabler for Model Driven SE

  3. An Introduction to SysML SysML Background • UML for System Engineering RFP issued – 28 March 2003 • SysML Partners Kickoff meeting – 6 May 2003 • Chaired by S. Friedenthal and C. Kobryn • v0.9 Submission to OMG – 10 Jan 2005 • Addendum stereotypes chapter – 30 May 2005 • SST and SP split – 30 August 2005 • SST/SP revised submissions to OMG – 14 November 2005 • INCOSE and OMG Evaluations – December 2005 thru January 2006 • SysML Merge Team (SMT) submission v0.99 (ad/2006-02-01) – 13 February 2006 • SMT formally announced - 15 February 2006 • OMG Systems Modeling Language (OMG SysML) Specification-Final Adopted Specification ptc/06-05-04 – 6 July 2006 – Final public version planned in April 2007.

  4. An Introduction to SysML SysML Partners • Industry • American Systems, EADS Astrium, BAE SYSTEMS, Boeing, Deere & Company, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, Northrop Grumman, oose.de, Raytheon, THALES • Government : DoD/OSD, NASA/JPL, NIST • Vendors • Artisan, Ceira, Gentleware, IBM/Rational, I-Logix, PivotPoint Technology, Popkin, Project Technology, 3SL, Telelogic, Vitech • Liaisons • AP-233, CCSDS, EAST, INCOSE, Rosetta

  5. An Introduction to SysML SysML Specification Outline • Part IV – Crosscutting Constructs • Allocations • Requirements • Profiles & Model Libraries • Part V Appendices • Diagrams • Sample Problem • Non-Normative Extensions • Model Interchange * • Requirements Traceability • Terms and Definitions * • BNF Diagram Syntax Definitions • Preface • Part I - Introduction • Part II – Structural Constructs • Model Elements • Blocks • Ports and Flows • Constraint Blocks • Part III – Behavioral Constructs • Activities • Interactions • State Machines • Use Cases

  6. SysML et UML 2 UML4SysML SysML Profile

  7. Taxonomie des diagrammes

  8. An Introduction to SysML Major Extensions to UML 2 • New Diagram Types • Requirement Diagram (visual modeling of requirements) • Parametric Diagram (showing relations between parameters) • Structure Diagram • Block Definition Diagram (based on UML class diagram with blocks instead of classes) • Internal Block Diagram (based on UML composite structure diagram with restrictions and extensions) • Activity Diagram • extensions for continuous flow modeling • extensions to support disabling control and control operators. • accommodate needs of Extended Functional Flow Block Diagrams (EFFBDs)

  9. An Introduction to SysML SysML Diagram Frames

  10. 4 piliers de Sysml

  11. Les diagrammes SysML

  12. Requirements • Un nouveau diagramme • Pourquoi alors que l’on a les « Use Cases » ? • Les cas d’utilisation ne sont pas suffisants • Expression des fonctionnalités • Diagrammes étendus par des descriptions textuelles • Préconditions/Postconditions • Scénario(s) principal(aux) • Scénarios d’exception ou alternatifs • Mais souvent associés à une modélisation du comportement : • Interactions (Séquence) ou Activités ou Etats

  13. Requirements • Actuellement, les exigences sont : • structurées de façon arborescentes et/ou tabulaires • exprimées de façon textuelle • gérées par des outils (comme Doors) • La modélisation des exigences en SysML : • permet le lien avec ces façons de faire • permet le lien avec les outils de gestion d’exigences • ISO AP-233 • RIF : Requirement Interchange Format

  14. Une exigence simple • Une exigence comporte: • Le mot clé « requirement » • Les propriétés id et text

  15. Propriétés complémentaires • Verification status • Non vérifié, vérification par inspection,Vérification par tests, … • Criticality • High, medium, low • Requirement category • Functional, performance, physical • Alternative : sous-classes du stéréotype

  16. Les relations • Définir une hiérarchie/décomposition d’exigences • Dériver des exigences • Satisfaire des exigences • Vérifier des exigences • Raffiner des exigences • Copier des exigences • Lier une exigence et un élément du modèle

  17. Représentation des relations • Visuellement sur le même diagramme • Dans un compartiment de l’exigence ou avec une notation spécifique (callout notation) • Exemple de la relation Satisfy : • Définition : Elle relie un élément du modèle qui satisfait une exigence

  18. Représentation visuelle dans le diagramme

  19. Notation alternative

  20. La décomposition • Cette relation permet de montrer comment une exigence complexe peut être partitionnée en des ensembles d’exigences plus simples : • La décomposition entre plusieurs exigences peut être vue comme un ET logique entre celles-ci.

  21. La décomposition

  22. La décomposition

  23. La décomposition • Elle peut être vue à travers un outil de type « Browser/Explorer » • Data • Requirements • Camera Specification • Customer Specification • Availability • Operating System • 24/7 Operation • Weather Operation • System Specification • Sensor Decision

  24. La dérivation • Des exigences métiers peuvent se traduire en exigences techniques qui peuvent aussi conduire à d’autres exigences

  25. La dérivation

  26. Autres relations • Verify : entre une exigence et un cas de test • Refine : permet de réduire les ambiguités en associant une exigence à un autre élément : • Use case, Interaction, State machine, … • Copy : le texte (en lecture seule) d’une exigence peut être réutilisé ailleurs, l’id peut être modifié • Trace : relation générale entre une exigence et n’importe quel autre élément (documentation, ..)

  27. Représentations tabulaires

  28. Matrices

  29. Exemple d’exigences

  30. allocate value binding satisfy verify Cross Connecting Model Elements 2. Behavior 1. Structure 3. Requirements 4. Parametrics

More Related