Compléments sur des concepts et des idiomes Java

Compléments sur des concepts et
des idiomes Java
D. Conan
Rev : 951
CSC 4509 — ASR4
Télécom SudParis Juin 2013

Compléments sur des concepts et des idiomes Java
Table des matières
Compléments sur des concepts et des idiomes Java
D. Conan, , Télécom SudParis, CSC 4509 — ASR4
Juin 2013 1
Plan de la présentation 3
1 Contexte : Étude de l’application tchat multiclient et multiserveur 3
2 Architecture de l’application 4
2.1Architecturedesserveurs ....................................... 5
2.2Architecturedesclients ........................................ 6
2.3 Diagramme de classes des serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4Diagrammedeclassesdesclients ................................... 9
3 Types paramétrés 10
4 Objets immuables et collections immuables 11
5 Blocs de code « static » 12
6 Type énuméré et constructeur de type énuméré 13
7 Classes anomymes 14
Télécom SudParis — D. Conan — Juin 2013 — CSC 4509 — ASR4 2

Compléments sur des concepts et des idiomes Java
# 2
'
&
$
%
Plan de la présentation
1 Contexte : Étude de l’application tchat multiclient et multiserveur . . . . . . . . . . . . . . . . . 3
2 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Types paramétrés...............................................................9
4 Objets immuables et collections immuables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 Blocs de code « static »........................................................11
6 Type énuméré et constructeur de type énuméré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7 Classes anomymes.............................................................13
# 3
'
&
$
%
1 Contexte : Étude de l’application tchat multiclient et
multiserveur
■Infrastucture du système de tchat multiclient et multiserveur
♦Réalisé pendant les séances de travail personnel
♦Mise à disposition d’une solution type par l’équipe enseignante
▶Utilisation de concepts avancés et d’idiomes Java
⋆Quelques compléments de cours sont fournis dans cette présentation
■Documentation de référence :
♦Tutoriels Java de Oracle/Sun
♦Livre Effective Java, 2nd edition de Joshua Bloch, Addison Wesley, 2008
▶Ce livre a été traduit en français sous le titre « Java Efficace »
Télécom SudParis — D. Conan — Juin 2013 — CSC 4509 — ASR4 3

Compléments sur des concepts et des idiomes Java
# 4
'
&
$
%
2 Architecture de l’application
Client 4
Client 0 Client 1
Server 1Server 0
Server 3Server 2
Client 2 Client 3
La figure de cette diapositive présente la configuration utilisée dans nos tests avant de vous fournir cette
réalisation de l’application de tchat. Les particularités sont les suivantes :
•test de l’aspect multiclient avec deux clients attachés à certains serveurs,
•test de l’aspect multiserveur avec des serveurs connectés à plusieurs voisins,
•test de la propagation des messages de tchat avec gestion des cycles dans la topologie des serveurs.
Télécom SudParis — D. Conan — Juin 2013 — CSC 4509 — ASR4 4

Compléments sur des concepts et des idiomes Java 2 Architecture de l’application
# 5
'
&
$
%
2.1 Architecture des serveurs
main thread
− infinite loop
− call to select()
and call to the
actions of the
state machine
ChatSelectorMultiServer thread
− infinite loop
− read command lines
to control the server
Access to the state of the server
through ChatServerState.semaphore
La figure de cette diapositive présente l’architecture d’un serveur multiactivité (en anglais, multithread).
L’activité principale du serveur est constituée d’une boucle infinie organisée autour de l’appel à la méthode
select. Une seconde activité est ajoutée pour permettre la saisie de commandes à la console afin de contrôler
le fonctionnement du serveur, par exemple lors des tests pour démarrer ou arrêter un algorithme réparti
entre les serveurs de l’application de tchat. Cette seconde activité est donc une boucle infinie de lecture de
commandes au clavier.
Dans chaque itération de la boucle infinie de l’activité principale, le serveur reçoit soit une demande de
connexion par un client ou un serveur, soit un message d’un client ou d’un serveur, puis le seveur exécute
une action de réaction à cet événement. Cette action modifie l’état du serveur et potentiellement émet des
messages vers des clients et des serveurs. La seconde activité du serveur peut aussi modifier l’état du serveur
et émettre des messages. Donc, l’état du serveur rassemblé dans la classe ChatServerState doit être accédé
en exclusion mutuelle. C’est pourquoi la classe ChatServerState contient un sémaphore qui doit être utilisé
par les deux activités concurrentes du serveur.
Par ailleurs, la forme des boucles de traitement des événements des deux activités du serveur donnent
l’indication de l’orientation naturelle utilisée pour l’insertion d’algorithmes répartis : c’est l’orientation « évé-
nement » présentée dans la section 1.2 du cours d’algorithmique répartie. Ainsi, les algorithmes répartis pré-
sentés selon l’orientation « contrôle » doivent d’abord être traduits dans une forme orientée « événement »
avant d’être insérés dans l’architecture du serveur.
L’orientation « événement » suggère l’utilisation du patron de conception « machine à états ». Aussi,
afin de faciliter l’insertion d’algorithmes répartis dans l’architecture initiale, nous ajoutons un mécanisme de
machine à états. C’est la mise en œuvre de ce patron de conception qui requiert des compléments sur des
concepts et des idiomes Java.
Télécom SudParis — D. Conan — Juin 2013 — CSC 4509 — ASR4 5