Transcript SysML

SysML
Langage de modélisation
pour l’ingénierie système
Bruno Tatibouet & Ahmed HAMMAD
LIFC
[email protected]
[email protected]
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
An Introduction to SysML
2
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.
An Introduction to SysML
3
• Industry
SysML Partners
– 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
Introduction INCOSE,
to SysML
– AP-233, CCSDS,AnEAST,
Rosetta
4
SysML Specification Outline
•
Preface
•
Part I - Introduction
•
Part II – Structural Constructs
•
– Model Elements
•
– Blocks
– Ports and Flows
– Constraint Blocks
•
Part III – Behavioral Constructs
– Activities
– Interactions
– State Machines
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
– Use Cases
An Introduction to SysML
5
SysML et UML 2
UML 2
UML4SysML
SysML
UML
UML
reused
by 2
Reuse
SysML
SysML
extensions to
UML
(1, 2)
UML
not required
by SysML
(UML UML4SysML)
SysML Profile
Taxonomie des diagrammes
7
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)
TISYSE
An Introduction to SysML
8
SysML Diagram Frames
TISYSE
An Introduction to SysML
9
4 piliers de Sysml
10
Les diagrammes SysML
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
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
Une exigence simple
• Une exigence comporte:
– Le mot clé « requirement »
– Les propriétés id et text
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
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
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
Représentation visuelle dans
le diagramme
Notation alternative
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.
La décomposition
La décomposition
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
La dérivation
• Des exigences métiers peuvent se traduire en
exigences techniques qui peuvent aussi
conduire à d’autres exigences
La dérivation
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,
..)
Représentations tabulaires
id
name
text
S1
Operating Environment
The System …
S1.1
Weather Operation
…
S1.2
24/7 Operation
…
S2
Availability
…
id
name
relation
id
name
Rationale
D1
Sensor
Decision
derivedFrom
S1.1
24/7 Operation
…
derivedFRom
S1.2
Weather
Operation
….
Matrices
Exemple d’exigences
Cross Connecting
Model Elements
2. Behavior
1. Structure
act PreventLockup [Swimlane Diagram]
ibd [block] Anti-LockController
[Internal Block Diagram]
satisfies
«requirement»
Anti-Lock
Performance
ibd [block] Anti-LockController
[Internal Block Diagram]
d1:TractionDetector
«allocate»
act PreventLockup
[Activity Diagram]
:TractionDetector
«allocate»
:BrakeModulator
allocatedFrom
«activity»DetectLos
d1:Traction
Of
Traction
OfTraction
Detector
c1:modulator
c1:modulator
Interface
Interface
c1:modulator
interface
DetectLossOf
Traction
m1:BrakeModulator
m1:Brake
Modulator
allocatedFrom
«activity»Modulate
BrakingForce
allocatedFrom
«ObjectNode»
TractionLoss:
TractionLoss:
allocatedTo
«connector»c1:modulatorInterface
values
DutyCycle: Percentage
satisfy
Modulate
BrakingForce
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
req [package] VehicleSpecifications
[Requirements Diagram - Braking Requirements]
v.chassis.tire.
Friction:
v.brake.abs.m1.
DutyCycle:
v.brake.rotor.
BrakingForce:
v.Weight:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
Vehicle System
Specification
Braking Subsystem
Specification
«requirement»
StoppingDistance
«requirement»
Anti-LockPerformance
id=“102”
text=”The vehicle shall stop
from 60 mph within 150 ft
on a clean dry surface.”
id=”337"
text=”Braking subsystem
shall prevent wheel lockup
under all braking conditions.”
VerifiedBy
SatisfiedBy
«interaction»MinimumStopp
«block»Anti-LockController
«deriveReqt»
ingDistance
tf:
tl:
bf:
:BrakingForce
Equation
[f = (tf*bf)*(1-tl)]
c
m:
f:
F:
:Accelleration
Equation
[F = ma]
a:
a:
:DistanceEquation
[v = dx/dt]
v:
v:
:VelocityEquation
[a = dv/dt]
x:
«deriveReqt»
«deriveReqt»
3. Requirements
30
v.Position:
4. Parametrics