RAPPORT UML

Projet Midihaou

Projet Base de données XML sur le net proposé par Jean-Luc Massat

Etudiant : Athlan Bertil, Barrau Julien, Choron Emilie, Giraud Nicolas

Law-Weng-Sam Frédéric, Li Junhua, Sery Didier

1/29
Table des matières
1 Diagramme de cas d'utilisation.........................................................................................................3
1.1 Utilisateur non authentifié........................................................................................................ 3
1.2 Utilisateur authentifié............................................................................................................... 4
1.3 Gestionnaire de collection........................................................................................................ 5
1.4 Administrateur.......................................................................................................................... 6
2 Diagramme de séquence...................................................................................................................7
2.1 Authentification........................................................................................................................ 7
2.2 Création de document............................................................................................................... 8
2.3 Validation des documents......................................................................................................... 9
2.4 Génération de CSS..................................................................................................................10
3 Diagramme états-transitions........................................................................................................... 11
3.1 Démarrage et arrêt de l'application......................................................................................... 11
3.2 Requête d'affichage des documents........................................................................................ 11
3.3 Requête de modification de document....................................................................................12
3.4 Création d'un schéma..............................................................................................................13
3.5 Requête de demande............................................................................................................... 14
3.6 Validation de l'ensemble des documents.................................................................................15
3.7 Publication.............................................................................................................................. 16
3.8 Génération de CSS.................................................................................................................17
4 Diagramme de navigation...............................................................................................................18
4.1 Navigation utilisateur..............................................................................................................18
4.2 Navigation gestionnaire de collection.....................................................................................19
4.3 Navigation administrateur.......................................................................................................19
5 Diagramme de classe......................................................................................................................20
5.1 Beans persistés........................................................................................................................20
5.2 La couche de stockage (DAO)................................................................................................21
5.3 La couche métier (business)................................................................................................... 22
5.3.1 Manipulation des données...............................................................................................22
5.3.2 Publication des documents..............................................................................................25
5.3.3 Validation des documents................................................................................................25
5.4 Couche vue (View) + Couche Contrôleur (Control)..............................................................26
5.5 Architecture générale.............................................................................................................. 27
5.6 Architecture View/Control......................................................................................................28
6 Diagramme de déploiement............................................................................................................29
7 Génération du code.........................................................................................................................29

2/29
1 Diagramme de cas d'utilisation

Il s'agit de la solution UML pour représenter le modèle conceptuel.

Les cas d'utilisation permettent de structurer les besoins des utilisateurs et les objectifs
correspondants d'un système.

Ils identifient les utilisateurs du système (acteurs) et leur interaction avec le système.

Ils permettent de classer les acteurs et structurer les objectifs du système.

Les différents acteurs :

Dans notre application, nous avons définis plusieurs types d'utilisateurs qui ont des droits et
des fonctionnalités qui leurs sont propres. C'est pourquoi nous avons quatre diagrammes de cas
d'utilisation, un pour chaque type d'utilisateur.

1.1 Utilisateur non authentifié

Utilisateur non authentifié

Nous pouvons remarquer que ce type d'utilisateur (non authentifié) a accès à l'application et
peut néanmoins consulter certains documents. Ceux-ci doivent avoir un «status» public.

3/29
 1.2 Utilisateur authentifié

Utilisateur authentifié

Un utilisateur s'authentifie comme document (les données d'authentification appartiennent à

un document). Ce qui implique qu'un utilisateur possède obligatoirement au moins un document
dans notre CMS. Il a donc la possibilité de modifier ce document, aisni que ceux dont il est le
propriétaire.

Pour toute autre action sur un document que la modification du contenu l'utilisateur doit
effectuer une demande soit au gestionnaire de la collection soit à l'administrateur

4/29
 1.3 Gestionnaire de collection

Gestionnaire de collection

Le gestionnaire de collection a tous les droits sur les documents de sa collection (création,
suppression, modification) et peut également changer les caractériques de celle-ci.

Il est à noter que le gestionnaire de collection peut «publier la collection», c'est à dire que les
documents sont mis en ligne et donc accessibles par tout le monde.

5/29
 1.4 Administrateur

Administrateur
L 'administrateur a tous les droits sur les collections et les documents du CMS. De plus il est
le seul à pouvoir agir sur les schémas.

6/29
2 Diagramme de séquence

Les diagrammes de séquences permettent de représenter des collaborations entre objets

selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages.
Les diagrammes de séquences peuvent servir à illustrer un cas d'utilisation.
Nous avons définis trois différents acteurs:
– l'utilisateur :
– le serveur
– SGBDR

Nos diagrammes de séquence reprennent les cas d'utilisations que nous avons jugés judiceux
de représenter ainsi.

2.1 Authentification

Authentification

L'authentification se fait lorsque la base de données renvoie un couple login / password

correspondant aux informations entrées par l'utilisateur.

7/29
 2.2 Création de document

Création de document

La création d'un document se fait premièrement par la création d'un document vide et ce
dernier sera rempli par la suite.

Ce remplissage est réalisé grâce à un formulaire conforme au schéma de la collection. C'est

pourquoi une requête afin d'obtenir ce schéma est indispensable.

8/29
 2.3 Validation des documents

Validation des documents

La validation de tous les documents est exécutée en parcourant la hiérarchie de notre CMS
de manière récursive. C'est à dire qu'on valide chaque document de chacune des collections de tous
les schémas.
Dès lors que l'application a testé la validité, elle met à jour la donnée du document qui donne
son état de validité.

9/29
 2.4 Génération de CSS

Génération de CSS

On change de manière dynamique la feuille de style CSS car chaque modification est
visible au fur et à mesure.

10/29
3 Diagramme états-transitions

Les diagrammes d'états-transitions permettent de décrire les changements d'états d'un objet
ou d'un composant, en réponse aux interactions avec d'autres objets/composants ou avec des
acteurs.
Une transition est déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un événement
qui conditionne la transition.

Notre application étant un serveur web les actions sont déclenchées par des requêtes.

3.1 Démarrage et arrêt de l'application

Démarrage et arrêt de l'application

Ce serveur se trouve alors en attente de ses requêtes dès sa mise en service et jusqu'à son
extinction.

3.2 Requête d'affichage des documents

Requête d'affichage des documents

11/29
 3.3 Requête de modification de document

Requête de modification de document

Lorsqu'un document est modifié l'application vérifie sa validité. A ce moment, dans le cas où
le document est invalide, un message prévient l'utilisateur qui a le choix de sauvegarder malgrés
tout son document ou de revenir à l'état d'édition si il juge nécessaire de rendre son document
valide.

12/29
3.4 Création d'un schéma

Création d'un schéma

13/29
 3.5 Requête de demande

Requête de demande

L'envoie de message se fait par un mail au gestionnaire de la collection si il y en a un. Sinon

le mail ira directement à l'administrateur.

14/29
 3.6 Validation de l'ensemble des documents

Validation de l'ensemble des documents

Lorsqu'un document est invalide un mail est envoyé au propriétaire lui signifiant l'état de
son document ainsi que l'ensemble des incompatibilités avec le schéma. De plus ce document est
ajouté à une liste de documents invalides qui sera retourné à l'administrateur à la fin de cette phase
de validation.

15/29
 3.7 Publication

Publication

Cette requête est lancé pas le gestionnaire lorsqu'il veut mettre en ligne l'ensemble des
documents de sa collection. Les pages webs permettant de mettre en forme les documents destinés à
la publication par l'application d'une feuille de style sont générées et déposées sur un serveur HTTP.

16/29
 3.8 Génération de CSS

Génération de CSS

Un fichier html est généré à partir du schéma, afin de visualiser le changement des
paramètres de la feuille de style. Ces paramètres sont modifiés grâce à un formulaire.

Lorsque l'utilisateur estime que la mise en page est conforme à ses désirs la feuille de style
est créée ou modifiée.

17/29
4 Diagramme de navigation

Bien que ce diagramme ne fasse pas parti des diagrammes UML de base, nous avons préféré
en réaliser quelques uns. Une application web consiste en de nombreuses pages liées entre elles et
ce diagramme nous a permis de clarifier la navigation et l'interface qui doivent être implémentées.

4.1 Navigation utilisateur

18/29
4.2 Navigation gestionnaire de collection

4.3 Navigation administrateur

19/29
5 Diagramme de classe
Nous avons organisé l'application en quatre couches distinctes plus un ensemble de classes
représentant les données de la base.
Chaque couche inférieure propose des interfaces qui devront être utilisées par la couche
supérieure afin d'introduire une inversion des dépendances et ainsi assurer la bonne séparation des
couches.

5.1 Beans persistés

Les classes Document et InternalDocument représentent les documents gérés par le CMS.
La propriété content de Document contient les données sous forme XML.

20/29
 5.2 La couche de stockage (DAO)
Cette couche regroupe les méthodes spécifiques à la base de données et au framework ORM
utilisé.

21/29
 5.3 La couche métier (business)
La couche métier peut être vue comme un distributeur de service. Elle va principalement
faire appel à la couche DAO pour produire et effectuer les traitements sur les structures de données
manipulées par l'application.
Elle est composée de différents packages qui regroupent les classes en fonction des types de
traitements qu'elles proposent.

5.3.1 Manipulation des données

22/29
23/29
L'interface Auth est destinée à être implémentée par les modules d'authentification externe.

24/29
 5.3.2 Publication des documents

Toujours dans l'optique service, cette couche va produire les documents HTML à destination
du front-office.

5.3.3 Validation des documents

25/29
 5.4 Couche vue (View) + Couche Contrôleur (Control)
La couche vue permet d'effectuer les traitements liés à l'affichage comme la génération des
formulaires dynamiques. Derrière chaque vue on trouve une classe Control qui va intercepter les
actions de la vue pour aiguiller. On se retrouve donc avec un modèle MVC derrière chaque page de
l'application.

26/29
5.5 Architecture générale

27/29
 Ce diagramme montre l'empilement des différentes couches et les objets qu'elles utilisent
pour s'interfacer.

5.6 Architecture View/Control

28/29
6 Diagramme de déploiement

7 Génération du code
Pour réaliser la majorité des diagrammes nous avons utilisé Poséidon. Nous avons donc
utiliser sa faculté à générer le code java correspondant afin de mettre en place le squelette de
l'application. Ceci nous a aidé dans la répartition des taches au niveau du développement.
Le code directement généré correspondait à nos attentes sauf pour certain type tel que les
tableaux d'objets, les enum et les types DOM4J.

29/29