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 protocolesProcessus de conception des protocolesSpécification des protocolesTest 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écifet 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 logicielleConception préliminaireConception détaillée etGénération du code

Tests d'intégration (cible)

DéboguageTests unitairesTests d'intégration (hôte)

Tests fonctionnels

Exploitationmaintenance

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 permisdans 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

SIGNALm5;

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

g2g1g2

aType

block type block instances

typeofinstancegate

references

46

Intérieur d’un Block Type

Block Type aType

block type name

Process_3

Process_4

[m4]

[m1]

[m5]gatereference

gate

sr4

sr5

sr6

gate name

g1

g2

[m4]

[m1]

[m4]

Signaux permis à travers porte

g2

[m4]

g1

47

Process Types

P_typeSymbol:

P1: P_typeInstance:

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 designal 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 niveauxEncourage 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ébutSauf pour le cas de garde… (à voir)

Et peut contenir 0 ou plusieurs sortiesMê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

SAVEDans 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émentationQuestions 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

MinuterieActions 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 t1Temporisation 5.0 “unités de temps” de maintenant

state1

t1 m2

reset(t1)

TIMER t1;

Rec. message d’expiration de t1Annulation de minuterie

Déclaration de t1

64

SDL Process with Timers and Queues

SDL Process

Input Queue (per process)

Timer

Synchronize withglobal time

Get valueof NOW

Ask for valueof NOW

Send signal to another process

Get signal fromanother 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 processas soon as have one

ModifiedFIFO

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 queuecurrent 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 = 3true

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