Cours Poo - Uml-Sysml

Cours POO « UML-SYSML »
UNIVERSITE CENTRALE/POLYTECH
Module POO (UML/SysML)
Enseignant : BOUBAKRI Mohamed Naceur

Ingénieur Général – Consultant Senior IT
1
BOUBAKRI M.N – HONORIS UU -
Chapitre I : Généralités
1-Historique de la notation SysML

La modélisation avec le langage UML est une pratique bien établie
dans l'industrie logicielle. Bien que le langage UML permette par son
caractère à usage général d'adresser de nombreux besoins pour
l'Ingénierie des Systèmes (IS), il est nécessaire d'adapter ce langage
de modélisation par la définition de « profils UML ». Plusieurs projets
ont été menés pour réaliser des profils UML sur des domaines
spécifiques de l'IS :
MARTE : profil UML pour des systèmes embarqués en temps-réel
Profil UML SoC (System on a Chip)
Le besoin de définir un langage basé sur UML pour l'IS a été initié en
2001 par l'organisation internationale de l'ingénierie
système INCOSE (International Council on Systems Engineering), qui
s'est mise en relation avec l'OMG (Object Management Group),
organisme responsable d'UML, pour créer le groupe d'intérêt
spécialisé dans les domaines de l'IS ou « SE DSIG » (Systems
Engineering Domains Special Interest Group).
Suite à de nombreux ateliers, l'INCOSE et l'OMG ont défini et publié
la demande de proposition « UML pour l'IS » en 2003 (UML for SE
RFP - Request For Proposal).
Plusieurs membres de l'industrie (BAE, Motorola, oose, Boeing.),
éditeurs d'outils (IBM, Sparx Systems.), universités et organisations
(INCOSE, AP233) ont travaillés sur la définition du langage de
modélisation système SysML (Systems Modeling Language).
Juillet 2006 : OMG annonce l'adoption de SysML
Septembre 2007 : spécifications de la version 1.0 rendues officielles
Décembre 2008 : SysML v1.1
2
Juin 2010 : SysML v1.2 (version actuelle)
2-Objectifs de SysML
-SysML est à l'ingénierie des systèmes complexes et/ou hétérogènes
ce qu'UML est à l'informatique. SysML doit permettre à des acteurs
de corps de métiers différents de collaborer autour d'un modèle
commun pour définir un système.
-SysML est un moyen de regrouper dans un modèle commun à tous
les corps de métiers, les spécifications, les contraintes, et les
paramètres de l'ensemble du système.
-SysML n'aborde plus la conception avec la notion de classes mais
avec la notion de blocs qui deviendrons des parties mécaniques,
électroniques, informatiques ou autres.
3-Les avantages d'une modélisation SysML sont :

 Partage des spécifications d'un système complexe entre tous les
corps de métiers.
 Identification des risques et création d'une base d'analyse
commune à tous les participants d'un projet.
 Facilite la gestion de projets complexes, l'évolutivité et la
maintenabilité des systèmes complexes.
 Documente et capitalise le savoir de tous les corps de métiers
dans un projet.
SysML est fait pour :

 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.
3
 Vérifier et valider la faisabilité d'un système avant sa

réalisation.
SysML intègre :
 Les composants physiques de toutes technologies.
 Les programmes.
 Les données et les énergies.
 Les personnes.
 Les procédures et flux divers.
4-La réalisation :
La réalisation, la mise en production et l'exploitation d'un système
va être différent d'une industrie à l'autre.
Entre l'automobile, l'aviation ou le médical on trouvera toujours
certaines similitudes mais il est impossible de faire une description
générique commune à toutes ces industries.
De plus un modèle SysML est fait pour représenter des systèmes
hétérogènes complexes mettant en œuvre des technologies issues de
corps de métiers différents comme la mécanique, l'électronique et
l'informatique.
Il paraît donc impossible de définir une méthodologie réellement
commune à tous les métiers du monde.
5-La capture des besoins
La capture des besoins est une phase fondamentale dans la
réalisation d’un projet SysML. L'avantage de SysML est que nous
disposons en plus du diagramme d'exigence « Requirement
diagram », du diagramme paramétrique et des représentations en
vue du diagramme de package. On dispose aussi des blocs « block
definition diagram » et « internal block definition diagram ».
Pour la capture des besoins :
 Définir le contexte général (métier, juridique, etc...) et organiser
tous ces éléments à travers le diagramme d'exigence.
4
 Définir les acteurs humains ou non qui vont interagir avec le

système.
 Définir les fonctionnalités attendues du système avec un
diagramme de Use Case.
 Définir le contexte technique du projet (serveurs, réseau, etc...)
en donnant une représentation des blocs qui le définissent.
 Définir le fonctionnement dynamique du système avec en plus
des diagrammes de séquence, d'activité et d'état, le diagramme
paramétrique.
 Définir les besoins en interface homme machine (IHM) s'il y en
a.
 Rédiger un cahier des charges fonctionnel et technique qui
permettra à la fois de réaliser le projet et de le valider au fur et
à mesure jusqu'à la phase de recette finale.
6-Démarche :
Tout comme dans l'étude UML, nous n'avons pas de méthode
parfaite ou universelle pour aborder une modélisation SysML.
Nous allons vous proposer ici une démarche qui se présente de
façon chronologique du fait que la rédaction nous oblige à mettre les
choses dans un certain ordre. Cependant dans la réalité des faits
nous avons souvent à faire des aller et retours entre ces différentes
parties de la capture des besoins.
Pour être tout à fait honnête durant la mise en œuvre d'un projet il
est même possible de revenir sur la définition des besoins techniques
ou fonctionnels quand on est en phase de modélisation ou de
réalisation.
Cependant il est préférable de limiter ce genre de retour en arrière
qui peut déstabiliser complètement le projet.
7-Définition du métier et du contexte
5
SysML est beaucoup plus performant que UML pour décrire le

contexte général d'un projet car les diagrammes d'exigence, de bloc
et paramétrique permettent une description bien plus complète.
Cependant la toute première action va consister à collecter les
spécifications (ci-dessous « Requirements) pour ensuite faire
l'analyse qui nous amènera à la définition puis à la validation du
système.
8- L'Ingénierie Système (IS)
L'Ingénierie Système (IS), ou Systems Engineering en anglais (SE),

est une démarche méthodologique pour répondre à des problèmes
complexes par la réalisation de solutions logicielles et matérielles.
L'Ingénierie Système s'adresse aux secteurs suivants de l'activité

industrielle :
 Automobile
 Ferroviaire
 Aéronautique
 Espace
 Militaire
 Systèmes embarqués (ex : encodage/décodage vidéo et audio, set
top box)
 Télécoms
 Santé/médical
 Production d'énergie, etc.
6
Chapitre II- Notions de base UML, SysML et comparatif des

diagrammes
UML, langage de modélisation très répandu pour les développements

logiciels, a été utilisé et adapté pour définir un langage de
modélisation des systèmes
: SysML ou Systems Modeling Language.
Présentation de la notation SysML
SysML (Systems ModelingLanguage) est basé sur UML et remplace

la modélisation de classes et d'objets par la modélisation de blocs pour
un vocabulaire plus adapté à l'Ingénierie Système. Un bloc englobe
tout concept logiciel, matériel, données, processus, et même la gestion
des personnes.
Comme représenté sur la figure suivante, SysML réutilise une partie

d'UML2 (« UML4SysML » ou « UML pour SysML »), et apporte
également ses propres définitions (extensions SysML). SysML
n'utilise donc pas les 13 diagrammes définis par UML 2, permettant
ainsi d'accéder à un ensemble de diagrammes accessibles et adaptés à
l'IS.
UML4SysML :
7
 Diagramme de séquence
 Diagramme d'états
 Diagramme de cas d'utilisations
 Diagramme d'activités
 Diagramme de paquetage
 Diagrammes de classe et structure composite (utilisés pour les
diagrammes de définitions de blocs et de bloc interne - BDD &
IBD)
Extensions SysML:
 Définitions pour les diagrammes de définitions de blocs et de

bloc interne - BDD & IBD
 Modifications dans le diagramme d'activités
 Diagramme d'exigences (requirements) - Nouveau
 Diagramme paramétrique - Nouveau
 Allocations (traçabilité) - Nouveau
SysML : 9 diagrammes - 4 structurels, 4 dynamiques, et les

diagrammes d' exigences :
 Structurels
o Le « Block Definition Diagram » (BDD) remplace le
diagramme de classes
o L' « Internal Block Diagram » (IBD) remplace le
diagramme de structure composite
o Le diagramme de paquetage reste inchangé
o Le diagramme paramétrique est une extension SysML pour

l'analyse de paramètres critiques du système
 Dynamiques
o Le diagramme d'activités est légèrement modifié pour
SysML
o Les diagrammes de séquence, d'états, et de cas
d'utilisations restent inchangés
 Le diagramme d'exigences est une extension SysML
8
Comparatif des diagrammes UML et SysML
SysML Description UML
Identique en UML et en SysML,

il modélise les fonctionnalités
que le système doit fournir. Le
Use Case Use
cas d'utilisation est une unité
diagram Case diagram
fonctionnelle utilisée pour la
description et la recette du
système.
Identique en UML et en SysML

le diagramme de séquence
Sequence modélise la chronologie des
Sequence diagram
diagram interactions entre les éléments
du système ou entre le système
et l'extérieur.
Même utilisation en UML et en

Activity SysML. Le diagramme d'activité
Activity diagram
diagram modélise les flux d'informations
et les flux d'activité du système.
Identique en UML et en SysML,

il représente les différents états
State
que peut prendre un élément State Machine
Machine
ou une opération ainsi que ses diagram
diagram
réactions aux évènements
extérieurs.
Le diagramme de Bloc en
SysML est semblable au
diagramme de Classe en UML. Il
Block
donne une représentation
Definition Class diagram
statique des entités du système,
diagram
de leurs propriétés, de leurs
opérations et de leurs
opérations.
Internal Le diagramme internet de bloc Composite

Block SysML et le diagramme Structure diagram
9
diagram composite UML donnent une

représentation « Boîte
blanche » qui matérialise les
imbrications des parties et leurs
interconnections par les ports.
Le diagramme de Package
montre l'organisation générale
Package du modèle en UML comme en
Package diagram
diagram SysML. En SysML il sert en plus
à donner différentes vues du
système.
Nouveau dans SysML ce

diagramme modélise les
Parametric paramètres physiques du
N/A
diagram système. Il sert à tester les
performances physiques et
quantitatives du système.
Le diagramme de spécification
est nouveau dans SysML et il
Requiremen
permet de collecter et N/A
t diagram
d'organiser toutes les exigences
textuelles du système.
Nouveau en SysML. Les tables

d'allocation sont de simples
Allocation tableaux et non des
N/A
tables diagrammes qui récapitulent les
spécifications afin de faciliter le
suivi de projet.
La modélisation : pour simuler et pour communiquer

La modélisation des systèmes a deux objectifs principaux : simuler
leur comportement et communiquer des descriptions. En sciences de
l'ingénieur, elle peut s'effectuer selon trois grands points de vue
complémentaires :
1
0
1. Le point de vue fonctionnel, qui consiste à décrire les actions

effectuées par le système pour répondre à la question « A quoi
sert-il ? » ;
2. Le point de vue structurel qui, dans le cadre de la systémique,
consiste à décrire les composants du produit et de son
environnement ainsi que les relations entre ces composants,
pour répondre aux questions « De quoi est-il composé ? » et
« Comment est-il organisé ? » ;
3. Le point de vue comportemental, qui consiste à modéliser le
produit et son environnement au sein d'une théorie afin de
répondre, par la simulation, à la question « Quelles sont ses
performances ? ».
Les trois grands points de vue des sciences de l'ingénieur :

fonctionnel, structurel et comportemental.
1
1
Chapitre III- Les diagrammes fonctionnels

SysML propose deux types de diagrammes permettant d'effectuer
une modélisation fonctionnelle :
1-Diagramme des cas d'utilisation

Le premier s'appelle diagramme des cas d'utilisation et est noté uc
(pour use case diagram).
Un diagramme des cas d'utilisation d'une automobile.
Un diagramme des cas d'utilisation comporte toujours quatre types

d'éléments :
 La frontière séparant le système de son environnement,
représentée par un rectangle muni du nom du système (ici

Véhicule) ;
 Un ou plusieurs cas d'utilisation, qui sont des expressions
d'actions pouvant être réalisées en utilisant le système (ici
Diriger le véhicule) ;
 Un ou plusieurs acteurs, qui sont des entités extérieures au
système, réalisant et/ou subissant les actions décrites par les
cas d'utilisation (ici Conducteur) ; en pratique, un acteur
modélise généralement un humain ou un système automatisé ;
1
2
 Une ou plusieurs relations entre ces éléments ; en particulier,

une ligne entre un acteur et un cas d'utilisation signifie que
l'acteur participe au cas d'utilisation, c'est-à-dire qu'il réalise
et/ou subit l'action correspondante (SysML ne distingue pas les
deux cas de figure). Plusieurs acteurs peuvent participer à un
même cas d'utilisation, et réciproquement.
Ce diagramme permet également de classer les acteurs, de classer
les cas d'utilisation et d'établir des relations entre ces derniers.
Relations du diagramme uc :
o Association : une ligne entre un acteur et un cas d'utilisation

o La relation de généralisation : montre qu'une fonction est un cas
particulier d'une autre fonction.
o La relation d'extension << extend >> : une sous fonction possible
mais pas obligatoire
o La relation d'inclusion << include>> : une sous fonction
obligatoirement incluse dans une autre
2-Diagramme des exigences

Le second diagramme, nommé diagramme des exigences et noté
req (pour requirement diagram), permet de spécifier, hiérarchiser et
documenter des exigences, c'est-à-dire des attentes portant sur le
système ou sur son comportement ; il s'agit d'une notion vaste,
incluant par exemple toutes sortes de caractéristiques chiffrées, des
1
3
choix technologiques imposés, le respect de normes ou de

réglementations...
Un diagramme des exigences d'une automobile.
Ce diagramme représente le contenu d'un package nommé

Exigences et :
 Définit deux exigences, nommées Performances du véhicule et
Temps d'accélération ; seule cette dernière est explicitée ;

 Hiérarchise ces deux exigences : le trait continu terminé par un
symbole « plus cerclé » (⊕) signifie que l'exigence Temps
d'accélération est contenue dans l'exigence Performances du
véhicule ;
 Définit une allocation, c'est-à-dire une relation entre deux
éléments définis sur des diagrammes différents : la flèche
pointillée munie du mot-clé « refine » signifie que le cas
d'utilisation Conduire, raffine l'exigence Temps d'accélération,
c'est-à-dire que cette exigence caractérise ce cas d'utilisation.
Les allocations sont très utiles pour documenter les exigences ;
outre la caractérisation des cas d'utilisation, elles permettent de
mettre les exigences en relation avec les composants qui les
satisfont, avec les modèles de comportements qui permettent de
vérifier si elles sont satisfaites, ou encore d'en assurer la traçabilité.
SysML permet également de définir des types d'exigences particuliers
afin de classer celles-ci.
1
4
Exercice : UC
Il s’agit de construire le diagramme des cas d’utilisation qui permet de

modéliser les phrases suivantes :
- Conduire le véhicule
- Le propriétaire du véhicule doit faire une police
d’assurance
- Le propriétaire du véhicule doit l’enregistrer auprès des
services des mines (Agence du Transport Terrestre)
- L’agent de maintenance répare le véhicule.
1
5
Correction :
1
6
Chapitre IV- Les diagrammes structurels
En SysML, la modélisation structurelle repose essentiellement sur

deux diagrammes utilisés conjointement :
1-Diagramme de définition de blocs (BDD)

Le premier, appelé diagramme de définition de blocs et noté bdd
(pour "block definition diagram"), sert à définir, classer et
hiérarchiser les blocs, qui sont des modèles de composants ou, plus
précisément, de classes de composants.
Un diagramme de définition des blocs d'une automobile.
Ainsi, cette figure représente le contenu d'un package nommé

Structure et définit :
 Quatre blocs (remarquons que la décomposition n'est pas
exhaustive !) ;
 Deux caractéristiques du bloc Véhicule, toutes deux pourvues
d'une unité : masse et vitesse ;
 Quatre relations d'appartenance des blocs GMP, Différentiel et
Roue motrice au bloc Véhicule ; les deux flèches dirigées vers le
bloc Roue motrice signifient qu'un composant de classe
Véhicule contient deux composants de classe Roue motrice, et
chacune de ces flèches est munie d'un rôle, c'est-à-dire d'un
1
7
nom donné à la relation d'appartenance, permettant de

distinguer ces deux composants.
Ce diagramme permet également d'affiner la définition des blocs
grâce à des stéréotypes, c'est-à-dire des blocs « spécialisés » munis
de noms dédiés. Les plus courants sont les blocs logiciels
(« software »), les blocs matériels (« hardware »), les acteurs figurant
sur le diagramme des cas d'utilisation (« actor ») et le système lui-
même (« system » ou « system of interest »).
2-Diagramme interne d'un bloc (IBD)

Le second, nommé diagramme interne d'un bloc et noté ibd (pour
« internal block diagram ») modélise la structure interne d'un bloc : il
représente les composants de ce bloc ainsi que les flux de matière,
d'énergie et/ou d'information pouvant circuler entre ces composants
Les composants sont modélisés par des instances des blocs ; leur
type et leur nombre doivent être cohérents avec la définition donnée
dans le diagramme précédent.
Un diagramme interne d'un bloc d'une automobile.
Cette figure représente la vue interne du bloc Voiture :

 Modélise les composants par des instances de blocs, nommées
par un symbole « deux points » (:) suivi du nom du bloc dont

elles sont issues, et précédé du rôle dans le cas où celui-ci est
défini (ici, les deux instances du bloc Roue motrice possèdent
les rôles respectifs avant gauche et avant droite) ;
1
8
 Définit des ports, c'est-à-dire des interfaces permettant aux

composants d'échanger des flux avec leurs environnements,
représentés par des carrés chevauchant le bord du rectangle ;
ici, les ports sont nommés d'après le type de flux qui les
traverse et possèdent une direction (entrante ou sortante) ;
 Représente les flux possibles par des connecteurs joignant les
ports.
Ce mécanisme permet de modéliser la structure de systèmes
sophistiqués avec une grande rigueur, toujours selon le même
schéma : définir des blocs dans un bdd, puis les instancier dans un
ibd. Leurs deux utilisations les plus courantes sont l'utilisation « boîte
blanche », consistant à modéliser la structure du produit comme sur
les figures ci-dessus, et l'utilisation « boîte noire », consistant à définir
des éléments du milieu extérieur dans un bdd (pouvant inclure, par
exemple, les acteurs) puis à représenter les flux que ceux-ci peuvent
échanger avec le produit dans un ibd. Dans les deux cas, il est
important de garder à l'esprit qu'un ibd ne représente que des flux
possibles, permis par la structure du système, et non les flux
effectivement échangés à un certain instant de la vie du système : ce
n'est pas un diagramme fonctionnel ou comportemental !
La modélisation structurelle joue généralement un rôle central en
SysML. Elle peut notamment être liée :
 A la modélisation comportementale, en allouant des modèles
de comportements aux blocs (ou à leurs instances) ou en

spécifiant des relations mathématiques entre leurs
caractéristiques, notamment dans le but de réaliser des
simulations ;
 A la modélisation fonctionnelle, en faisant participer les
acteurs (qui sont des blocs spécialisés !) aux cas d'utilisation, et
en allouant les blocs (ou leurs instances) aux exigences qu'ils
satisfont.
1
9
3- diagramme des paquets
SysML offre enfin un troisième type de diagramme structurel, qui

n'apporte aucune information sur le produit ou son environnement
proprement dits, mais sert à classer les différentes données
contenues dans un modèle : le diagramme des paquets, noté pkg
(pour « package diagram »).
Ce diagramme permet de définir des paquets ou packages, qui sont

des éléments pouvant contenir d'autres éléments du modèle (cas
d'utilisation, exigences, blocs, autres paquets ...) selon un principe
tout à fait analogue à celui des dossiers informatiques ; comme nous
venons de le voir, de nombreux diagrammes SysML de haut niveau
représentent le contenu d'un paquet, et le paquet "principal"
contenant toutes les données (analogue au répertoire racine d'un
disque dur) s'appelle tout simplement ... le modèle. L'organisation
des données en paquets prend toute son utilité pratique lorsque l'on
utilise un logiciel de modélisation.
2
0
EXERCICES RECAITULATIFS
Exercice 1 : les relations entre les blocs
Donner le nom de chacune des principales relations entre les blocs

et l’expliquer.
2
1
Correction 1 :
Association : relation d’égal à égal entre deux éléments

A utilise B.
Est utilisé dans 2 diagrammes : cas d’utilisation, défnition de blocs
Dépendance : 2 items distincts mais dont l’un dépend de l’autre

A dépend de B
Est utilisé dans 3 diagrammes : exigences, cas d’utilisation,
définition de blocs.
Agrégation : un élément est une composante facultative de l’autre

A entre dans la composition de B sans être indispensable à son
fonctionnement
Est utilisé dans 2 diagrammes : exigences, défnition de blocs
Composition : un élément est une composante obligatoire de

l’autre
A entre dans la composition de B et lui est indispensable
Est utilisé dans 2 diagrammes : exigences, définition de blocs.
2
2
Généralisation : dépendance de type « filiation » entre 2 items

A est une sorte de B
Est utilisé dans 2 diagrammes : cas d’utilisation, définition de
blocs.
Conteneur : relation d’inclusion entre 2 items

B contient A
Est utilisé dans 3 diagrammes : exigences, cas d’utilisation,
définition de blocs.
Exercice 2 récapitulatif : BDD

Compléter les multiplicités manquantes et expliquer les notions et
concepts indiqués par des flèches.
2
3
2
4
Correction 2:
2
5
Exercice 3 récapitulatif : IBD

Expliquer les notions et concepts indiqués par des flèches.
2
6
Correction 3 :
Exercice 4 : BDD
Modéliser le système ABS qui contient un bloc de contrôle
« Système anti blocage des roues » lui même composé d'un
2
7
bloc de détection d'adhérence et d'un bloc de régulation de

freinage.
Correction 4
Commentaire :
On retrouve bien dans cette représentation les principes d'UML
mais adapté à un système qui combine de la mécanique, de la
physique, de l'électronique et de la programmation.
2
8
Chapitre V- Les diagrammes comportementaux
SysML offre quatre types de diagrammes comportementaux,

appartenant à deux catégories bien distinctes. L'un de ces
diagrammes permet de représenter graphiquement des systèmes
d'équations reliant les caractéristiques du modèle. Les trois autres
permettent de modéliser un comportement par une suite d'étapes
(actions, états...) munie de règles d'évolution, et prennent
généralement la forme de graphes orientés. Outre leur rôle
descriptif, certains de ces diagrammes peuvent être utilisés pour
réaliser des simulations.
Le diagramme paramétrique
La modélisation paramétrique consiste à construire des systèmes de
relations (équations, éventuellement différentielles, ou inéquations)
entre les grandeurs (physiques ou logiques) qui caractérisent les
modèles des composants et des flux, afin de réaliser des simulations.
En pratique, ces relations proviennent généralement de l'expression
des lois d'une théorie ou de modèles de comportements de
composants ; SysML n'étant pas un outil de modélisation physique,
c'est au modélisateur qu'il revient de choisir et d'écrire ces relations,
bien que certains logiciels proposent des bibliothèques susceptibles
de faciliter cette tâche. Ici, nous nous intéressons par exemple au
système d'équations suivant :
t
v(t )   a( )d (1)
0
F (t )  ma(t ) (2)
F (t )  Fg (t )  Fd (t ) (3)
Pour représenter ce système d'équations en SysML, on procède en
deux temps. Premièrement, on représente les différentes relations,
ainsi que les grandeurs qui y interviennent, dans des blocs de
2
9
contraintes (constraint blocks). Cette représentation s'effectue dans

un diagramme de définition de blocs que l'on construit selon le
même principe que s'il s'agissait de blocs « standard » .
Un diagramme de définition des blocs de contrainte d'une automobile,

en vue d'une modélisation paramétrique.
Par exemple, le diagramme ci-dessus définit :

 Quatre blocs de contraintes, dont trois sont caractérisés par
des variables (parameters) et des relations entre ces variables

(constraints), qui correspondent aux trois équations ci-dessus
prises indépendamment les unes des autres, et sont écrites
dans le langage du logiciel qui réalisera la simulation ;
 Une relation d'appartenance de chacun des trois blocs
caractérisés au bloc Dynamique du véhicule ;
 Une relation de référence représentée par la flèche munie d'un
losange évidé, qui signifie que le bloc de contrainte Dynamique
3
0
du véhicule peut faire appel aux caractéristiques du bloc

Véhicule. Cette relation est munie d'un nom de rôle, à savoir v.
Dans un deuxième temps, on construit un diagramme
paramétrique, noté par, qui représente graphiquement le système
formé par ces contraintes et leurs paramètres (figure suivante). Pour
cela, on instancie les blocs de contrainte, de la même façon que l'on
instancie des blocs dans un ibd.
Un diagramme paramétrique d'une automobile.
Le diagramme ci-dessus représente l'intérieur du bloc de contrainte

Dynamique du véhicule. Il est construit de façon tout à fait similaire à
un ibd :
 Il définit trois contraintes, qui sont des instances des blocs de
contraintes , et les représente par des rectangles à coins

arrondis nommés selon la convention habituelle ; les
paramètres intervenant dans l'expression de ces contraintes
sont également représentés et nommés conformément à la
définition des blocs de contraintes ;
 Il définit quatre références à des caractéristiques de blocs ; ces
références sont représentées par des rectangles portant le nom
3
1
de la caractéristique précédé des rôles (noms des relations de

référence ou d'appartenance) permettant de remonter jusqu'au
bloc concerné (ici, la caractéristique F n'a pas été définie.) ;
 Enfin, il relie les paramètres égaux (entre deux contraintes ou
entre une contrainte et une référence) afin de représenter la
structure du système d'équations.
Un diagramme paramétrique représente un système de relatons
mathématiques, et non un algorithme de résolution (qui n'existe
d'ailleurs pas toujours !). Un tel modèle est dit acausal ; s'il est
mathématiquement bien formulé (ce qui relève de la responsabilité
du modélisateur), alors on pourra réaliser une simulation d'après ce
modèle.
Les diagrammes basés sur des suites d'étapes

L'autre grande catégorie de modélisation comportementale offerte
par SysML fait appel à une suite d'étapes et de règles d'évolution,
représentées par des graphes orientés : elle est donc causale. SysML
propose trois modèles de comportements de ce type, correspondant
chacun à un point de vue différent, et représentés par un diagramme
différent.
Le premier diagramme, nommé diagramme d'activités et noté act
(pour activity diagram), permet de modéliser un comportement sous
la forme d'une suite d'actions transformant des flux de matière,
d'énergie et/ou d'information (figure ci-dessous). Un tel modèle
s'appelle une activité et contient, la plupart du temps, une
description comportementale mais aussi fonctionnelle.
3
2
Un diagramme d'activité d'une automobile.
Ce diagramme représente une activité nommée Faire avancer le

véhicule et définit
 Quatre actions, représentées par des rectangles dont les coins
sont arrondis ;
 La matière d'œuvre entrante et sortante de chacune de ces
actions, représentée par des carrés situés sur le bord extérieur
des actions ;
 La matière d'œuvre entrante et sortante de l'activité entière,
représentée par des rectangles chevauchant le cadre du
diagramme ;
 Les flux de la matière d'œuvre au cours de l'activité,
représentés par des flèches reliant les carrés ou rectangles ; ces
flèches sont munies du mot-clé « continuous » indiquant qu'il
s'agit de flux continus, à l'exception de celle qui représente le
choix du rapport (par défaut, les flux sont supposés discrets) ;
 Des allocations des actions aux modèles de composants (i.e.
aux instances des blocs), en partitionnant l'activité en colonnes
3
3
appelées swimlanes (« lignes d'eau ») portant chacune le nom

d'une instance d'un bloc.
Les diagrammes d'activités possèdent une sémantique très riche,
adaptée à des descriptions à la fois fonctionnelles et
comportementales. Ils offrent de nombreuses possibilités dont la
figure ci-dessus ne donne qu'un infime aperçu : ils permettent de
représenter des flux continus ou discrets, d'imposer des conditions
sur le déclenchement des actions (qui peuvent être activées et
désactivées au cours du temps), de spécifier des exécutions parallèles
ou des branchements conditionnels, d'inclure une activité dans une
autre, de coupler plusieurs activités entre elles... Les actions sont
souvent allouées aux instances des blocs. Ce diagramme est
généralement utilisé à des fins purement descriptives, mais peut
parfois servir à réaliser des simulations si les comportements sont
modélisés de façon suffisamment détaillée.
Le second diagramme, nommé diagramme d'états et noté stm
(pour state machine diagram), permet de modéliser un
comportement par un automate fini (parfois appelé machine à états),
c'est-à-dire une suite d'états reliés par des transitions pilotées par
des événements, supposés instantanés et de durée négligeable.
La règle de base est que le système change d'état lorsque ces

événements surviennent (figure suivante).
3
4
Un diagramme d'états d'une automobile.
Ce diagramme représente un automate fini nommé Marche/arrêt et

définit :
 Deux états nommés moteur arrêté et moteur allumé ; ce
dernier possède un comportement d'entrée repéré par le mot-

clé entry, qui est appelé au moment où cet état devient actif et
n'est pas défini sur ce diagramme ;
 Un pseudo-état indiquant l'état initial, représenté par un disque
noir ;
 Deux transitions entre les états ; toutes deux possèdent un
événement déclencheur (respectivement mise du contact et
coupure du contact) et l'une d'entre elles possède de plus une
condition de garde indiquée entre crochets (antidémarrage
déverrouillé). Un changement d'état s'effectue lorsque
l'événement déclencheur de la transition se produit, sous
réserve que la condition de garde (s'il y en a une) soit vraie à
l'instant où il se produit.
Les automates finis permettent de modéliser des comportements
selon un point de vue complémentaire à celui des activités :
l'enchaînement des états est piloté par les événements mentionnés
dans les transitions, tandis que l'enchaînement des actions est
uniquement piloté par leur durée d'exécution. Les deux modèles
présentent cependant des possibilités syntaxiques comparables
3
5
(exécutions parallèles ou branchements conditionnels, inclusion,

couplages...) et peuvent tous deux être alloués à des blocs ou à leurs
instances (mais l'allocation des automates n'est pas représentée par
des swimlanes, contrairement à celle des activités). Les automates
sont régis par des règles précises et leur niveau de détail est
généralement assez élevé pour permettre la réalisation de
simulations.
Enfin, le diagramme de séquence, noté sd (pour sequence diagram),
permet de modéliser des interactions entre des instances de blocs
(c'est-à-dire des modèles de composants du produit et de son
environnement), selon un ordre chronologique et sans détailler leurs
comportements individuels. Ces interactions sont modélisées par des
messages, définis en SysML comme une action qui déclenche un
comportement prédéfini chez son destinataire.
Diagramme de séquence d’une automobile
Ce diagramme :
 Représente deux instances de blocs dont l'un est un acteur ;
3
6
 Attribue à chaque instance une ligne de vie, c'est-à-dire une

ligne pointillée symbolisant l'écoulement du temps (vers le bas)
;
 Représente deux messages, mettre le contact() et contact mis ;
 Représente les comportements individuels des deux instances
par des rectangles blancs, sans les détailler ; c'est dans le cadre
de ces comportements que les messages sont échangés.
Les diagrammes de séquences sont souvent associés à des
diagrammes d'activités ou d'états couplés entre eux, en raison de la
complémentarité des points de vue : en effet, une activité ou un
automate fini représentent généralement le comportement
individuel d'un composant sans détailler ses interactions avec
l'extérieur, tandis qu'un diagramme de séquence représente
uniquement les interactions. Les interactions sont explicitement liées
à la modélisation structurelle, puisque des instances de blocs y
figurent ; de plus, comme tout modèle de comportement, elles
peuvent être allouées à la modélisation fonctionnelle, et il est
notamment fréquent d'allouer une interaction à un cas d'utilisation
afin de développer celui-ci.
Exercices récapitulatifs
Exercice 1 récapitulatif
3
7
Correction 1
Correction 1 :
3
8
Chapitre VI – Récapitulatif et TD
Dans cette ressource, nous avons mis en évidence les points
suivants :
1. SysML permet de modéliser un produit et son environnement
par un système, c'est-à-dire un ensemble de composants qui
interagissent entre eux.
2. Cette modélisation est multipoints de vue et inclut notamment
des aspects fonctionnels, structurels et comportementaux.
3. Un modèle SysML est représenté par un ensemble de boîtes et
de lignes, munies de types, de noms permettant de les
identifier, et d'une hiérarchie (une boîte contient d'autres
boîtes et des lignes).
4. Les boîtes et les lignes sont assemblées au sein de diagrammes
interdépendants : un même élément, repéré par son nom, peut
figurer sur des diagrammes différents, qui apportent alors des
informations complémentaires.
5. Il existe neuf types de diagrammes. Ces types, ainsi que les
relations possibles entre les éléments représentés par ces
diagrammes, sont récapitulés sur la figure ci-dessous (le
diagramme des paquets a été omis dans un souci de simplicité).
6. Un diagramme doit toujours représenter l'intérieur d'une boîte.
Cependant, cette représentation peut être partielle (on ne
représente que ce dont on a besoin).
3
9
Figure 14 : Récapitulatif des neuf types de diagrammes SysML (sans le diagramme des paquets) ainsi que des
relations possibles entre les contenus de ces diagrammes
4
0
TD 1: Modélisation d’une balance électronique

QCM :
1-Le diagramme des exigences (requirement diagram) utilise
les liens signifiant les termes : contenance, vérification,
précision, satisfaction, dérivation. Compléter les liens suivant
par l’un des termes précédents.
2- Le diagramme des exigences est utilisé pour :
a- collecter toutes les exigences techniques,
b- collecter toutes les exigences légales, physiques, commerciales

normatives ou autres d'un projet.
c- être transversal à l'intégralité du système
d) permettre la hiérarchisation des spécifications.
Cocher les réponses correctes.
3- Le diagramme des exigences comporte les trois types de blocs

suivants : lesquels ?
4
1
a- Bloc Exigence fonctionnelle (functional Requirement)

b- Diagramme de bloc de définition (BDD)
c- Diagramme de bloc interne
d- Bloc SubSystem
e-Bloc commentaire.
4- compléter le diagramme d’exigences ci-dessous en tenant

compte des données suivantes :
il s’agit du diagramme des exigences représentant « les exigences de

pesée ».
1-l’exigence « pesée des aliments » identifiée par 1 est associée au
texte « la balance doit être un produit grand public ». Elle est
associée aux sous-exigences ci-après par des liens de contenance :
1.1- bloc d’exigence fonctionnelle « mesurer la masse » qui
nécessite une exigence de précision intitulée « précision de la
mesure » identifiée par 3 et mesurant la sensibilité du capteur à 1 g.
1.2- bloc subsystem intitulé « supporter un récipient » permettant
l’utilisation des récipients différents. Ce bloc se sert d’un lien de
satisfaction pour bien maintenir l’équilibre du plateau.
1.3- bloc d’exigence fonctionnelle « permettre des mesures
cumulées » pour ajouter et peser des ingrédients supplémentaires
sans avoir à vider le contenu du bol. Ce bloc utilise un lien de
satisfaction pour le tarage.
L’exigence « pesée des aliments » est également associée, par un lien

de dérivation, à un bloc subsystem d’utilisation « faciliter le transport
et le rangement » et ce pour un confort d’utilisation. Cette exigence
identifiée par 4 a induit des contraintes supplémentaires concernant
l’autonomie « fonctionner en autonomie » et l’encombrement
« limiter l’encombrement » en se servant de liens de contenance
identifiées respectivement 4.1 et 4.2. En plus le lien de dérivation est
associé à un bloc commentaire expliquant les 2 contraintes
supplémentaires.
4
2
4
3
Correction TD1
1-Le diagramme des exigences (requirement diagram) utilise
les liens suivants :
Ce diagramme est utilisé pour collecter toutes les exigences

techniques, légales, physiques, commerciales normatives ou autres
d'un projet. Ce diagramme est transversal à l'intégralité du système et
permet en plus de hiérarchiser les spécifications.
Il comporte trois types de blocs :
Bloc Exigence fonctionnelle (functional Requirement)
Le bloc comporte une entête avec l'indication <<requirement>>, son

titre et un corps avec numéro d'identification (Id) et un définition
précise.
Chaque exigence peut se décomposer en sous-exigences, les liens

hiérarchiques entre exigence et sous-exigences sont matérialisés par
une liaison avec un cercle du côté de l'exigence de plus haut niveau.
La numérotation (Id) reprend aussi dans sa forme la hiérarchie des
blocs (1 a pour sous-exigences 1.1 et 1.2..).
On peut également trouver des relation notée "refine" qui relient à une
exigence une autre qui vient la préciser souvent de façon quantitative.
4
4
Bloc SubSystem
Représenté par un rectangle simple avec comme identifiant

"subsystem". Ce bloc représente une partie technique du système
étudié qu'on relie par une relation notée "satisfy" (flèche en pointillé) à
une ou plusieurs exigences fonctionnelles.
Bloc commentaire
On trouve également des blocs cornés sans entêtes qui permettent

d’insérer des commentaires au diagramme.
Etude du cas : la balance électronique
4
5
4
6
Suite TD1
2-Le diagramme des cas d'utilisation (uc)
a) Les cas d’utilisation du système(ovales) reliés par des associations
qui signifient « participe à ». Donner le type des associations
suivantes :
b) Compléter le Diagramme de cas d’utilisation : balance électronique

sachant que :
-l’utilisateur peut peser des aliments.
-Le système peut convertir la pesée en volume.
-La pesée des aliments nécessite de tarer automatiquement pour

s’assurer du poids à vide. De même, il est possible de tarer à la
demande « manuellement » pour tenir compte du poids de
l’emballage.
4
7
4
8
CORRECTION
2-Le diagramme des cas d'utilisation (uc)
Le diagramme de cas d’utilisation est un schéma qui montre les cas
d’utilisation du système(ovales) reliés par des associations (lignes) à
leurs acteurs (icône bonhomme).
Chaque association signifie simplement « participe à ».
Éléments du diagramme
Liens de l'uc
 un ou plusieurs acteur (personnes ou autre système);

 les différents cas d'utilisation dans des ovales
 des liens
o lien de généralisation : montre qu'une fonction est un cas
particulier d'une autre fonction
o Le lien d'extension << extend >> : une sous fonction
possible mais pas obligatoire
o Le lien d'inclusion << include>> : une sous fonction
obligatoirement incluse dans une autre
4
9
Diagramme de cas d’utilisation : balance électronique
5
0
Le diagramme de définition de blocs (BDD)

Le diagramme de définition de blocs est un diagramme structurel
qui décrit physiquement le système et/ou ses sous-systèmes ; Il s'agit
de recenser les constituants d'un bloc.
Remarque : On fait souvent un BDD représentant le contexte d'un

système où l'on voit apparaître les acteurs ou les autres systèmes
pouvant interagir.
Le diagramme est composé généralement de :
 un bloc "central" représentant l'élément à décomposer;

 plusieurs autres blocs représentants les constituants.
Ils sont reliés par des liens dotés d'un losange et d'une flèche qui
pointe vers le constituant :
Remarque : sur les liens on peut indiquer la multiplicité : c'est à dire le

nombre d'instances de bloc mis en jeu dans la relation.
Question : Modéliser le BDD de la balance électronique :
1- le bloc central : système de la balance

2- les constituants du bloc central :
a) bloc « pile » dont la valeur de la tension = 3 v
b) bloc châssis
c) bloc poutre
d) bloc plateau
e) bloc jauges de déformations dont la valeur de la précision=1g
f) sous-système « Module électronique » composé des blocs
suivants :
f1- logiciel
f2- amplificateur : dont la valeur de l’amplification=910
f3- filtre dont la propriété « fréquence de coupure »=3.3 Hz
f4- microcontrôleur permettant d’afficher les messages
5
1
g) 3 blocs constituants l’IHM décrits comme suit :

g1- afficheur
g2- bouton ON/OFF/T
g3- bouton g/ml
5
2
Correction BDD : Cas de la balance électronique
5
3
Le diagramme de bloc interne (IBD)

Comme le précédent, le diagramme de bloc interne permet de montrer
les différents constituants du système mais il permet de définir les
différents flux entre les composants du système présenté.
Éléments graphiques
 Les blocs : Les différentes parties du système étudié sont

représentées sous forme de blocs muni ou non de ports.
 Les ports : représentés par des petits carrés à la frontière des
blocs, ils peuvent contenir ou non des flèches indiquant le sens
de la relation.
 Les connecteurs : ce sont des traits continus reliant des ports.
Ils peuvent porter un commentaire indiquant la nature du flux.
5
4
Travail demandé : On vous propose le tableau suivant :

Instance bloc Bloc/port entrée Flux reçu Flux émis Bloc/port sortie Remarques
:plateau Port « aliment » Force force :poutre
:poutre :plateau Force Déformation :jauge de déformation
:plateau Force Sans rôle :châssis
:châssis :poutre Sans rôle - -
:jauge de :poutre Déformation Signal entrée :amplificateur
déformation :pile Energie élect Signal entrée :amplificateur
:amplificateur :jauge de déformation Signal brut

:pile Energie élect Signal :filtre
amplifié
:pile - - Energie - :jauges, - :amplificat, -
électrique :filtre, - :microCon
alimentation :afficheur
:filtre :amplificateur Signal amplifié Signal filtré :microCont

:pile Energie électr-
microContrôleur :filtre Signal filtré Messages à
:pile Energie électriq afficher :afficheur Flux bidirec-
:bouton ON/OFF Sans rôle Sans rôle :bouton ON/OFF
:bouton g/ml Sans rôle Sans rôle :bouton g/ml
:afficheur :pile Alimentation Flux Port « œil utilisateur »

:microCont Messages à afficher lumineux
:bouton ON/OFF :microCont Sans rôle Sans rôle :microCon Flux bidrec-
Port « doigt utilisateur » Pression Sans rôle :microCon
:bouton g/ml :microCont Sans rôle Sans rôle :microCon Flux bidrec-
Port « doigt utilisateur » Pression Sans rôle :microCon
5
5
Compléter le diagramme IBD ci-dessous:
5
6
Correction IBD : Cas de la balance électronique
5
7
Le diagramme paramétrique
Le diagramme paramétrique reprend la structure du diagramme précédent mais spécifie les grandeurs
physiques véhiculées dans les liens. On ajoute aussi les relations mathématiques entre les grandeurs au sein
d'un bloc. Ce diagramme permet d'aller vers la simulation numérique du comportement du système.
Exemple de la balance
Dans le diagramme BDD précédent, on précisera par exemple,
 dans le bloc correspondant à la poutre, une relation de la forme : F = K.x qui met en relation la force
reçue et la déformation x engendrée; K étant la raideur.
 dans le bloc correspondant à la jauge de déformation, une relation de de type U = A.x, où U est la
tension renvoyée par la jauge et X la déformation.
5
8
TD 2 : Le véhicule HSUV
Nous allons utiliser comme exemple le cas traité dans la

spécification officielle de SysML.
Il s'agit de modéliser un véhicule hybride sportif et utilitaire à la
fois : Hybrid Sport Utility Vehicule.
L'intérêt de cet exemple réside dans les contradictions
qu'impose un véhicule à la fois sportif et utilitaire.
Identification des blocs candidats

Dans notre exemple issu de l'industrie automobile il est
clair que les contraintes juridiques et de production ne nous
permettent pas forcément de tout ré-inventer.
Nous décrivons donc ci-dessous chaque bloc du système en lui
donnant un nom P, C, I, CH, etc...
5
9
6
0
Répartition des blocs et sous blocs

Ensuite pour affiner encore le modèle, chaque bloc peut être
défini par des sous blocs de la même manière que le sous-
système « Puissance » représenté ci-après.
6
1
6
2
6
3
6
4
6
5
Définition des connexions entre blocs

Une fois les différents blocs identifiés et associés entre eux,
nous passons à la définition des connexions entre « blokcs »
et/ou « parts ».
En effet, il est possible de représenter des classes et des objets
en UML et nous représentons des « blocks » et des « parts » en
SysML.
En SysML, nous utiliserons le « Internal block diagram » qui est
le descendant du « composite diagram » en ULM afin de
représenter les relations entre « blokcs » et/ou « parts ».
Nous représenterons les différentes interfaces, les ports et nous
décrirons les flux qui circulent entre les « blocks » et les
« parts ».
Nous pourrons représenter aussi bien des informations comme
des structures de données que des éléments matériels comme
de la matière ou de l'énergie.
L'une des premières façons de modéliser les associations entre
« parts » consiste comme ci-dessous à les relier et à nommer
leurs associations.
Pour aller encore plus loin nous allons représenter comme ci-
dessous chaque « Part » avec les ports, les interfaces et les
items échangés entre les « Parts ».
Nous avons ainsi une représentation à la fois logique et
physique du système qui va nous permettre de spécifier et de
valider le système.
Les items représentant des valeurs comme le couple ou le
courant électrique ci-dessous seront ensuite réutilisés à travers
le diagramme paramétrique qui va permettre la mise en
équation et la vérification du système.
6
6
6
7
6
8
Vérification du système par les diagrammes paramétriques.

Nous avons à priori défini un système qui répond à l'ensemble
des spécifications et qui présente maintenant tous les blocs et
sous blocs, toutes les parties et toutes les associations qui
permettent de simuler son fonctionnement.
Nous allons donc maintenant procéder à la vérification des
performances du système et nous allons en même temps
valider le modèle lui même.
Afin de modéliser mathématiquement le fonctionnement de
notre véhicule HSUV nous allons donc définir des équations
appelées « Constraints » qui utiliserons les valeurs décrites par
nos « Internal Block Diagrams » dans les unités définies par le
package des unités de mesure de l'automobile décrites en tout
début de cette partie SysML.
Ces équations qu'on appelle « Constraints » constituent la
représentation statique du modèle paramétrique et pour
effectuer une vérification du système nous allons les mettre en
œuvre dans un diagramme paramétrique qui utilisera les
instances de ces équations.
Ci-dessous la représentation statique des équations dans un
diagramme de bloc qui montre les dépendances entres les
« Constraints ».
Chaque « constraint » définissant le comportement du véhicule
en ligne droite est nommée pawr, pos, vel, acc.
Ces instances seront ensuite mises en œuvre dans le
diagramme paramétrique.
6
9
7
0
Une fois les équations définies, celles-ci peuvent être

utilisées comme ci-dessous pour procéder à des
simulations du système.
7
1
7
2
7
3
Enfin pour préparer le cadre général de l'étude, chaque

entreprise, chaque projet peut nécessiter une
organisation spécifique.
Dans l'exemple donné par le tutoriel officiel de SysML
nous avons l'organisation ci-dessous qui regroupe en
package les différentes parties de l'étude afin de
faciliter la recherche et la création de diagrammes dans
un projet qui en contiendra beaucoup à la fin.
Cette démarche peut sembler un peu complexe mais en
réalité cela revient au même que de préparer
l'arborescence de dossiers communs à un groupe de
travail avant de commencer un projet.
C'est donc une étape très importante dont les
modifications éventuelles doivent être portées à la
connaissance de tous.
7
4
7
5
7
6
Identification des acteurs et des cas d'utilisation

Tout comme dans l'étude UML nous allons identifier qui
va interagir avec le système et quelles fonctionnalités le
système va fournir aux acteurs ou requérir des acteurs.
Nous allons ainsi définir toutes les interactions entre le
système et son environnement.
Comme nous pouvons le constater ci-dessous aucun
changement entre UML et SysML
7
7
7
8
7
9
8
0
De même nous pouvons définir le fonctionnement

général du système avec des diagrammes d'activité et
des diagrammes d'état comme ci-dessous :
8
1
8
2
Collecte et structuration des spécifications (

Requirement Diagram )
Nous n'avons pas attendu SysML pour collecter et
structurer les exigences et documentations relatives à
un projet.
Cependant, SysML nous permet grâce au diagramme de
spécification « Requirement Diagram » et grâce aux
tableaux récapitulatifs de structurer parfaitement
toutes les exigences requises.
Nous pourrons ainsi les organiser entre eux et les
associer ensuite aux différents packages, blocs et
autres afin de lier les responsables de chaque élément
aux spécifications qui le concerne.
C'est aussi une façon de donner une vue transversale
des spécifications à tous les responsables collaborant à
la réalisation du système.
Certains environnements de modélisation UML
permettent même de lier les spécifications à des
documents Word, Excel ou autre afin de gérer le
stockage et les versions de ceux-ci.
Ci-dessous la vue de l'organisation des spécifications
grâce au « Requirement diagram » représentant
l'organisation des packages de spécifications.
8
3
8
4
Complément de conception
Atelier « G A B »
Cette étude de cas concerne un système simplifié de Guichet Automatique de Banque (GAB). Le GAB offre
les services suivants :
1. distribution d’argent à tout porteur de carte de crédit, via un lecteur de carte et un distributeur de billets.
2. consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients porteurs d’une
carte de crédit de la banque adossée au GAB.
3. Toutes les transactions sont sécurisées.
4. il est parfois nécessaire de recharger le distributeur, etc…
A partir de ces quatre phases, nous allons progressivement :

 identifier les acteurs ;
 identifier les cas d’utilisation ;
 construire un diagramme de cas d’utilisation ;
 décrire textuellement les cas d’utilisation ;
 compléter les descriptions par des diagrammes dynamiques ;
 organiser et structurer les cas d’utilisation.
8
5
8
6
système: GAB
retirer de l'argent <<include>> syst-autorisation
porteur de carte
retirer argent avec carte banque
sys-banque
<<include>>
s'authentifier
consulter solde
<<include>>
déposer de l'argent
déposer du numéraire
déposer chèques <<extend>>
<<extend>>
recharger distributeur
récupérer cartes avalées
récupérer chèques déposés
8
7

Cours Poo - Uml-Sysml

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours Poo - Uml-Sysml

Transféré par

Droits d'auteur :

Formats disponibles

Cours POO « UML-SYSML »

Module POO (UML/SysML)

Enseignant : BOUBAKRI Mohamed Naceur

1-Historique de la notation SysML

Juin 2010 : SysML v1.2 (version actuelle)

3-Les avantages d'une modélisation SysML sont :

SysML est fait pour :

 Vérifier et valider la faisabilité d'un système avant sa

 Définir les acteurs humains ou non qui vont interagir avec le

7-Définition du métier et du contexte

SysML est beaucoup plus performant que UML pour décrire le

8- L'Ingénierie Système (IS)

L'Ingénierie Système (IS), ou Systems Engineering en anglais (SE),

L'Ingénierie Système s'adresse aux secteurs suivants de l'activité

Chapitre II- Notions de base UML, SysML et comparatif des

UML, langage de modélisation très répandu pour les développements

Présentation de la notation SysML

SysML (Systems ModelingLanguage) est basé sur UML et remplace

Comme représenté sur la figure suivante, SysML réutilise une partie

 Définitions pour les diagrammes de définitions de blocs et de

SysML : 9 diagrammes - 4 structurels, 4 dynamiques, et les

o Le diagramme paramétrique est une extension SysML pour

Comparatif des diagrammes UML et SysML

SysML Description UML

Identique en UML et en SysML,

Identique en UML et en SysML

Même utilisation en UML et en

Identique en UML et en SysML,

Internal Le diagramme internet de bloc Composite

diagram composite UML donnent une

Nouveau dans SysML ce

Nouveau en SysML. Les tables

La modélisation : pour simuler et pour communiquer

1. Le point de vue fonctionnel, qui consiste à décrire les actions

Les trois grands points de vue des sciences de l'ingénieur :

Chapitre III- Les diagrammes fonctionnels

1-Diagramme des cas d'utilisation

Un diagramme des cas d'utilisation d'une automobile.

Un diagramme des cas d'utilisation comporte toujours quatre types

représentée par un rectangle muni du nom du système (ici

 Une ou plusieurs relations entre ces éléments ; en particulier,

o Association : une ligne entre un acteur et un cas d'utilisation

2-Diagramme des exigences

choix technologiques imposés, le respect de normes ou de

Un diagramme des exigences d'une automobile.

Ce diagramme représente le contenu d'un package nommé

Temps d'accélération ; seule cette dernière est explicitée ;

Il s’agit de construire le diagramme des cas d’utilisation qui permet de

Chapitre IV- Les diagrammes structurels

En SysML, la modélisation structurelle repose essentiellement sur

1-Diagramme de définition de blocs (BDD)

Un diagramme de définition des blocs d'une automobile.

Ainsi, cette figure représente le contenu d'un package nommé

nom donné à la relation d'appartenance, permettant de

2-Diagramme interne d'un bloc (IBD)

Un diagramme interne d'un bloc d'une automobile.

Cette figure représente la vue interne du bloc Voiture :

par un symbole « deux points » (:) suivi du nom du bloc dont

 Définit des ports, c'est-à-dire des interfaces permettant aux

de comportements aux blocs (ou à leurs instances) ou en

3- diagramme des paquets

SysML offre enfin un troisième type de diagramme structurel, qui

Ce diagramme permet de définir des paquets ou packages, qui sont