Modlisation des systmes

complexes avec SysML

Abdelouahed Sabri
abdelouahed.sabri@gmail.com

Introduction

SysML: Systems Modeling Language

Langage de modlisation spcifique au domaine de lIngnierie

Systme (IS)
Cest une adaptation du langage de modlisation UML (Unified
Modeling Language)
Il permet la spcification, l'analyse, la conception,
la vrification et la validation des systmes

Introduction: Ingnierie Systme

LIngnierie Systme (IS): (src wikipedia)

Est une approche permettant de formaliser et dapprhender la

conception de systmes

Systme: est un ensemble d'lments humains ou matriels

Les mthodes de lIngnierie Systme (IS) reposent sur

des approches de modlisation et de simulation pour
valider les exigences ou pour valuer le systme
L'ingnierie des systmes se concentre sur la dfinition
des besoins du client et des exigences fonctionnelles et
matrielles

Introduction: Modlisation

Modliser consiste en une simplification pour faciliter la

comprhension des systmes dvelopper
Un modle est:

Une reprsentation abstraite et simplifie d'une entit

(phnomne, processus, systme, etc.) du monde rel en vue
de le dcrire, de l'expliquer ou de le prvoir.
Un langage commun, prcis, qui est connu par tous les
membres de l'quipe et il est donc, ce titre, un vecteur
privilgi pour communiquer.

Introduction: Modlisation

Pourquoi Modliser???
Ltape de modlisation dun systme est gnralement ralise
avant sa ralisation pour mieux comprendre le fonctionnement
du systme. C'est aussi un bon moyen pour matriser sa
complexit et ainsi assurer sa cohrence.

Un modle permet de:

Produire un guide pour le dveloppement du systme

mieux rpartir les tches

d'automatiser certaines d'entre elles. C'est galement un facteur de
rduction des cots et des dlais.

Avoir un support documentaire du systme

Dfinir les structures de donnes ainsi que le comportement du
systme
Prdire et savoir comment va tre notre systme et ainsi le valider
vis--vis des clients
5

Introduction: Modlisation

Sur le modle:

doit ressembl au systme rel quon vise dvelopper

peut tre reprsent avec plusieurs niveaux de prcision
ne doit pas tre trs simple ni trop complexe
doit permettre sa modification et sa rutilisation
doit permettre un passage facile entre le niveau conceptuel et
limplmentation

Introduction: Modlisation

Les diffrentes
standardisation)

de

modlisation

(avant

Mthodes de premire gnration: sont des mthodes fonctionnelles de

dcomposition
hirarchique
ou
descendante.
Exemple: SADT (Structured Analysis and Design Technique).

mthodes

Avantages: Clarification et une dcomposition analytique de la complexit dun

systme
Inconvnients: difficiles utiliser; Absence de reprsentation squentielle, absence
doprations logiques boolens et impossibilit d'une vue globale du systme

Mthodes de deuxime gnration : connues sous le nom de mthodes

systmiques.
Exemple: Merise, SSADM (Structured Systems Analysis and Design
Method)
Mthodes de troisime gnration ou mthodes objets: OMT (Object
Modeling Technique, 1991), Booch (1991), OOA (Object-Oriented
Analysis, 1992), OOD (object-oriented design), fusion (1991)

Exemples: UML SysML

Introduction: Modlisation

UML (Unified Modeling Language)

lUML a t prsent pour standardiser les mthodes de

modlisations dj prsentes sans standardiser le processus de
dveloppement.
UML est un langage de modlisation qui la fois comprhensible par
les humains (par les graphiques) et par les machines (sa syntaxe).

Une reprsentation visuelle permettant la communication entre les

acteurs d'un mme projet
Une notation graphique simple, comprhensible mme par des non
informaticiens

LUML nest pas dfinit comme une mthode mais un langage de

modlisation objet adopt pour toutes les mthodes Objet. Il est
considr comme une norme de modlisation.
LUML est un langage qui s'appuie sur un mtamodle, un modle de
plus haut niveau qui dfinit:

Les lments d'UML (les concepts utilisables)

Leur smantique (leur signification et leur mode d'utilisation).
8

Introduction

La modlisation UML est utilis pour :

Dcomposer le processus de dveloppement,

Mettre en relation les experts mtiers et les analystes,
Coordonner les quipes d'analyse et de conception,
Sparer l'analyse de la ralisation,
Prendre en compte l'volution de l'analyse et
dveloppement,

du

UML: Formalisme du langage

Principe: tout systme est reprsentable sous forme de vues

partielles. La conjonction des vues permettra de donner une ide
totale et pratique
Ainsi, on peut se contenter de modliser partiellement un systme
et pas compltement modliser les parties qui sont critiques.

Le langage UML peut tre dcompos en deux sous

ensembles :

Les vues : Les vues sont les observables du systme. Elles dcrivent
le systme d'un point de vue donn.

En combinant toutes ces vues il est possible de dfinir (ou retrouver) le

systme complet.

Les diagrammes : Les diagrammes sont des lments graphiques.

dfinissant le contenu des vues, qui sont des notions abstraites
10

UML: Vues

En UML, la manire de dfinir une architecture dun

systme est inspir des 4+1 vues de Kruchten (1995).
Dans ces vues, Kruchten propose 5 faons indpendantes
et complmentaires pour dfinir un modle
d'architecture :

11

UML: Vues

Vue logique:

Cette vue explique comment peuvent tre satisfaits les besoins

des acteurs (c'est le COMMENT).
Cette vue organise aussi (selon des critres purement
logiques), les lments du domaine en catgories ce qui va
permettre de rpartir les tches dans les quipes, de regrouper
ce qui peut tre gnrique et disoler ce qui est propre une
version donne, etc...

12

UML: Vues

Vue d'implmentation

Vue de bas niveau, appele aussi vue de ralisation .

Sont rle est didentifier les modules qui ralisent
(physiquement) les classes de la vue logique
Elle

permet l'allocation des lments de modlisation dans des

modules (fichiers sources, bibliothques dynamiques, bases de
donnes, excutables, etc...)

13

UML: Vues

Vue des processus

Cette vue est trs importante dans les environnements

multitches,
Cette vue exprime:

La dcomposition du systme en terme de processus (tches).

Les interactions entre les processus (leur communication).
La synchronisation et la communication des activits parallles
(threads).

14

UML: Vues

Vue des cas d'utilisation (use cases)

C'est la description du modle vue par les acteurs du

systme.
Elle correspond aux besoins attendus par chaque acteur (c'est
le QUOI et le QUI).
Elle dfinit les besoins des clients du systme et centre la
dfinition de l'architecture du systme sur la satisfaction (la
ralisation) de ces besoins.
A l'aide de scnarios et de cas d'utilisation, cette vue conduit
la dfinition d'un modle d'architecture pertinent et cohrent.

15

UML: Les diagrammes

Les diagrammes sont utiliss pour reprsenter les

diffrentes vues et ainsi reprsenter des concepts
particuliers du systme d'information.
UML 2.X propose 14 types de diagrammes (9 en UML
1.3) qui dpendants hirarchiquement et se compltent,
de faon permettre la modlisation d'un projet tout au
long de son cycle de vie.
Ces diagrammes se rpartissent en trois grands groupes :

Diagrammes structurels ou statiques (Structure Diagram) :

permet de reprsenter le systme physiquement
Diagrammes comportementaux ou dynamiques (Behavior
Diagram) : montrent le fonctionnement du systme
Diagrammes fonctionnels: dcrivant le besoin fonctionnel du
systme
16

Les diagrammes

17

Diagramme de cas dutilisations (Use Cases)

Les diagrammes de cas d'utilisation est une faon simple

pour exprimer les besoins utilisateurs dune application
Un diagramme de cas d'utilisation capture le
comportement d'un systme, d'un sous-systme, d'une
classe ou d'un composant tel qu'un utilisateur extrieur le
voit

tape importante pour produire un logiciel conforme aux

attentes des utilisateurs

18

Elments des diagrammes de cas dutilisation

Acteur

Un acteur est l'idalisation d'un rle jou par une personne

externe, un processus ou une chose qui interagit avec un
systme

Ou bien

19

lments des DCU:

Acteur

Comment identifier les acteurs ?

Les acteurs d'un systme sont les entits externes ce

systme et qui interagissent (saisie de donnes, rception
d'information, ) avec lui
Les

acteurs sont l'extrieur du systme et dialoguent avec lui

Les acteurs peuvent tre:

Des utilisateurs: Client, responsable clientle, bibliothcaire,

responsable d'agence, administrateur,
Les systmes avec lesquels le systme va devoir communiquer: les
priphriques manipuls par le systme (imprimantes, hardware d'un
distributeur de billet, ), des logiciels dj disponibles intgrer dans
le projet, des systmes informatiques externes au systme mais qui
interagissent avec lui,
20

Elments des DCU:

Cas d'utilisation

Est une unit cohrente reprsentant une

fonctionnalit visible de l'extrieur
Qui ralise un service de bout en bout, avec un
dclenchement, un droulement et une fin, pour
l'acteur qui l'initie

modlise

un service rendu par le systme, sans imposer le

mode de ralisation de ce service

21

Elments des DCU:

Cas dutilisation

Reprsentation graphique:

Ou bien

Ou bien

Remarque:
Le nom du cas d'utilisation doit commencer par un verbe linfinitif suivi
d'un complment en se plaant du point de vue de l'acteur et non pas de
celui du systme
Retirer largent

Et NON pas

Distribuer de l'argent

Consulter le solde

Et NON pas

Consultation du Solde
22

Reprsentation d'un DCU

23

Relations dans les DCU

I- Relations entre acteurs et cas d'utilisation

Relation d'association:

le chemin de communication entre un acteur et un cas d'utilisation est

reprsent par un trait continu

Multiplicit:

Lorsqu'un acteur peut interagir plusieurs fois avec un cas d'utilisation,

il est possible d'ajouter une multiplicit sur l'association du ct du cas
d'utilisation

Le symbole * signifie plusieurs fois. Si lchange est n fois alors on met n. Alors
que n..m signifie entre n et m fois, etc.

24

Relations dans les DCU

I- Relations entre acteurs et cas d'utilisation

Acteurs principaux et secondaires:

Un acteur est qualifi de principal pour un cas d'utilisation lorsque ce cas
dutilisation rend service cet acteur.
on ajoute le strotype: << primary >>
Un acteur est qualifi de secondaire dans le cas contraire.
on ajoute le strotype: << secondary >>

Exemple: Le client, acteur principal effectue le retrait alors que le

systme bancaire, acteur secondaire administre le retrait

25

Relations dans les DCU

II- Relations entre cas d'utilisation

Cas d'utilisation interne:

Quand un cas dutilisation n'est pas directement reli un

acteur, il est qualifi de cas d'utilisation interne.
Diagramme Use cases de lutilisation dune carte bancaire
<<primary>>

Retirer largent

<<include>>
Vrifier si solde
suffisant

Il existe deux types de relations :

1.
2.

Inclusion et extension: ce sont les plus utiliss

La gnralisation/spcialisation.
26

Relations dans les DCU

II- Relations entre cas d'utilisation

Relation de dpendance: Inclusion / extension

Une dpendance se reprsente par une flche avec un trait

pointill

Direction de la flche:

Si un cas A inclut ou tend un cas B, la flche est dirige de A

vers B

27

Relations dans les DCU

II- Relations entre cas d'utilisation

Relation
de
dpendance:
Relation
d'inclusion
Un cas dutilisation A inclut un cas dutilisation B si le
comportement dcrit par le cas A inclut le comportement du
cas B : le cas A dpend de B

Lorsque A est sollicit, B l'est obligatoirement comme une partie de A

Cette dpendance est symbolise par le strotype << include >>

28

Relations dans les DCU

II- Relations entre cas d'utilisation

Relation de dpendance: Relation d'extension

On dit qu'un cas d'utilisation A tend un cas d'utilisation B
lorsque le cas d'utilisation A peut tre appel au cours de
l'excution du cas d'utilisation B

Excuter B peut ventuellement entraner l'excution de A

(contrairement l'inclusion, l'extension est optionnelle)
Cette dpendance est symbolise par le strotype << extend >>

29

Relations dans les DCU

II- Relations entre cas d'utilisation

Relation de dpendance: Relation d'extension

Point dextension: L'extension peut intervenir un point prcis du

cas tendu
Une extension est souvent soumise condition

la condition est exprime sous la forme d'une note

30

Relations dans les DCU

II- Relations entre cas d'utilisation
Relation de gnralisation

Un cas A est une gnralisation d'un cas B si B est un cas particulier de A

Le symbole utilis pour la gnralisation est une flche avec un trait plein
dont la pointe est un triangle ferm dsignant le cas le plus gnral

Cette relation est prsente dans la plupart des diagrammes UML et se traduit par le
concept d'hritage dans les langages orients objet.
31

Relations dans les DCU

III- Relations entre acteurs
Une seule relation entre acteurs peut tre dfinie:

Relation de gnralisation

Un acteur A est une gnralisation d'un acteur B si l'acteur A peut tre

substitu par l'acteur B.

Tous les cas d'utilisation accessibles A le sont aussi B, mais l'inverse n'est
pas vrai.

32

DCU

Exercice 1

Le diagramme de cas dutilisation de la figure suivante

reprsente les fonctionnalits dune agence de voyage
classique.

Donnez les relations entre acteurs et cas dutilisation

Donnez les relations entre cas dutilisations
Donnez les relations entre acteurs

33

DCU

Exercice 2:
On considre un systme simplifi de Guichet Automatique de Banque
(G.A.B.). Ce systme offre les services suivants:

Distribution d'argent tout porteur de carte de crdit (carte Visa,

ou carte de la banque),

Consultation de solde,

Un client peut si il veut avoir un relev aprs une transaction

Toutes les transactions sont scurises avec une authentification

Identifiez les principaux ACTEURS du ce systme

2. Elaborez le diagramme de cas dutilisation du GAB.
1.

34

DCU

Solution

35

DCU

Exercice 3:
Le systme prcdant GAB est modifi comme suit:

En plus de la consultation de solde de compte, le systme permet

aussi de faire un dpt en numraire et dpt de chques pour les
clients de la banque porteurs d'une carte de crdit de la banque.

Aussi, le GAB ncessite des actions de maintenance, telles que le

rechargement en billets du distributeur, la rcupration des cartes
avales et des chques dposs, etc.

Identifiez les nouveaux ACTEURS du ce systme

2. Elaborez le nouveau diagramme de cas dutilisation du GAB.
1.

36

DCU

Exercice 3

37

Solution atelier

38

 faire

Dans un fichier pdf ou word que je vais rcuprer

dans 30 minutes, donner une description complte du
diagramme dutilisation de la gestion de la bibliothque

Le fichier doit aussi contenir le DCU dessin sous BOUML

Il faut tiqueter votre DCU: donner les dfinitions des
lments graphiques utiliss.

39

Autres diagrammes UML

40

Autres diagrammes UML

UML 2.x propose 13 diagrammes et 9 dans UML 1.x

Peuvent tre rpertoris en 3 catgories

Diagrammes structurels ou
statiques (ce que les
systme EST)
Diagrammes
comportementaux
ou
fonctionnels (ce que le
systme FAIT)
Diagrammes dinteraction
ou dynamiques (comment le
systme EVOLUE)

41

Les diagrammes UML les plus utiliss

Diagramme des cas d'utilisation :

Diagramme de classes:

Permet une reprsentation squentielle du droulement des traitements

et des interactions entre les lments du systme et/ou de ses acteurs.

Diagramme de composants :

Reprsente les classes (entits) intervenant dans le systme

Diagramme de squence :

Identifie les possibilits d'interaction entre le systme et les acteurs

(intervenants extrieurs au systme), c'est--dire toutes les
fonctionnalits que doit fournir le systme.

Reprsente les composants du systme d'un point de vue physique, tels

qu'ils sont mis en uvre (fichiers, bibliothques, bases de donnes)

Diagramme de dploiement:

Reprsente les lments matriels (ordinateurs, priphriques, rseaux,

systmes de stockage) et la manire dont les composants du systme
sont rpartis sur ces lments matriels et interagissent entre eux.
42

SysML

44

Introduction

SysML: un langage de modlisation spcifique au domaine

de l'ingnierie systme

Il permet:

La spcification,
l'analyse,
la conception,
la vrification
la validation de nombreux systmes et systmes-de-systmes.

SysML est une extension/adaptation de UML

SysML: ddi pour la modlisation des systmes complexes

UML: orient logiciel (applications informatiques utilisant la
notion de programmation objet)
45

Introduction

SysML est un langage plus rduit que UML

apprentissage/utilisation beaucoup plus facile
SysML limine les concepts d'UML qui sont lis sa vision
centre sur le logiciel
Rduction de nombres de diagrammes dUML: rutilise sept
diagrammes dUML (13 diagrammes) et ajoute de deux
nouveaux types de diagrammes

UML

SysML

46

Diagrammes SysML
Diagrammes ajouts

Diagramme conservs

Diagrammes
supprims

Diagrammes adapts

diagramme des
exigences

diagramme des cas

d'utilisation

diagramme de
composants

diagramme de
dfinition de bloc
(diagramme de classe
dans UML)

diagramme
paramtrique

diagramme de
squence

diagramme de
communication

diagramme de blocs
internes (diagramme
de structure
composite dans UML)

tableaux d'allocations
qui sont drivs des
autres diagramme
SysML

diagramme d'tat

diagramme de
dploiement

diagramme d'activit

diagramme global
d'interaction

diagramme des
paquetages

diagramme de temps
diagramme d'objets

47

SysML: Diagramme des exigences

48

Diagramme des exigences: requirement diagram

1re nouveaut du SysML par rapport UML

Cest un diagramme fonctionnel qui dcrit les exigences du

cahier de charges fonctionnel.
Cest une faon innovatrice permettant de dessiner
graphiquement les exigences systmes

Une exigence:

Permet de spcifier une capacit, une contrainte ou une fonction que le

systme doit satisfaire.

49

Diagramme des exigences

Reprsentation graphique:

Chaque exigence et reprsente par un rectangle strotyp

requirement identifi par un identifiant unique et un texte
descriptif
Les exigences peuvent tre relies entre elles par de relations de :

Contenance: ligne pleine termine par un cercle contenant une croix du

ct conteneur. Ceci pour rle de dcomposer une exigence composite
en plusieurs exigences unitaires,
Le raffinement (refine): flche en des tirets dont la source est la
prcision et qui est strotype refine. Ceci pour rle dajouter une
prcision une exigence
la drivation ( deriveReqt ): flche en des tirets dont la source est la
prcision et qui est strotype deriveReqt . Consiste relier des
exigences leurs drives: relier des exigences systmes des exigences
de niveau sous-systme

50

Diagramme des exigences

Exemple - Robot AL@DYN: une camra de surveillance

associe une plateforme robotique, lensemble pouvant
tre pilot et consult distance.

51

Diagramme des exigences

52

Diagramme des exigences

Exercice:

Modifier le diagramme des exigences suivant pour ladapter

aux spcifications suivantes:

Le rebot une base pour le

charger quand il nest pas en
charge suffisante
Le rebot est quip de capteurs
embarqus pour le guider dans
sa progression ceci pour viter
les obstacles
La
camra
est
mobile
verticalement et cette mobilit
est assure par une liaison
mcanique
53

Diagramme des exigences

54

Diagramme des exigences

Complments

SysML permet lutilisation des notes (commentaires) sur tous

les types de diagrammes. Deux mots-cls particuliers ont t
dfinis afin de reprsenter :
1.
2.

des problmes rsoudre ( problem )

des justificatifs ( rationale ).

55

Diagramme des exigences

56

Diagramme des exigences

Exercice: Lave linge

Proposer un diagramme des exigences dun lave linge en se

basant sur les spcifications suivantes

Le lave linge propose trois types de programmes:

Laver le linge: Plusieurs type de lavage sont possibles (coton, esthtique,

enfant, la main, rapide)
Chauffer leau: la temprature de leau doit tre programme et varie
entre 30 et 100.
Essorer le linge: le linge peut tre essor une vitesse allant de 500tr/min
1500tr/min.

Pour des raisons de scurit, il y a des contraintes sur la fermeture et

louverture de la porte du lave linge.Ainsi;

Il faut que la porte soit ferme pour excuter les programmes

slectionns.
La porte ne peut tre ouverte quaprs la fin de lexcution du programme
slectionn.
57