SlideShare une entreprise Scribd logo
1  sur  83
Télécharger pour lire hors ligne
1
Conception des protocoles
de communication
Azza Ouled Zaid
Institut Supérieur d’Informatique
2ème année Cycle d’Ingénieurs
2
Conception des protocoles
 Conception des protocoles
 Processus de conception des protocoles
 Spécification des protocoles
 Test des protocoles
 Spécification SDL
3
Techniques de conception
 Application des méthodes formelles et informatiques pour la
conception des logiciels de communication
 Méthodes informelles :
 manque de fondation théorique
 définition ambiguë des dispositifs désirés
 pas moyen de vérifier la complétude et la consistance du système
 coût économique exorbitant
 Méthodes formelles :
 techniques mathématiques qui offrent une base rigoureuse du
développement logiciel, qui mène à la justesse et la fiabilité à
différentes étapes
4
Langage formel
 Une syntaxe formelle stricte
 exposer des énoncés de manière précise, concise et sans
ambiguïté
 simplifier la manipulation et la transformation d'énoncés.
 Appliquer les règles de transformation précises
 développement de formules logiques, contrapositions,
commutativité, associativité, etc.
 sans connaître la signification de l'énoncé transformé ou la
signification de la transformation.
5
Langage formel
 Le seul langage permettant aux machines de « faire
des mathématiques ».
 L'inconvénient : ne pas connaître le sens de l'énoncé
empêche de savoir quelles sont les transformations
pertinentes et nuit à l'intuition du raisonnement.
6
Méthodes formelles pour la
conception des protocoles
 Offre une façon formelle et sûre pour la conception des
protocoles
 modélisation des protocoles et spécification
 synthèse des protocoles
 Permet une analyse formelle avant l’implémentation du
protocole
 vérification et validation des protocoles
 analyse de performance des protocoles
7
Langage formel pour la
conception des protocoles
 Une génération directe et automatique des
programmes exécutables à partir d’une spécification
formelle
 Pas très répondu ni bien établi
 coût élevé en terme de temps et ressources
 apprendre un langage formel est aussi difficile
qu’apprendre un langage de programmation
8
Principes de conception des
protocoles
 Un concepteur adhère à une discipline si seulement
si elle nous permet d’obtenir :
 simplicité
 modularité
 faisabilité
 robustesse aux pannes
 comportement : ordonnancement, absence de blocage,
cohérence des données partagées
9
Simplicité
 Un protocole bien structuré  réalisé à partir d’un petit nbre de
blocs clairs et bien conçus
 Chaque bloc réalise convenablement une fonction
 Le fonctionnement des blocs et leur façon d’interagir.
 facile à comprendre et à implémenter, facile à vérifier et à
maintenir.
 Les protocoles légers vérifient l’argument suivant : efficacité et
vérifiabilité ne sont pas des objectifs orthogonaux mais
complémentaires
10
Modularité — Une hiérarchie des
fonctions
 Une fonction complexe peut être construite avec des petits
blocs qui interagissent d’une manière simple.
 Chaque petit bloc est un protocole léger qui peut être
séparément réalisé, vérifié, implémenté et maintenu
 Les fonctions orthogonales sont conçues d’une façon
indépendante.
 La structure du protocole résultant est ouverte, extensible,
remplaçable sans affecter le fonctionnement des
composants individuels
11
Modularité — Une hiérarchie des
fonctions
 Les modules individuels ne fixent aucune hypothèse sur la
présence des autres modules ou leur fonctionnement.
 Le contrôle des erreurs et le contrôle des flots de données sont des
fonctions orthogonales, résolus séparément
 Ils n’imposent aucune hypothèse sur les données à part celui qui est
strictement nécessaire à la réalisation de cette fonction
• Un système de correction ne doit pas imposer des hypothèses
sur, codage des données, vitesse de transmission. Ces
préoccupations, s’ils sont nécessaires sont placés dans d’autres
modules, spécialement optimisés à cet objectif
12
Protocole bien formé
 Ne doit pas contenir des codes inatteignables ou inexécutables.
 Complétude : un protocole incomplet peut causer des réceptions non
définies durant l’exécution.
 Borné : il ne dépasse pas les limites du système (capacité des files
d’attente).
 Stabilisation automatique :
 Si une erreur résiduelle change arbitrairement l’état du protocole ce dernier
retourne toujours à l’état ciblé.
 Si le protocole est initialisé à partir d’un état aléatoire il atteint l’état ciblé
dans un temps fini
 Adaptation dynamique
 Ex: adapter le débit de transmission à la capacité du canal et au débit de
réception.
13
Robustesse
 Les événements inattendues exigent des considérations
automatiques
 Pas difficile de concevoir un protocole qui travaille dans des
conditions normales
 Leur défi est l’inattendu. le protocole doit être préparé pour traiter
convenablement chaque action faisable et chaque chaîne
d’action réalisable sous n’importe quelle condition possible.
 Le protocole devrait prendre en charge au minimum son
environnement pour éviter des dépendances sur les dispositifs
particuliers qui pourraient changer.
14
Robustesse
 Une conception robuste est automatiquement mise à l’échelle de
la nouvelle technologie, sans exiger les changements
fondamentaux.
 Une conception minimale qui élimine les contraintes non
essentielles qui pourraient empêcher l'adaptation aux conditions
imprévues.
 Élimination des aspects les moins pertinents pour ne considérer
que ceux qui sont essentiels.
15
Cohérence
 Il y a quelques normes et manières redoutées dans lesquelles les
protocoles peuvent échouer
 Blocage : états dans lesquels aucune autre exécution de protocole
n'est possible,
• Ex: touts les processus du protocole attendent les conditions qui ne
peuvent jamais être remplies.
 Boucle infinie : séquence d’exécutions qui peuvent être répétées
indéfiniment souvent sans accomplir jamais le progrès efficace.
 Arrêts non déterminé : l'accomplissement d'une exécution de
protocole sans satisfaire les conditions d’arrêt appropriées.
16
 En général, le respect de ces critères ne peut
pas être vérifié par une révision manuelle des
spécifications de protocole.
 Des outils plus puissants sont nécessaires pour
les empêcher ou les détecter.
17
Les 5 éléments d’un protocole
 Les spécifications de protocole se composent de cinq parties
distinctes. Pour être complète, chaque spécification doit inclure
explicitement :
1. Le service à fournir par le protocole
2. Les conditions au sujet de l'environnement dans lequel le protocole
est exécuté
3. Le vocabulaire des messages employés pour mettre en application
le protocole
4. Le codage (format) de chaque message dans le vocabulaire
5. Les règles de procédures gardant l'uniformité des échanges de
message
18
Les 5 éléments d’un protocole
(suite)
 L’étape 5, est le cœur d’un protocole.
 Une assertion de justesse est une assertion sur la
possibilité ou l’impossibilité d’un comportement
 Définir des formalismes pour décrire et vérifier le
comportement des processus
19
Dix règles de base de conception
de protocole
1. Assurez-vous que le problème est bien défini.
2. Définissez le service à réaliser à chaque niveau
d'abstraction (qui vient avant et comment?).
3. Concevez la fonctionnalité externe avant la
fonctionnalité interne.
4. Maintenez-la simplicité
5. Identifier les problèmes plus simples, les séparer, et
puis les résoudre individuellement.
6. Ne reliez pas ce qui est indépendant. Séparez les
préoccupations orthogonales.
20
Dix règles de base de conception
de protocole (suite)
7. Ne présentez pas ce qui est négligeable.
8. Avant de mettre en application une conception,
établissez un prototype à niveau élevé et vérifiez que
les critères de conception sont rencontrés.
9. Implémenter la conception, mesurez sa performance, et
au besoin, optimisez-la.
10. Vérifiez que la version finale d‘implémentation
optimisée est équivalente à la conception qui a été
vérifiée.
 Ne sautez pas les règles 1 à 7.
 La règle 10 est la plus fréquemment violée
21
Développement des logiciels
 Le développement des logiciels passe par des
phases qui amènent à la production d’un système
vérifiant certaines caractéristiques et répondant
aux besoins préalablement requis.
 Ces phases font partie de tous les cycles de
développement de systèmes indépendamment de :
 la nature, domaine, taille et la complexité du
système à développer.
22
Le génie logiciel
 Le modèle du cycle de vie (ou de processus) d’un
logiciel est un modèle de phases qui commence quand
le logiciel est conçu et se termine quand le produit n’est
plus disponible pour l’utilisation.
 Plusieurs modèles de cycle de vie d’un logiciel existent
 Le mode d'organisation le plus employé et normalisé par
l'AFNOR (Association Française de Normalisation) est
une technique par anticipation appelée Modèle en V
23
Le modèle de développement en
V
 Le plus tôt qu’on identifie une erreur dans la trajectoire de
développement, le moins cher il est de corriger l’erreur
24
Modèle d’un logiciel
 Une spec formelle est un modèle abstrait
 Un modèle est une entité qui se comporte comme le
système réel de certains points de vue
 P.ex. un modèle d’avion pourrait
• Être comme l’avion, mais beaucoup plus petit
• Être comme l’avion, mais ne pas voler
• Se comporter comme l’avion pour le pilote, mais il ne peut pas
avoir des passagers, ne peut pas voler, etc. (simulateur de vol)
 Donc il est une abstraction
 Un modèle formel d’un logiciel est une entité mathématique qui
a certaines des caractéristiques du logiciel, mais pas d’autres
• P.ex. n’est pas capable de fonctionner à la même vitesse, ne peut
pas produire la sortie dans l’exacte forme désirée, etc.
25
Différents niveaux de spécif
et cycle de développement
 Nous pouvons effectuer des
V&V et du test entre tous les
niveaux
Spec d’exigences (langue
naturelle, notation logique)
Spécification du
comportement
Spécification de
l’implantation
(comportement utilisant des
composantes données)
Implantation
26
Spécification d’exigences ou
besoins
 Ce que le système doit faire pour l’usager,
 les exigences peuvent être à plusieurs niveaux
d’abstraction, peuvent représenter différents aspects du
système
 Nombreuses méthodes de spec développés, p.ex.
 Use Cases (UML)
 Notations logiques
 Diagrammes de transitions d’états…
27
Spécification du comportement
 Décrit le comportement du système en termes de
séquences d’interactions possibles avec
l’environnement
 Les modèles à états sont les plus souvent utilisés,
p.ex.
 au début, le système et dans l’état inactif,
 ceci rend possible une transition signalisation, par laquelle le
système passe à un état attente
 puis il passe à l’état signal occupé
 La structure interne de la spec est abstraite, ne
correspond pas à un modèle d’implantation
28
Spécification de l’implantation
 Semblable à la spec du comportement
 Mais la spec a une structure interne qui
correspond à un modèle d’implantation
 Décrit les composantes de l’implantation,
etc.
29
Vérification et test
 La vérification est une technique dont le rôle est de
s’assurer qu’un système corresponde aux exigences
 Une distinction plus fine est entre
 Validation: la fonctionnalité du système correspond-elle aux
exigences de l’usager?
 Vérification: le système, fonctionne-t-il bien?
 Dont l’acronyme V&V
 Test: processus de détection de fautes par exécution et
comparaison des résultats avec les exigences
30
Validation et vérification
 Conformité aux exigences : système |= spécification
 Validation : do we build the right product ?
 Vérification : do we build the product right ?
 En pratique :
 examen du code par une équipe indépendante
 test (en général ad hoc)
 Vérification en fin de conception
 irréaliste : il n'y a pas de spécification complète
 infaisable : outils de vérification pas assez puissants
 inutile : erreurs détectées trop tard
 intégrer V & V dans la conception
31
Techniques de vérification
 Vérification déductive
 règles de preuve associées aux instructions du programme
 vérification suivant la structure syntaxique
 mécanisation : assistants de preuve, démonstrateurs de
théorèmes
 Vérification sémantique (model checking)
 méthode algorithmique de vérification
 exploration exhaustive de l'espace d‘états du modèle
 domaine d'application : hardware, protocoles de communication,.
 vérification de propriétés ou d‘équivalences entre modèles
 Pre-requis
 sémantique (opérationnelle ou axiomatique) des systèmes
langage de spécification
32
Techniques de validation
 Simulation
 exécution d'un modèle du système
 prototypage, discussion avec le client
 Test
 appliquer des stimuli à l'implémentation du système
 Établir la conformité à l'objectif de test
 white box : structure interne du système connue
 black box : on ne connaît que l'interface du système
 montre la présence d'erreurs, jamais leur absence (Dijkstra)
 Standardisation : ISO-ITU-T 96
 génération de cas de test (use case) pour l'objectif visé
 sélection d'un sous-ensemble représentatif
 implantation des cas de test
 exécution avec le logiciel test
 analyse des résultats
33
Cycle de vie du système de
télécommunication
Étude préalable
de besoin
Spécification
Conception
générale
Implémentation :
Spécification logicielle
Conception préliminaire
Conception détaillée et
Génération du code
Tests
d'intégration (cible)
Déboguage
Tests unitaires
Tests d'intégration (hôte)
Tests
fonctionnels
Exploitation
maintenance
34
Spécifications des protocoles
 Les spécifications de protocole consiste à
 préciser l’ensemble des objectifs à réaliser
par la mise en œuvre pratique
 définir le comportement requis pour une
entité de protocole
35
Spécifications des protocoles
 la nature des spécifications de protocole a une influence forte
sur le test du protocole
 test de conformité : moyen d’assurer la satisfaction de
l’implémentation du protocole aux besoins
 Les systèmes de protocole ne sont pas des systèmes
logiciels traditionnels, mais une variante du logiciel
 Les systèmes traditionnels se composent des fonctions qui
partent d'un état initial vers un état final
 ces systèmes s'appellent transformationnels parce qu'ils
transforment un premier état à un état final
 les exemples typiques : fabrication, traitements des données
différés, progiciels
Progiciel :Logiciel d'application paramétrable, destiné à la réalisation de diverses tâches.
36
Spécifications des protocoles
 Les systèmes réactifs peuvent ne jamais se terminer
 le but d'exploiter les systèmes réactifs est de maintenir
l'interaction avec l'environnement système
 un système réactif ne peut pas être spécifier en se
référant seulement à ses états initiaux et finals, mais
plutôt à son comportement continu
 les exemples typiques sont les logiciels d'exploitation,
les systèmes de contrôle de processus, et les systèmes
de protocole de communication
37
Spécifications des protocoles
Système de protocole de communication = système réactifs
  Techniques de description formelles :
 réseaux de Pétri, grammaires formelles, langages de
programmation à haut niveau, algèbres de processus,
types de données abstraits, et logique temporelle,
 Les Machine à État fini (MEF) ont été souvent étendues
par l'addition des paramètres et des attributs de données
afin de traiter naturellement certaines propriétés des
protocoles par exemple numérotation des séquences et
adressage
38
Introduction à
SDL
SDL : Specification and Description
Language
39
Développement
 Au début SDL n’était qu’un simple formalisme graphique
pour spécifier les machines à états finis des protocoles
téléphoniques
 En 1984, on ajouta les processus et les données
 SDL 1988 vit une stabilisation sur laquelle on a bâti
ultérieurement
 En 1992 on ajouta l’orientation objet
 En 1996 on ajouta
 ASN.1, une notation pour la spec des structures de
données
 et les Message Sequence Charts
• Aujourd’hui SDL et MSC sont deux notations intégrées
 Nous avons couramment un effort d’intégration de SDL
dans UML
40
Brève intro à l’SDL
 L’SDL est essentiellement graphique, même si une
notation textuelle existe
 Deux éléments primaires:
 Structure
• Identifie les différentes composantes du système, et les voies
de communication
• Composantes: Blocks, Processes
• Communication:
• Channels (entre blocs): communication qui prend du temps
• Signal routes (dans un bloc): communication instantanée
• Les points de connexion: Gates
 Behaviour - Comportement
• Seulement les processus ont un comportement
• Basé sur le modèle des machines à états finis étendues
41
Structure à haut niveau
Block_1
Block_2
Example de system SDL
canal
environnement
path
toEnv1
toEnv2
[m2]
[m3]
[m1]
[m4]
bloc
nom de canal
signaux en sortie
signaux en entrée
Signaux permis
dans ce canal
42
Déclarations de signaux
(dans un système ou bloc ou processus)
SIGNAL
m1, m2, m3(INTEGER), m4, m5;
paramètres
43
Dans un Bloc
 un système est composé de blocs, les blocs sont
composés de processus
Block Block_1
nom de bloc
Process_1
Process_2
[m1]
[m4]
[m5]
signal route
processus
sr1
sr2
sr3
nom de signal route
SIGNAL
m5;
44
Processus
 À moins de spécification explicite, une instance d’un
processus est créée à l’amorçage du système, et continuera
jusqu’à ce que le processus décide de se terminer
 Chaque processus reçoit (automatiquement par le système)
son propre Process Identifier ou PID
 Les processus peuvent être créés dynamiquement:
P(1,3)
No d’instances à
l’initialisation
P(0, )
No max d’instances
No illimité
d’instances
45
Block_3:
aType
Block_4:
aType
Example2
Block Types
path
toEnv1
toEnv2
[m1]
[m1]
[m4] [m4]
g1
g2
g1
g2
aType
block type block instances
type
of
instance
gate
references
46
Intérieur d’un Block Type
Block Type aType
block type name
Process_3
Process_4
[m4]
[m1]
[m5]
gate
reference
gate
sr4
sr5
sr6
gate name
g1
g2
[m4]
[m1]
[m4]
Signaux permis à
travers porte
g2
[m4]
g1
47
Process Types
P_type
Symbol:
P1: P_type
Instance:
48
Signal List pour abréger les
listes
SIGNAL
m1, m2, m3(INTEGER), m4;
SIGNALLIST
list1 m1, m2, m3, m4;
Example3
signal list name
Block_b
[(list1)]
Utilisation de
signal list
49
Détails
 Les blocs peuvent contenir des sous-blocs
ou aussi des processus
 Les déclarations de signaux, listes de
signaux, etc., peuvent être à tous les
niveaux
 Encourage la bonne pratique de faire les
déclarations au niveau le plus interne
50
Behaviour, Comportement
 Seulement les processus peuvent avoir un comportement
 Le comportement définit une machine à états finis étendue
(MEFE)
 Modèle:
 Chaque processus a une (et seulement une) file d’entrée à
travers laquelle il peut recevoir des signaux
 Cette file est infinie théoriquement, mais finie en pratique
 Signaux de sources différentes sont ajoutés à la même file à
leur arrivée
• Tandis que dans le modèle MEFC (Chap. 4) il y a un canal pour
chaque paire de processus communicants
 Quand un signal en tête d’une file d’entrée d’un processus est
égal au signal d’entrée qui cause une transition d’état possible
pour l’état courant du processus, cette transition est effectuée et
le signal est enlevé de la file
51
Communication entre
processus
P1
P2
P3
…
Chaque proc a sa propre
file d’entrée, une seule
Un proc peut insérer des
signaux dans sa propre file
52
Transitions d’états en SDL
 En principe, le modèle d’automate de
SDL est le modèle Mealy:
 Cependant ce modèle a été élargi en
SDL.
 Les transitions peuvent être des
programmes de complexité arbitraire
entrée / sortie
53
Transitions en SDL
 Une transition contient une entrée au
début
 Sauf pour le cas de garde… (à voir)
 Et peut contenir 0 ou plusieurs sorties
 Même une boucle de sorties…
54
SDL Behaviour-Comportement
state1
m5
m2
state2
état
entrée
m4
m4
state3
prochain état
Process p1
state1
état initial
sortie
Observez les symboles pour les entrées,
les sorties, et les états
55
Variables
 Les déclarations sont séparées par des virgules, à la fin de
toutes il y a un ;
DCL
v1 INTEGER,
v2 PID,
v3 BIT,
v4 OCTET,
v5 DURATION;
Identificateur de proc
Pour la minuterie
0 ou 1
huit bits
Nom de
variable
Type de
variable:
entier
56
Entrée de valeurs
http://www.sdl-forum.org/sdl88tutorial/3/signals.htm
57
Mécanismes d’interaction et
transitions
 Si à un moment donné la file d’entrée n’est
pas vide, le premier signal est enlevé
 S’il y a une transition correspondante, elle
est exécutée
 Sinon le message est écarté, à moins que…
(save!)
58
SAVE
Dans cet exemple, le signal C est remis dans le canal.
Si p.ex. il y a un signal A après le C, la transition A est effectuée mais C
reste dans le canal.
Malheureusement, la manière dans laquelle cette fonctionnalité est
censée fonctionner n’est pas définie dans la norme et elle est laissée à
l’implémentation
Questions possibles, pas résolues dans la norme :
 Dans quelle position du canal est-il mis? Au début ou à la fin?
 Sera-t-il encore disponible si le prochain état aussi ne peu pas
l’utiliser?
save
http://sdl-forum.org/sdl88tutorial/4/semantics_of_the_communication.htm
59
Variables PID
 Chaque signal d’entrée porte automatiquement le PID du
proc qui l’a envoyé
 Chaque processus a une var prédéfinie SENDER
 Quand un signal d’entrée est reçu, la valeur du PID de l’envoyeur est
affecté à SENDER
 Autres PIDs prédéfinis:
 SELF: le PID de ce processus
 PARENT: le processus qui a créé ce processus
 OFFSPRING: le processus le plus récemment créé par ce
processus
 Les PIDs sont générés automatiquement par le système
d’exécution, donc l’usager pourrait avoir quelques difficultés
à les reconnaître…
60
Gardes
state1
m3
state2
m4
m1
state3
x = 5
x < 0
Nous venons ici s’il
n’y a pas d’entrée
appropriée pour l’état
et la cond est vraie
DCL
x INTEGER;
Condition garde
Si condition
vraie on vient ici
61
Fonctionnement des transitions
avec gardes
 On contrôle la file d’entrée
 S’il y a un signal approprié dans la file
d’entrée, on suit la transition pour ce signal
 Si la file est vide ou il n’y a pas de signal
attendu, mais la garde est vraie, on suit la
transition de la garde
62
Minuterie
 Actions avec minuterie
 SET: Une minuterie est amorcée avec une valeur
• Le langage ne spécifie pas les unités de temps
• Défaut outil Tau: millisecondes
 RESET: Annule une minuterie déjà amorcée
 EXPIRY: Notification que la minuterie est déclenchée
• Résultat: un message d’expiration avec un nom qui
est celui de la minuterie est mis dans la file d’entrée
du processus (!)
• Ceci veut dire que une temporisation pourra être
reçue quelque temps après
63
Minuteries, timers
set(now+5.0,t1) Amorce minuterie t1
Temporisation 5.0 “unités de temps”
de maintenant
state1
t1 m2
reset(t1)
TIMER t1;
Rec. message d’expiration de t1
Annulation de minuterie
Déclaration de t1
64
SDL Process with Timers and Queues
SDL Process
Input Queue (per process)
Timer
Synchronize with
global time
Get value
of NOW
Ask for value
of NOW
Send signal to another process
Get signal from
another process
(queue always open)
Place timer signal into the queue
Remove timer signal from the queue
Timer signal consumed by SDL process (can deactivate)
SET, RESET Ready to consume a signal
Send signal to process
as soon as have one
Modified
FIFO
RESET – remove from queue and de-activate (stop counting)
SET – RESET and activate (start counting)
3 states of a timer - active
- inactive
- timer signal in queue
current time
65
Programmer les transitions
 Une transition, causée par une entrée du
canal ou une garde, peut contenir un
programme entier, impliquant 0 ou plusieurs
sorties en positions différentes
 Pour programmer ces transitions, plusieurs
éléments sont fournis, correspondant aux bien
connus organigrammes (flow-charts)
66
Exemples d’éléments
qui peuvent être utilisés dans une transition
x := 0 Affectation de variables
Prcd_name Appel de procédures
Prcs_name Création d’instance de processus
Terminaison de processus
67
Décisions
 Opérateurs: <, <=, >, >=, =, /=
x = 3
true
false
x
=2
= 1 else
variable
conditions
Condition
logique
68
Entrée/sortie de signaux
 Options pour les sorties des signaux:
 Le signal est envoyé sur la route spécifiée
 Le signal est envoyé au processus spécifié
m3 VIA signal_route_name
m3 TO process_id
69
Environnement
L’environnement est connecté au système comme un autre
processus
L’environnement est supposé savoir quels messages à envoyer à
un moment donné, sinon ils seront écartés
70
SDL/GR et SDL/PR
http://www.sdl-forum.org/sdl2000present
71
Message
Sequence Charts
72
Introduction à MSC
 Langage graphique et textuel pour spécifier les séquences
d’événements dans un système
 semblable aux Diagrammes de séquence de l’UML
 La notation par laquelle les scénarios d’un système SDL sont
présentés
 Deux parties:
 MSC réguliers
• montrent directement les messages possibles
 MSC haut niveau (HLMSC)
• montrent la corrélation entre MSC réguliers
73
Diagrammes de séquences (Message
Sequence Charts MSC)
 Décrivent les protocoles de manière visuelle
 communications et interactions
 Expriment des scénarios positifs/négatifs entre processus
concurrents.
 Utilisés au début du cycle de développement
 abstraction des données, etc...
 Standard de la norme Z.120 de l'ITU (CCITT), utilisés dans
UML (Unified Modeling Language).
 La visualisation de la trace du message est choisi d’une
manière simple et intuitive
74
Diagrammes de séquences (Message
Sequence Charts MSC)
 Pour la spécification du transfert des fichiers
 Frontières des interfaces, commande séquentielle
des messages, temporisateurs etc...
 Chaque diagramme MSC représente un scénario
d'un échange typique ou exceptionnel des
messages entre les entités du système
75
MSC for B-ISDN (outgoing call)
76
Message Sequence Graphs
(MSG)
 Un MSG est un graphe, dont les noeuds sont étiquetés
par des MSC.
 Le MSG décrit une spécification comme un ensemble
(éventuellement infini) de MSC, correspondant aux
chemins acceptants du graphe.
 Lors des branchements, les choix locaux des
processus doivent respecter le contrôle global donné
par l'étiquette d'un noeud.
77
Exemple MSG
78
Exemple (MSC)
79
SDL : Specification and
Description Language
 MSC et SDL décrivent le même comportement avec deux
perspectives différentes
 SDL montre comment se comporte chaque entité communicante,
alors que les diagrammes MSC montrent comment ils interagissent
l'un sur l'autre en échangeant des messages
 Avec des spécifications des systèmes de communication complexes
 Structure (architecture) des systèmes
• faire coopérer des parties ( systèmes, blocs, processus)
 Communications avec l'environnement et dans le système
• Canaux comme chemins de communications
• Signaux comme les messages transférés à travers le canal
 Comportement dynamique de chaque pièce basé sur des machines
d'état
80
Annexes
81
Annexes
82
Annexes
83
Annexes

Contenu connexe

Similaire à 1327415.ppt

Présentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxPrésentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxssuserf298861
 
Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011Jean-Marc Fontaine
 
Une application sans framework en 2019
Une application sans framework en 2019Une application sans framework en 2019
Une application sans framework en 2019Rodrigue Villetard
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxZALIMAZA
 
Présentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxPrésentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxZALIMAZA
 
Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptxboulonvert
 
Présentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxPrésentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxZALIMAZA
 
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes PratiquesEmmanuel Hugonnet
 
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4Emmanuel Hugonnet
 
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1DIALLO Boubacar
 
Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Laurent PY
 
introduction génie logiciel-1.ppt
introduction génie logiciel-1.pptintroduction génie logiciel-1.ppt
introduction génie logiciel-1.pptSafaeElhouicha
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxssuserec8501
 
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppthbadir
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptxLatifaBen6
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vieHarun Mouad
 

Similaire à 1327415.ppt (20)

Présentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxPrésentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptx
 
Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011
 
Methodo support
Methodo supportMethodo support
Methodo support
 
Une application sans framework en 2019
Une application sans framework en 2019Une application sans framework en 2019
Une application sans framework en 2019
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptx
 
Présentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxPrésentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptx
 
Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptx
 
Présentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxPrésentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptx
 
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
 
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
 
Cours spring
Cours springCours spring
Cours spring
 
Cours ALGR M1.pdf
Cours ALGR M1.pdfCours ALGR M1.pdf
Cours ALGR M1.pdf
 
PFE PPT2
PFE PPT2PFE PPT2
PFE PPT2
 
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1
 
Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)
 
introduction génie logiciel-1.ppt
introduction génie logiciel-1.pptintroduction génie logiciel-1.ppt
introduction génie logiciel-1.ppt
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
 
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
 

1327415.ppt

  • 1. 1 Conception des protocoles de communication Azza Ouled Zaid Institut Supérieur d’Informatique 2ème année Cycle d’Ingénieurs
  • 2. 2 Conception des protocoles  Conception des protocoles  Processus de conception des protocoles  Spécification des protocoles  Test des protocoles  Spécification SDL
  • 3. 3 Techniques de conception  Application des méthodes formelles et informatiques pour la conception des logiciels de communication  Méthodes informelles :  manque de fondation théorique  définition ambiguë des dispositifs désirés  pas moyen de vérifier la complétude et la consistance du système  coût économique exorbitant  Méthodes formelles :  techniques mathématiques qui offrent une base rigoureuse du développement logiciel, qui mène à la justesse et la fiabilité à différentes étapes
  • 4. 4 Langage formel  Une syntaxe formelle stricte  exposer des énoncés de manière précise, concise et sans ambiguïté  simplifier la manipulation et la transformation d'énoncés.  Appliquer les règles de transformation précises  développement de formules logiques, contrapositions, commutativité, associativité, etc.  sans connaître la signification de l'énoncé transformé ou la signification de la transformation.
  • 5. 5 Langage formel  Le seul langage permettant aux machines de « faire des mathématiques ».  L'inconvénient : ne pas connaître le sens de l'énoncé empêche de savoir quelles sont les transformations pertinentes et nuit à l'intuition du raisonnement.
  • 6. 6 Méthodes formelles pour la conception des protocoles  Offre une façon formelle et sûre pour la conception des protocoles  modélisation des protocoles et spécification  synthèse des protocoles  Permet une analyse formelle avant l’implémentation du protocole  vérification et validation des protocoles  analyse de performance des protocoles
  • 7. 7 Langage formel pour la conception des protocoles  Une génération directe et automatique des programmes exécutables à partir d’une spécification formelle  Pas très répondu ni bien établi  coût élevé en terme de temps et ressources  apprendre un langage formel est aussi difficile qu’apprendre un langage de programmation
  • 8. 8 Principes de conception des protocoles  Un concepteur adhère à une discipline si seulement si elle nous permet d’obtenir :  simplicité  modularité  faisabilité  robustesse aux pannes  comportement : ordonnancement, absence de blocage, cohérence des données partagées
  • 9. 9 Simplicité  Un protocole bien structuré  réalisé à partir d’un petit nbre de blocs clairs et bien conçus  Chaque bloc réalise convenablement une fonction  Le fonctionnement des blocs et leur façon d’interagir.  facile à comprendre et à implémenter, facile à vérifier et à maintenir.  Les protocoles légers vérifient l’argument suivant : efficacité et vérifiabilité ne sont pas des objectifs orthogonaux mais complémentaires
  • 10. 10 Modularité — Une hiérarchie des fonctions  Une fonction complexe peut être construite avec des petits blocs qui interagissent d’une manière simple.  Chaque petit bloc est un protocole léger qui peut être séparément réalisé, vérifié, implémenté et maintenu  Les fonctions orthogonales sont conçues d’une façon indépendante.  La structure du protocole résultant est ouverte, extensible, remplaçable sans affecter le fonctionnement des composants individuels
  • 11. 11 Modularité — Une hiérarchie des fonctions  Les modules individuels ne fixent aucune hypothèse sur la présence des autres modules ou leur fonctionnement.  Le contrôle des erreurs et le contrôle des flots de données sont des fonctions orthogonales, résolus séparément  Ils n’imposent aucune hypothèse sur les données à part celui qui est strictement nécessaire à la réalisation de cette fonction • Un système de correction ne doit pas imposer des hypothèses sur, codage des données, vitesse de transmission. Ces préoccupations, s’ils sont nécessaires sont placés dans d’autres modules, spécialement optimisés à cet objectif
  • 12. 12 Protocole bien formé  Ne doit pas contenir des codes inatteignables ou inexécutables.  Complétude : un protocole incomplet peut causer des réceptions non définies durant l’exécution.  Borné : il ne dépasse pas les limites du système (capacité des files d’attente).  Stabilisation automatique :  Si une erreur résiduelle change arbitrairement l’état du protocole ce dernier retourne toujours à l’état ciblé.  Si le protocole est initialisé à partir d’un état aléatoire il atteint l’état ciblé dans un temps fini  Adaptation dynamique  Ex: adapter le débit de transmission à la capacité du canal et au débit de réception.
  • 13. 13 Robustesse  Les événements inattendues exigent des considérations automatiques  Pas difficile de concevoir un protocole qui travaille dans des conditions normales  Leur défi est l’inattendu. le protocole doit être préparé pour traiter convenablement chaque action faisable et chaque chaîne d’action réalisable sous n’importe quelle condition possible.  Le protocole devrait prendre en charge au minimum son environnement pour éviter des dépendances sur les dispositifs particuliers qui pourraient changer.
  • 14. 14 Robustesse  Une conception robuste est automatiquement mise à l’échelle de la nouvelle technologie, sans exiger les changements fondamentaux.  Une conception minimale qui élimine les contraintes non essentielles qui pourraient empêcher l'adaptation aux conditions imprévues.  Élimination des aspects les moins pertinents pour ne considérer que ceux qui sont essentiels.
  • 15. 15 Cohérence  Il y a quelques normes et manières redoutées dans lesquelles les protocoles peuvent échouer  Blocage : états dans lesquels aucune autre exécution de protocole n'est possible, • Ex: touts les processus du protocole attendent les conditions qui ne peuvent jamais être remplies.  Boucle infinie : séquence d’exécutions qui peuvent être répétées indéfiniment souvent sans accomplir jamais le progrès efficace.  Arrêts non déterminé : l'accomplissement d'une exécution de protocole sans satisfaire les conditions d’arrêt appropriées.
  • 16. 16  En général, le respect de ces critères ne peut pas être vérifié par une révision manuelle des spécifications de protocole.  Des outils plus puissants sont nécessaires pour les empêcher ou les détecter.
  • 17. 17 Les 5 éléments d’un protocole  Les spécifications de protocole se composent de cinq parties distinctes. Pour être complète, chaque spécification doit inclure explicitement : 1. Le service à fournir par le protocole 2. Les conditions au sujet de l'environnement dans lequel le protocole est exécuté 3. Le vocabulaire des messages employés pour mettre en application le protocole 4. Le codage (format) de chaque message dans le vocabulaire 5. Les règles de procédures gardant l'uniformité des échanges de message
  • 18. 18 Les 5 éléments d’un protocole (suite)  L’étape 5, est le cœur d’un protocole.  Une assertion de justesse est une assertion sur la possibilité ou l’impossibilité d’un comportement  Définir des formalismes pour décrire et vérifier le comportement des processus
  • 19. 19 Dix règles de base de conception de protocole 1. Assurez-vous que le problème est bien défini. 2. Définissez le service à réaliser à chaque niveau d'abstraction (qui vient avant et comment?). 3. Concevez la fonctionnalité externe avant la fonctionnalité interne. 4. Maintenez-la simplicité 5. Identifier les problèmes plus simples, les séparer, et puis les résoudre individuellement. 6. Ne reliez pas ce qui est indépendant. Séparez les préoccupations orthogonales.
  • 20. 20 Dix règles de base de conception de protocole (suite) 7. Ne présentez pas ce qui est négligeable. 8. Avant de mettre en application une conception, établissez un prototype à niveau élevé et vérifiez que les critères de conception sont rencontrés. 9. Implémenter la conception, mesurez sa performance, et au besoin, optimisez-la. 10. Vérifiez que la version finale d‘implémentation optimisée est équivalente à la conception qui a été vérifiée.  Ne sautez pas les règles 1 à 7.  La règle 10 est la plus fréquemment violée
  • 21. 21 Développement des logiciels  Le développement des logiciels passe par des phases qui amènent à la production d’un système vérifiant certaines caractéristiques et répondant aux besoins préalablement requis.  Ces phases font partie de tous les cycles de développement de systèmes indépendamment de :  la nature, domaine, taille et la complexité du système à développer.
  • 22. 22 Le génie logiciel  Le modèle du cycle de vie (ou de processus) d’un logiciel est un modèle de phases qui commence quand le logiciel est conçu et se termine quand le produit n’est plus disponible pour l’utilisation.  Plusieurs modèles de cycle de vie d’un logiciel existent  Le mode d'organisation le plus employé et normalisé par l'AFNOR (Association Française de Normalisation) est une technique par anticipation appelée Modèle en V
  • 23. 23 Le modèle de développement en V  Le plus tôt qu’on identifie une erreur dans la trajectoire de développement, le moins cher il est de corriger l’erreur
  • 24. 24 Modèle d’un logiciel  Une spec formelle est un modèle abstrait  Un modèle est une entité qui se comporte comme le système réel de certains points de vue  P.ex. un modèle d’avion pourrait • Être comme l’avion, mais beaucoup plus petit • Être comme l’avion, mais ne pas voler • Se comporter comme l’avion pour le pilote, mais il ne peut pas avoir des passagers, ne peut pas voler, etc. (simulateur de vol)  Donc il est une abstraction  Un modèle formel d’un logiciel est une entité mathématique qui a certaines des caractéristiques du logiciel, mais pas d’autres • P.ex. n’est pas capable de fonctionner à la même vitesse, ne peut pas produire la sortie dans l’exacte forme désirée, etc.
  • 25. 25 Différents niveaux de spécif et cycle de développement  Nous pouvons effectuer des V&V et du test entre tous les niveaux Spec d’exigences (langue naturelle, notation logique) Spécification du comportement Spécification de l’implantation (comportement utilisant des composantes données) Implantation
  • 26. 26 Spécification d’exigences ou besoins  Ce que le système doit faire pour l’usager,  les exigences peuvent être à plusieurs niveaux d’abstraction, peuvent représenter différents aspects du système  Nombreuses méthodes de spec développés, p.ex.  Use Cases (UML)  Notations logiques  Diagrammes de transitions d’états…
  • 27. 27 Spécification du comportement  Décrit le comportement du système en termes de séquences d’interactions possibles avec l’environnement  Les modèles à états sont les plus souvent utilisés, p.ex.  au début, le système et dans l’état inactif,  ceci rend possible une transition signalisation, par laquelle le système passe à un état attente  puis il passe à l’état signal occupé  La structure interne de la spec est abstraite, ne correspond pas à un modèle d’implantation
  • 28. 28 Spécification de l’implantation  Semblable à la spec du comportement  Mais la spec a une structure interne qui correspond à un modèle d’implantation  Décrit les composantes de l’implantation, etc.
  • 29. 29 Vérification et test  La vérification est une technique dont le rôle est de s’assurer qu’un système corresponde aux exigences  Une distinction plus fine est entre  Validation: la fonctionnalité du système correspond-elle aux exigences de l’usager?  Vérification: le système, fonctionne-t-il bien?  Dont l’acronyme V&V  Test: processus de détection de fautes par exécution et comparaison des résultats avec les exigences
  • 30. 30 Validation et vérification  Conformité aux exigences : système |= spécification  Validation : do we build the right product ?  Vérification : do we build the product right ?  En pratique :  examen du code par une équipe indépendante  test (en général ad hoc)  Vérification en fin de conception  irréaliste : il n'y a pas de spécification complète  infaisable : outils de vérification pas assez puissants  inutile : erreurs détectées trop tard  intégrer V & V dans la conception
  • 31. 31 Techniques de vérification  Vérification déductive  règles de preuve associées aux instructions du programme  vérification suivant la structure syntaxique  mécanisation : assistants de preuve, démonstrateurs de théorèmes  Vérification sémantique (model checking)  méthode algorithmique de vérification  exploration exhaustive de l'espace d‘états du modèle  domaine d'application : hardware, protocoles de communication,.  vérification de propriétés ou d‘équivalences entre modèles  Pre-requis  sémantique (opérationnelle ou axiomatique) des systèmes langage de spécification
  • 32. 32 Techniques de validation  Simulation  exécution d'un modèle du système  prototypage, discussion avec le client  Test  appliquer des stimuli à l'implémentation du système  Établir la conformité à l'objectif de test  white box : structure interne du système connue  black box : on ne connaît que l'interface du système  montre la présence d'erreurs, jamais leur absence (Dijkstra)  Standardisation : ISO-ITU-T 96  génération de cas de test (use case) pour l'objectif visé  sélection d'un sous-ensemble représentatif  implantation des cas de test  exécution avec le logiciel test  analyse des résultats
  • 33. 33 Cycle de vie du système de télécommunication Étude préalable de besoin Spécification Conception générale Implémentation : Spécification logicielle Conception préliminaire Conception détaillée et Génération du code Tests d'intégration (cible) Déboguage Tests unitaires Tests d'intégration (hôte) Tests fonctionnels Exploitation maintenance
  • 34. 34 Spécifications des protocoles  Les spécifications de protocole consiste à  préciser l’ensemble des objectifs à réaliser par la mise en œuvre pratique  définir le comportement requis pour une entité de protocole
  • 35. 35 Spécifications des protocoles  la nature des spécifications de protocole a une influence forte sur le test du protocole  test de conformité : moyen d’assurer la satisfaction de l’implémentation du protocole aux besoins  Les systèmes de protocole ne sont pas des systèmes logiciels traditionnels, mais une variante du logiciel  Les systèmes traditionnels se composent des fonctions qui partent d'un état initial vers un état final  ces systèmes s'appellent transformationnels parce qu'ils transforment un premier état à un état final  les exemples typiques : fabrication, traitements des données différés, progiciels Progiciel :Logiciel d'application paramétrable, destiné à la réalisation de diverses tâches.
  • 36. 36 Spécifications des protocoles  Les systèmes réactifs peuvent ne jamais se terminer  le but d'exploiter les systèmes réactifs est de maintenir l'interaction avec l'environnement système  un système réactif ne peut pas être spécifier en se référant seulement à ses états initiaux et finals, mais plutôt à son comportement continu  les exemples typiques sont les logiciels d'exploitation, les systèmes de contrôle de processus, et les systèmes de protocole de communication
  • 37. 37 Spécifications des protocoles Système de protocole de communication = système réactifs   Techniques de description formelles :  réseaux de Pétri, grammaires formelles, langages de programmation à haut niveau, algèbres de processus, types de données abstraits, et logique temporelle,  Les Machine à État fini (MEF) ont été souvent étendues par l'addition des paramètres et des attributs de données afin de traiter naturellement certaines propriétés des protocoles par exemple numérotation des séquences et adressage
  • 38. 38 Introduction à SDL SDL : Specification and Description Language
  • 39. 39 Développement  Au début SDL n’était qu’un simple formalisme graphique pour spécifier les machines à états finis des protocoles téléphoniques  En 1984, on ajouta les processus et les données  SDL 1988 vit une stabilisation sur laquelle on a bâti ultérieurement  En 1992 on ajouta l’orientation objet  En 1996 on ajouta  ASN.1, une notation pour la spec des structures de données  et les Message Sequence Charts • Aujourd’hui SDL et MSC sont deux notations intégrées  Nous avons couramment un effort d’intégration de SDL dans UML
  • 40. 40 Brève intro à l’SDL  L’SDL est essentiellement graphique, même si une notation textuelle existe  Deux éléments primaires:  Structure • Identifie les différentes composantes du système, et les voies de communication • Composantes: Blocks, Processes • Communication: • Channels (entre blocs): communication qui prend du temps • Signal routes (dans un bloc): communication instantanée • Les points de connexion: Gates  Behaviour - Comportement • Seulement les processus ont un comportement • Basé sur le modèle des machines à états finis étendues
  • 41. 41 Structure à haut niveau Block_1 Block_2 Example de system SDL canal environnement path toEnv1 toEnv2 [m2] [m3] [m1] [m4] bloc nom de canal signaux en sortie signaux en entrée Signaux permis dans ce canal
  • 42. 42 Déclarations de signaux (dans un système ou bloc ou processus) SIGNAL m1, m2, m3(INTEGER), m4, m5; paramètres
  • 43. 43 Dans un Bloc  un système est composé de blocs, les blocs sont composés de processus Block Block_1 nom de bloc Process_1 Process_2 [m1] [m4] [m5] signal route processus sr1 sr2 sr3 nom de signal route SIGNAL m5;
  • 44. 44 Processus  À moins de spécification explicite, une instance d’un processus est créée à l’amorçage du système, et continuera jusqu’à ce que le processus décide de se terminer  Chaque processus reçoit (automatiquement par le système) son propre Process Identifier ou PID  Les processus peuvent être créés dynamiquement: P(1,3) No d’instances à l’initialisation P(0, ) No max d’instances No illimité d’instances
  • 46. 46 Intérieur d’un Block Type Block Type aType block type name Process_3 Process_4 [m4] [m1] [m5] gate reference gate sr4 sr5 sr6 gate name g1 g2 [m4] [m1] [m4] Signaux permis à travers porte g2 [m4] g1
  • 48. 48 Signal List pour abréger les listes SIGNAL m1, m2, m3(INTEGER), m4; SIGNALLIST list1 m1, m2, m3, m4; Example3 signal list name Block_b [(list1)] Utilisation de signal list
  • 49. 49 Détails  Les blocs peuvent contenir des sous-blocs ou aussi des processus  Les déclarations de signaux, listes de signaux, etc., peuvent être à tous les niveaux  Encourage la bonne pratique de faire les déclarations au niveau le plus interne
  • 50. 50 Behaviour, Comportement  Seulement les processus peuvent avoir un comportement  Le comportement définit une machine à états finis étendue (MEFE)  Modèle:  Chaque processus a une (et seulement une) file d’entrée à travers laquelle il peut recevoir des signaux  Cette file est infinie théoriquement, mais finie en pratique  Signaux de sources différentes sont ajoutés à la même file à leur arrivée • Tandis que dans le modèle MEFC (Chap. 4) il y a un canal pour chaque paire de processus communicants  Quand un signal en tête d’une file d’entrée d’un processus est égal au signal d’entrée qui cause une transition d’état possible pour l’état courant du processus, cette transition est effectuée et le signal est enlevé de la file
  • 51. 51 Communication entre processus P1 P2 P3 … Chaque proc a sa propre file d’entrée, une seule Un proc peut insérer des signaux dans sa propre file
  • 52. 52 Transitions d’états en SDL  En principe, le modèle d’automate de SDL est le modèle Mealy:  Cependant ce modèle a été élargi en SDL.  Les transitions peuvent être des programmes de complexité arbitraire entrée / sortie
  • 53. 53 Transitions en SDL  Une transition contient une entrée au début  Sauf pour le cas de garde… (à voir)  Et peut contenir 0 ou plusieurs sorties  Même une boucle de sorties…
  • 54. 54 SDL Behaviour-Comportement state1 m5 m2 state2 état entrée m4 m4 state3 prochain état Process p1 state1 état initial sortie Observez les symboles pour les entrées, les sorties, et les états
  • 55. 55 Variables  Les déclarations sont séparées par des virgules, à la fin de toutes il y a un ; DCL v1 INTEGER, v2 PID, v3 BIT, v4 OCTET, v5 DURATION; Identificateur de proc Pour la minuterie 0 ou 1 huit bits Nom de variable Type de variable: entier
  • 57. 57 Mécanismes d’interaction et transitions  Si à un moment donné la file d’entrée n’est pas vide, le premier signal est enlevé  S’il y a une transition correspondante, elle est exécutée  Sinon le message est écarté, à moins que… (save!)
  • 58. 58 SAVE Dans cet exemple, le signal C est remis dans le canal. Si p.ex. il y a un signal A après le C, la transition A est effectuée mais C reste dans le canal. Malheureusement, la manière dans laquelle cette fonctionnalité est censée fonctionner n’est pas définie dans la norme et elle est laissée à l’implémentation Questions possibles, pas résolues dans la norme :  Dans quelle position du canal est-il mis? Au début ou à la fin?  Sera-t-il encore disponible si le prochain état aussi ne peu pas l’utiliser? save http://sdl-forum.org/sdl88tutorial/4/semantics_of_the_communication.htm
  • 59. 59 Variables PID  Chaque signal d’entrée porte automatiquement le PID du proc qui l’a envoyé  Chaque processus a une var prédéfinie SENDER  Quand un signal d’entrée est reçu, la valeur du PID de l’envoyeur est affecté à SENDER  Autres PIDs prédéfinis:  SELF: le PID de ce processus  PARENT: le processus qui a créé ce processus  OFFSPRING: le processus le plus récemment créé par ce processus  Les PIDs sont générés automatiquement par le système d’exécution, donc l’usager pourrait avoir quelques difficultés à les reconnaître…
  • 60. 60 Gardes state1 m3 state2 m4 m1 state3 x = 5 x < 0 Nous venons ici s’il n’y a pas d’entrée appropriée pour l’état et la cond est vraie DCL x INTEGER; Condition garde Si condition vraie on vient ici
  • 61. 61 Fonctionnement des transitions avec gardes  On contrôle la file d’entrée  S’il y a un signal approprié dans la file d’entrée, on suit la transition pour ce signal  Si la file est vide ou il n’y a pas de signal attendu, mais la garde est vraie, on suit la transition de la garde
  • 62. 62 Minuterie  Actions avec minuterie  SET: Une minuterie est amorcée avec une valeur • Le langage ne spécifie pas les unités de temps • Défaut outil Tau: millisecondes  RESET: Annule une minuterie déjà amorcée  EXPIRY: Notification que la minuterie est déclenchée • Résultat: un message d’expiration avec un nom qui est celui de la minuterie est mis dans la file d’entrée du processus (!) • Ceci veut dire que une temporisation pourra être reçue quelque temps après
  • 63. 63 Minuteries, timers set(now+5.0,t1) Amorce minuterie t1 Temporisation 5.0 “unités de temps” de maintenant state1 t1 m2 reset(t1) TIMER t1; Rec. message d’expiration de t1 Annulation de minuterie Déclaration de t1
  • 64. 64 SDL Process with Timers and Queues SDL Process Input Queue (per process) Timer Synchronize with global time Get value of NOW Ask for value of NOW Send signal to another process Get signal from another process (queue always open) Place timer signal into the queue Remove timer signal from the queue Timer signal consumed by SDL process (can deactivate) SET, RESET Ready to consume a signal Send signal to process as soon as have one Modified FIFO RESET – remove from queue and de-activate (stop counting) SET – RESET and activate (start counting) 3 states of a timer - active - inactive - timer signal in queue current time
  • 65. 65 Programmer les transitions  Une transition, causée par une entrée du canal ou une garde, peut contenir un programme entier, impliquant 0 ou plusieurs sorties en positions différentes  Pour programmer ces transitions, plusieurs éléments sont fournis, correspondant aux bien connus organigrammes (flow-charts)
  • 66. 66 Exemples d’éléments qui peuvent être utilisés dans une transition x := 0 Affectation de variables Prcd_name Appel de procédures Prcs_name Création d’instance de processus Terminaison de processus
  • 67. 67 Décisions  Opérateurs: <, <=, >, >=, =, /= x = 3 true false x =2 = 1 else variable conditions Condition logique
  • 68. 68 Entrée/sortie de signaux  Options pour les sorties des signaux:  Le signal est envoyé sur la route spécifiée  Le signal est envoyé au processus spécifié m3 VIA signal_route_name m3 TO process_id
  • 69. 69 Environnement L’environnement est connecté au système comme un autre processus L’environnement est supposé savoir quels messages à envoyer à un moment donné, sinon ils seront écartés
  • 72. 72 Introduction à MSC  Langage graphique et textuel pour spécifier les séquences d’événements dans un système  semblable aux Diagrammes de séquence de l’UML  La notation par laquelle les scénarios d’un système SDL sont présentés  Deux parties:  MSC réguliers • montrent directement les messages possibles  MSC haut niveau (HLMSC) • montrent la corrélation entre MSC réguliers
  • 73. 73 Diagrammes de séquences (Message Sequence Charts MSC)  Décrivent les protocoles de manière visuelle  communications et interactions  Expriment des scénarios positifs/négatifs entre processus concurrents.  Utilisés au début du cycle de développement  abstraction des données, etc...  Standard de la norme Z.120 de l'ITU (CCITT), utilisés dans UML (Unified Modeling Language).  La visualisation de la trace du message est choisi d’une manière simple et intuitive
  • 74. 74 Diagrammes de séquences (Message Sequence Charts MSC)  Pour la spécification du transfert des fichiers  Frontières des interfaces, commande séquentielle des messages, temporisateurs etc...  Chaque diagramme MSC représente un scénario d'un échange typique ou exceptionnel des messages entre les entités du système
  • 75. 75 MSC for B-ISDN (outgoing call)
  • 76. 76 Message Sequence Graphs (MSG)  Un MSG est un graphe, dont les noeuds sont étiquetés par des MSC.  Le MSG décrit une spécification comme un ensemble (éventuellement infini) de MSC, correspondant aux chemins acceptants du graphe.  Lors des branchements, les choix locaux des processus doivent respecter le contrôle global donné par l'étiquette d'un noeud.
  • 79. 79 SDL : Specification and Description Language  MSC et SDL décrivent le même comportement avec deux perspectives différentes  SDL montre comment se comporte chaque entité communicante, alors que les diagrammes MSC montrent comment ils interagissent l'un sur l'autre en échangeant des messages  Avec des spécifications des systèmes de communication complexes  Structure (architecture) des systèmes • faire coopérer des parties ( systèmes, blocs, processus)  Communications avec l'environnement et dans le système • Canaux comme chemins de communications • Signaux comme les messages transférés à travers le canal  Comportement dynamique de chaque pièce basé sur des machines d'état