cahier des charges

CAHIER DES CHARGES
. Projet : TER Fractal TV
. Date : 6 avril 2005
. Version : 1.5
. Encadrant :
Philippe Collet
. Auteurs :
NICOLAS Yohann
BARBIER Thomas
CASTILLEJOS Nicolas
SAUVAN Bastien
SALAGEANU Emil
. Changements clés depuis la dernière version :
- Mise en page et correction orthographique.
-1-
I . Introduction
I.1 Résumé
Fractal TV est un projet visant à développer un prototype client/serveur d’échange
de fichiers vidéos à l’aide de la plate-forme de composant Fractal et de l’API Java Media
Framework.
L’architecture du prototype sera de type 1-N , un unique serveur et N clients qui
se connecteront au serveur par l’intermédiaire de RMI (Remote Method Invocation) .
Le serveur fourni un ensemble de vidéos ou des captures (Webcam par exemple)
qu’ il peut envoyer ou diffuser à la demande des clients (téléchargement ou streaming
grâce au protocole RTP).
Le serveur pourra également :
- négocier la qualité de la vidéo en fonction de sa charge
- mettre un fichier indisponible si cette même charge est trop élevée
Le client sera portable (PC/Windows, PC/Linux, PocketPC/Windows Mobile), il
gérera essentiellement :
- Le paramétrage et la lecture des vidéos
- Le choix du type de diffusion
- La qualité de la vidéo en fonction de sa bande passante disponible
- Savoir lire les vidéos en fonction des codecs dont il dispose
Grâce à la plate-forme Fractal, le client pourra éventuellement changer (connecter
et déconnecter) des composants dynamiquement, renoncer éventuellement à certains
selon les capacités de la machine sur laquelle il tourne.
I.2 Existant
. La Plateforme de composants Fractal développé par ObjectWeb
. La Java Media Framework (JMF) de Sun
. Le projet DESS Telecom Fractal-RTP :
Projet de type client/serveur sous la plate-forme Fractal qui utilise JMF dont
on pourrait réutiliser des composants fractal dans notre prototype.
. Un projet des étudiants de l'ESSI en cours de réalisation dans le but d’améliorer
les performances sur Pocket PC (type IPAQ)
-2-
I.3 Fournitures
Voici une liste de tout ce qui sera livré :
- Le prototype du serveur de fichiers vidéos
- Le prototype du client
- La documentation (sous forme de Javadoc)
- Manuel utilisateur
I.4 Définitions et Acronymes
Streaming : Technique de transfert de données multimédia en un flux (Stream)
régulier et continu. Ceci permet de lire sur Internet un contenu audio-vidéo au fur et à
mesure de son téléchargement en direct ou en différé.
Fractal : Fractal est une plate-forme de composants modulable et extensible
permettant entre autres de concevoir, implémenter et de reconfigurer à chaud
différents systèmes ou applications.
JMF : La Java Media Framework est une bibliothèque de développement fournie
par Sun permettant d'utiliser les fonctionnalités multimédias standard. Elle offre de
nombreuses classes utiles pour le traitement audio et vidéo, mais aussi la gestion du
protocole Real Time Protocole (RTP) pour la diffusion de flux.
RMI : La Remote Method Invocation est une API Java permettant de manipuler
des objets distants (C'est-à-dire un objet instancié sur une autre machine virtuelle,
éventuellement sur une autre machine du réseau) de manière transparente pour
l'utilisateur, c'est à dire de la même façon que si l’objet était sur la machine virtuelle
(JVM) de la machine locale.
Ainsi un serveur permet à un client d'invoquer des méthodes à distance sur un objet
qu'il instancie. Deux machines virtuelles sont donc nécessaires (une sur le serveur et
une sur le client) et l'ensemble des communications se fait en Java.
-3-
II . Organisation du Projet
II.1 Processus
Nous avons choisi de développer notre prototype de manière incrémentale dans le
but de toujours garder autant que possible une version « opérationnelle » de notre travail
et d’en améliorer les fonctionnalités, la fiabilité et la robustesse tout au long de
l’avancement du projet.
La méthode incrémentale permet également un développement plus sécurisé face
à des problèmes éventuels et d'avoir une succession de prototypes se rapprochant de
l'application finale.
II.2 Organisation Structurelle
Jusqu’à aujourd’hui, nous avons appris à nous familiariser avec les technologies
requises par le projet, ainsi nous avons tous fait différents essais, que cela soit avec
Fractal ou la JMF. Tous les membres de l’équipe ont écrit une petite application
client/serveur basée sur Fractal (et/ou Fractal RMI) dans le but de mieux aborder le
principe de la programmation par composants. Nous avons également effectué quelques
essais avec la JMF (création d’un petit lecteur vidéo par exemple).
Lors d’une réunion avec notre encadrant de projet, nous avons suggéré
d’implémenter un petit prototype ayant des fonctionnalités très restreintes et encore sous
forme de classe Java.
Voici la répartition des tâches dans l’équipe pour ce travail :
- NICOLAS Yohann & CASTILLEJOS Nicolas pour la partie RTP de
l’application
- BARBIER Thomas pour le téléchargement de fichier
- SALAGEANU Emil & SAUVAN Bastien pour la partie RMI
Ce petit prototype est expliqué plus en détail dans ce document.
Pour la suite du développement, nous allons nous baser sur le prototype dont nous
disposons maintenant et le faire grandir.
Tout d’abord, nous allons « Fractaliser » chaque partie de notre application, c'està-dire créer des composants de haut niveau à partir de nos classes Java. Chacun gérant la
partie dont il s’était déjà acquitté jusque là.
Par la suite, nous affinerons l’architecture en descendant vers des composants de
plus en plus précis tout en améliorant les fonctionnalités de chacune de nos parties
respectives. Pendant ce temps, Nicolas se concentrera sur le déploiement sur Pocket PC .
Et enfin, tous les membres de l’équipe concentreront leur travail sur le
déploiement de l’application sur tous les supports et sur les tests .
-4-
II.3 Limites et Interfaces
Les interfaces :
Le serveur scannera périodiquement un répertoire contenant les vidéos et
proposera les fichiers dont il dispose aux clients.
Le manager du serveur pourra ajouter des vidéos au répertoire défini comme étant
répertoire « partagé » accessible aux clients.
Le client disposera d'une interface graphique. Il précisera obligatoirement le port
et le nom (Ou adresse IP) du serveur afin de s'y connecter.
Il pourra récupérer la liste des fichiers disponibles et choisir d'en lire un en
streaming ou de le télécharger pour pouvoir le visualiser par la suite en local.
Les limites :
Le serveur ne disposera d’aucune interface graphique pour son utilisateur.
Dans le cas du Pocket PC, seul les fichiers .mpeg et .mov seront gérés dans un
premier temps, l’ajout de formats compatibles pourra être possible selon l’état de
l’avancement du projet et de la qualité de l’ensemble du prototype .
III . Gestion
III.1 Objectifs et priorités
Notre objectif principal est d’avant tout fournir au client un prototype fonctionnel
dont les deux qualités fondamentales seraient, d’une part d’avoir un client portable sur les
Systèmes déjà cités et d’autre part la possibilité de pouvoir réutiliser le code.
Nous allons donc mettre l’accent sur les points suivants :
- Prototype minimal permettant 2 modes d'utilisations clients :
. Lecture du fichier distant (rtp / streaming).
. Téléchargement du fichier sur la machine du client puis
éventuellement lecture en local.
- Portabilité du code source (utilisation du jdk1.3 de Sun pour rester
compatible avec le Pocket PC, le reste de la portabilité sera assurée par l’utilisation du
langage Java)
- Assurer une certaine évolutivité à notre prototype de sorte que l’ajout de
formats vidéo supportés puisse être aisé ou encore de pouvoir ajouter des fonctionnalités
ultérieurement de manière simple et efficace (Sans changer le code déjà existant).
- Permettre le test de charge du serveur et négocier en fonction de cette
donnée la qualité de la vidéo diffusée.
-5-
III.2 Hypothèse, dépendances, contraintes
Hypothèse :
On utilisera AWT et pas SWING afin de conserver la compatibilité avec les
Pocket PC.
La JVM J9 de IBM pour Pocket PC est opérationnelle et nous permettra de
réaliser nos besoins.
Dépendances :
La gestion des codecs sur pocketPC dépend d'un projet des étudiants de l'ESSI,
ils restent des incertitudes sur sa sortie et même sur son utilisation possible.
La réutilisation du projet DESS Telecom pourrait fournir des composants fractal
intégrables à l'application sous réserve de compréhension du code, sa réutilisation n’est
pas certaine mais permettra de toute façon d’enlever certaines ambiguïtés.
Contraintes :
Le projet devra être développé en Java (Jdk1.3 pour compatibilité Pocket PC).
L’utilisation de la plate-forme de composant Fractal est imposée par les besoins
du client.
III.3 Gestion du risque
Le Pocket PC est un point dangereux de notre projet, le déploiement sur ce type
d'architecture est très fastidieux et pourrait nous obliger à renoncer à une version
compatible, livrable dans les temps avec notre prototype.
Le projet se basant sur des technologies différentes, l'assemblage est difficile à
mettre en place d’où notre choix de processus de développement incrémental. Nous
connaissons le coût que peut avoir le rassemblement de ces technologies, nous limitons
ainsi les risques à venir en utilisant ce modèle de développement.
Le projet de l'ESSI pourrait ne pas aboutir ne nous permettant pas de fournir une
version performante de notre application sur Pocket PC.
-6-
III.4 Moyens de contrôle
Pour un confort d’utilisation maximal du côté client, nous devons essayer de gérer
au mieux les points faibles de ce type de projet :
- Utiliser toute la bande passante disponible pour offrir au client une qualité
optimale de la vidéo.
- Exécuter les clients sur les plates-formes différentes afin de s’assurer que
le prototype soit efficace sur chacun des systèmes.
- En utilisant le même mode (Streaming ou téléchargement) sur le même
fichier avec plusieurs clients différents au même moment.
- En utilisant 2 modes différents sur le même fichier avec plusieurs clients
différents au même moment.
- En testant sur différents types de fichiers sur toutes les plates-formes au
même moment.
IV . Technique
IV.1 Méthodes et outils employés
L'ensemble du projet est réalisé en Java avec JBuilder X de Borland.
L’utilisation de Trac pourrait être envisageable dans le cas où un membre de
l’équipe disposerait d’une station de travail sous linux et tournant à plein temps. Trac
contient un serveur subVersion et d’un site wiki qui permet de voir les sources, de placer
des schémas d’architecture et des commentaires.
IV.2 Documentation
L'ensemble de la documentation relative aux API utilisées dans le projet ainsi que
les forums concernant le déploiement et l'utilisation du Pocket PC sont disponibles sur le
site Wiki du projet :
- http://deptinfo.unice.fr/twiki/bin/view/Minfo/TERFRACTALTV
La documentation se présentera dans un premier temps sous la forme d'une
Javadoc. C'est l'unique documentation nécessaire aux programmeurs, le fonctionnement
global de l'application n'intervenant que lors de l'assemblage.
La mise en commun des différentes parties du programme se fera en groupe, la
présence de chaque membre de l'équipe permettra de pouvoir modifier n'importe quel
bout de code afin de pouvoir l'assembler avec le reste du projet.
-7-
V . Calendrier
Notre activité jusqu'à ce jour :
. Découverte des nouvelles technologies nécessaires pour le projet (Multimédia,
programmation par composant (Fractal), déploiement par ADL en XML).
. Conception de quelques applications dans le but de se familiariser avec ces
technologies (Client/serveur échangeant une simple phrase puis en Fractal RMI).
. Développement d'un prototype basique de l'application :
Pour cela, l'application avait été ramenée à 3 clients/serveurs:
. Serveur et client pour le téléchargement de fichiers.
. Serveur et client RTP pour la visualisation des vidéos en streaming.
. Interfaces de communication entre le client et le serveur en Java RMI.
La partie RTP a permis l'initiation au Multimédia et à la diffusion en streaming, il
reste à approfondir ces connaissances pour pouvoir fournir une application la plus fiable
possible.
La partie RMI a permis la consolidation des connaissances dans cette technologie.
La partie téléchargement a permis l'essai des ZipSockets afin de compresser les
données envoyées sur le réseau mais son échec a aboutis à son abandon dans les choix de
conception.
Ce découpage a permis à chacun d'entre nous de travailler sur une partie
Client/Serveur. L'assemblage du prototype plus long que prévu a révélé les problèmes de
déploiement auxquels nous serons confrontés et ont influencé le choix du planning. Une
personne devra superviser l'assemblage et le déploiement du projet tout au long de son
développement.
Notre activité dans les semaines à venir :
A partir des connaissances acquises dans l’expérimentation de ces nouvelles
technologies, nous avons établi un planning prévisionnel où chaque semaine a son
objectif à atteindre toujours dans le but de développer de manière incrémentale.
-8-
PLANNING PREVISIONNEL
Nom
Semaine 1
Semaine 2
Semaine 3
Nicolas Yohann Barbier Thomas
Castillejos
Salageanu
Sauvan Bastien
Nicolas
Emil
Fractalisation et Fractalisation
Fractalisation du Fractalisation de
modifications du Serveur
client RTP
la partie RMI (en
serveur RTP
utilisant toujours
Téléchargement et
assemblage des
Java RMI) et
différentes parties
assemblage
Fractalisation de
la partie RMI (en
utilisant toujours
Java RMI) et
assemblage
Adaptation en
Fractal RMI
Adaptation en
Fractal RMI
Adaptation en
Fractal RMI
Fractalisation en
composant plus
détaillée de la
partie RMI
Fractalisation en
composant plus
détaillée de la
partie RMI
Adaptation en
Fractal RMI
PocketPC et
installation de la
J9
Fractalisation en Fractalisation en PocketPC et
composant plus composant plus installation de la
détaillée RTP
J9
détaillée du
et/ou
serveur RTP +
Déploiement par téléchargement.
(eventuellement
ADL
sur la J9)
Semaine 4
Assemblage,
déploiement et
test
Assemblage,
déploiement et
test
PocketPC et
Assemblage,
installation de la déploiement et
J9 (et/ou
test
déploiement)
Assemblage,
déploiement et
test
Semaine 5
Semaine de
réserve ou on
place les efforts
sur les points
faibles de
l'application.
Semaine de
réserve ou on
place les efforts
sur les points
faibles de
l'application.
Semaine de
réserve ou on
place les efforts
sur les points
faibles de
l'application.
Semaine de
réserve ou on
place les efforts
sur les points
faibles de
l'application.
Semaine de
réserve ou on
place les efforts
sur les points
faibles de
l'application.
Semaine 6
Finitions, rapport,
repérage de bugs
de dernière
minute.
Finitions, rapport,
repérage de bugs
de dernière
minute.
Finitions, rapport,
repérage de bugs
de dernière
minute.
Finitions, rapport,
repérage de bugs
de dernière
minute.
Finitions, rapport,
repérage de bugs
de dernière
minute.
-9-
VI . Fonctionnalités
VI.1 Fonctionnalités côté serveur
- proposition de vidéos :
- vidéos en téléchargement : permet au client de mettre en local
sur son ordinateur le fichier qu’il a demandé.
- vidéos en streaming : permet au client de visionner la vidéo
pendant le téléchargement grâce au protocole RTP.
- ajuster la qualité en fonction de la bande passante disponible
du client.
- test de charge du serveur :
- ajuster la qualité de la vidéo diffusée en fonction de la charge
- interdire l’accès si la charge est trop importante
- tenir a jour une liste de fichiers vidéos disponibles :
- ajouter des fichiers vidéo à la liste
- retirer des fichiers vidéo a la liste
VI .2 Fonctionnalités côté client
- téléchargement de vidéos :
- sélectionner une vidéo parmi la liste de vidéos disponibles
- confirmer transfert du fichier
- visualisation de vidéos :
- visualisation de vidéos par streaming
- sélectionner une vidéo parmi la liste de vidéos
- paramétrer la qualité en fonction de la bande passante
disponible.
- visualisation de vidéos en local
- capture de vidéo : fonctionnalité qui dépendra de l'état dans l'avancement
du projet
- capture de vidéo par l’intermédiaire d’un device approprié
(webcam par exemple)
- diffusion par streaming du flux capturé.
- 10 -
VII . Contraintes non fonctionnelles
VII.1 Plate-forme matérielle
L'application Fractal TV, étant implémentée en Java, pourra fonctionner sur les 2
plates-formes les plus connues, à savoir PC/Windows et PC/Linux.
Elle devra aussi fonctionner sur une plate-forme assez récente : le Pocket PC.
Le logiciel fonctionnera uniquement sur un réseau de vitesse de réception au
moins équivalente à celui de l' ADSL en ce qui concerne le côté client. Il n'est pas étudié
pour fonctionner sur des connexions à faible débit, de type 56k ou autres. En ce qui
concerne le serveur, il devra être sur un réseau possédant une assez grosse vitesse
d'upload pour pouvoir desservir plusieurs clients en même temps. Le nombre de clients
maximal pouvant recevoir de la vidéo en même temps dépendra très fortement du débit
d'upload de la connexion du serveur.
La version de Fractal utilisée sera la version 2.0 avec Java jdk 1.3 pour
compatibilité avec le Pocket PC.
VII.2 Emprunte mémoire
La mémoire des ordinateurs étant de plus en plus importante, les plate-formes PC
ne nécessitent pas une attention particulière sur l'utilisation de la mémoire. Seul la partie
« client » qui devra tournée sur Pocket PC devra se suffire de ses 32/64 voir 128 Mo de
RAM pour les modèles les plus performants.
- 11 -
VII.3 Annexes techniques
Schéma d’architecture
- 12 -