Dossier

d’analyse &
d’architecture
EL HIMRI Najat
SECK Maty
KIENE Nicolas
PAULHE Nils

Version 1.0 - 17.12.10

Sommaire
+ Categories
+ Figures
 1. Références // p.00
1.1 Documents
1.2 Glossaire
2. Analyse Fonctionnelle // p.00
2.1 Contexte
2.2 Rôles
2.3 Cas d’utilisation
2.4 Entités participantes auc cas d’utilisation
3. Architecture Fonctionnelle // p.00
3.1 îlots fonctionnels
3.2 Dépendance des îlots fonctionnel
3.3 Données fonctionnelles
4. Analyse Technique // p.00
4.1 Prototypage
4.2 Guide de mise en oeuvre
5. Architecture Technique // p.00
5.1 Noeud d’execution et lien de communication
5.2 Architecture en couches
6. Architecture Applicative // p.00
6.1 Composant applicatif
6.2 Dépendance des composants applicatifs
6.3 Données aplicatives
 1.1 Diagramme de contexte -
2.1 Diagramme de rôles
3.1 Diagramme de cas d’utilisation
4.1 Diagramme des entités participantes
aux cas d’utilisation
5.1 Diagramme de séquences fonctionnelles
5.1 Scénario 1
5.2 Scénario 2
5.3 Scénario 3
5.4 Scénario 4
5.5 Scénario 5
5.6 Scénario 6
6.1 Modèle des îlots fonctionnels
7.1 Modèle des noeuds d’éxecution
8.1 Modèle d’architecture en couches
9.1 Middleware et couches
10.1 Diagramme de séquence applicatives
10.1 Scénario 1
10.2 Scénario 2
10.3 Scénario 3
10.4 Scénario 4
10.5 Scénario 5
10.6 Scénario 6
11.1 Modèle des composants applicatifs
12.1 Modèle des données applicatives
Avant Propos -
Objet du document
Ce document est un dossier d’analyse et d’architecture pour l’Application Imprimerie;
Il présente le fonctionnement de la soumission du document à imprimer jusqu’à la livraison de ce
dernier selon cinq activité du processus de développement :

* l’analyse fonctionnelle
* l’analyse technique
* l’architecture fonctionnelle
* l’architecture technique
* l’architecture applicative

pour la illustration de ces activités on suit un cycle d développement itératif en Y

Dossier d’analyse & d’architecture Page 5 / 40

1. Références
1.1 Documents
N° Document Auteur(s) Edition
[1] Formation 3A, Masters ISIC & TW3S : Jacques SIMONIN 2010-2011
CESI Architecture Fonctionnelle

[2] Formation 3A, Masters ISIC et TW3S : Jacques SIMONIN 2010-2011

CESI Analyse Fonctionnelle

[3] Dossier d’analyse et d’architecture - Jacques SIMONIN, 2010-2011

CESI UVF23B301 - Illustration de cours Philippe TANGUY

[4] Vue fonctionnelle cible - Projet CESIP - Jacques SIMONIN 2010-2011

UVF23B301

Tableau 1.1 : Documents de référence

1.2 Glossaire
Libellé Définition
Conférence
Revue
Tableau 1.2 : Glossaire

1.3 Liste des Abréviations

DF Donnée fonctionnelle
F Fournir
IF Îlot Fonctionnel
Imp Application Imprimerie
U Utiliser

Dossier d’analyse & d’architecture Page 6 / 40

 Analyse
Fonctionnelle
2.1 Contexte
2.2 Rôles
2.3 Cas d’utilisation

Dossier d’analyse & d’architecture Page 7 / 40

2 Analyse fonctionnelle
Ce chapitre présente l’analyse des exigences fonctionnelles du système :

* le contexte du système
* les rôles interagissant avec le système
* les cas d’utilisation du système et les scénarios qui les illustrent
* le modèle d’entités associé aux cas d’utilisation

L’analyse fonctionnelle proposée ici complète une description d’acteurs de la soumission d’un
article et un modèle UML de données représentés dans [1].

2.1 Contexte

Figure 2.1 : Contexte

2.2 Rôles
Nom du rôle Description du rôle
Demandeur Demande d’impression d’un document
Responsable de l’activité Valide/ ne valide pas la demande d’impression
Chef de département Valide/ ne valide pas la demande d’impression
Imprimeur Imprime le document
Livreur Livre le document Imprimé
Tableau 2.1 : Rôles

Dossier d’analyse & d’architecture Page 8 / 40

Figure 2.2 : Diagramme de rôles

Dossier d’analyse & d’architecture Page 9 / 40

2.3 Cas d’utilisation

Figure 2.3 : Diagramme de cas d’utilisation

Dossier d’analyse & d’architecture Page 10 / 40

2.3.1 Cas d’utilisation UcDemandeImpression
Résumé
Ce use case permet de soumettre une demande d’impression d’un document

Contexte de déclenchement
Le use case est exécuté à la demande du Demandeur de l’impression du document

Rôle
Le demandeur.

Pré-condition
Le document doit avoir un titre.
Le demandeur doit avoir un nom.
Le demandeur doit être rattaché à une activité (enseignement / recherche contractuelle, r
echerche non contractuelle, etc.)

Description
A la demande du demandeur, le système présente d‘abord la possibilité de choisir le document
à imprimer.
Le système copie le document soumis (sur un disque appartenant au département d’impres-
sion)
Le système enregistre la date de dépôt de cette demande d’impression.
Le système met l’état du document à “demandée”

Le système demande la validation d’impression de ce document au chef de département ou res-

ponsable de l’activité de demandeur d’impression.

Post-Condition
Le document soumis à la demande doit avoir une date de soumission.
L’état d’impression de ce document doit être “demandée”.

Exception
Aucune exception.

Scénario
1. scénarios nominale de demande d’impression:

UcDemandeImpression
1. Identification du demandeur
2. Demande d’impression du document
3. Choix du document à imprimer par le demandeur
4. Copie du document sur un disque dur du département imprimerie
5. Enregistrement de la date de dépôt du document, avec le titre du document, le nom du de-
mandeur, et son département d’activité
6. Enregistrement de l’état d’impression du document à “demandée”
7. Envoie d’une demande de validation d’impression de ce document au chef de département /
responsable de l’activité du demandeur de l’impression.
2.3.2 Cas d’utilisation UcValidationImpression
Résumé
Ce use case permet de valider la demande d’impression du document .

Contexte de déclenchement
Ce use case est exécuté lorsqu’un document doit être validé avant impression.

Rôle
Le valideur (Chef de département ou responsable d’activité) autorise ou n’autorise pas
l’impression du document

Pré-condition
Le document doit être soumis par son demandeur.
Le demandeur doit avoir au moins un validateur associé.

Description
Le valideur consulte la liste des demandes d’impression de documents.
Le valideur autorise, ou n’autorise pas l’impression de chaque document soumis par les demandeurs.
Le système change l’état d’un document validé en le passant de “demandée” à “validée”.
Le système soumet l’impression de chaque document validé à l’imprimeur.

Post-Condition
Le document soumis à la demande doit avoir une date de validation.
L’état d’impression de ce document doit être “validée”.

Exception
Non validation de la demande d’impression

Scénario
1. scénarios nominale de validation d’impression:
UcValidationImpression
1. Identification du valideur
2. Choix du document à imprimer dans la liste des demandes
3. Validation de la demande pour le document choisi pour impression
4. Enregistrement de la date de validation de l’impression du document et le nom du valideur
5. modification de l’état d’impression du document à “validée”
6. Envoie d’une demande d’impression de ce document à l’imprimerie

2. scénarios d’exception de validation d’impression lorsque la valideur ne valide pas la demande

d’impression :
UcExceptionValidationImpression
1. Identification du valideur
2. Choix du document à imprimer dans la liste des demandes
3. Non validation de la demande pour le document choisi pour impression
4. Suppression du document sur le disque dur de l’imprimerie
5. Enregistrement de la date de non validation de l’impression du document et le nom du vali-
deur
6. modification de l’état d’impression du document à “non validée”
2.3.3 Cas d’utilisation UcImpression

Résumé
Ce use case permet de valider la demande d’impression du document .

Contexte de déclenchement
Ce use case est exécuté lorsqu’un document est validé par un validateur pour impression.

Rôle
L’imprimeur imprime le document

Pré-condition
Le document doit être validée pour impression par un valideur (état “validée”).

Description
L’imprimeur consulte la liste des demandes d’impression de documents validés.
L’imprimeur imprime les documents par ordre de date de validation.
Le système change l’état d’un document validé en le passant de “validée” à “réalisée”.
Le système soumet la livraison de chaque document imprimé au livreur.

Post-Condition
Le document soumis à la demande doit avoir une date de validation.
L’état d’impression de ce document doit être “validée”.

Exception
Il ne peut pas y avoir deux réalisation de document simultanées (processus critique)

Scénario
1. scénarios nominale d’impression:
UcImpression
1. Identification de l’imprimeur
2. Impression du premier document dans la liste de validation (trie par date)
3. Enregistrement de la date de réalisation de l’impression du document et le nom de l’impri-
meur
4. modification de l’état d’impression du document à “réalisée”
5. Envoie d’une demande de livraison de ce document au livreur

2. scénarios d’exception d’impression lorsque une impression arrive pendant la réalisation d’une
autre impression
UcExceptionValidationImpression
1. Identification du valideur
2. mise dans la file d’attente

Dossier d’analyse & d’architecture Page 13 / 40

2.3.3 Cas d’utilisation UcLivraison

Résumé
Ce use case permet de livrer le document réalisé(imprimé) .

Contexte de déclenchement
Ce use case est exécuté lorsqu’un document doit être réalisé et livré.

Rôle
Le livreur livre le document au demandeur.

Pré-condition
L’état du document doit être réalisé par l’imprimeur (état “réalisée”).

Description
Le livreur consulte la liste des documents réalisés et à livrer
Le livreur livre le document au demandeur de l’impression
Le système change l’état d’un document de “réalisée” à “livrée”

Post-Condition
Le document soumis à la livraison doit avoir une date de livraison.
L’état d’impression de ce document doit être “livrée”.

Exception
La non présence du demandeur de l’impression lors de la livraison

Scénario
1. scénarios nominale d’impression:
UcLivraison
1. Identification du livreur
2. Choix du document à livrer dans la liste des demande d’impression de documents à l’état
“réalisée”
3. livraison par ordre logique de trajet, remise en main propre
4. Enregistrement de la date de livraison du document et le nom du livreur
5. modification de l’état d’impression du document à “livrée”

2. scénarios d’exception de livraison lorsque le demandeur n’est pas présent pour la réception de
la livraison de son document réalisé.
UcExceptionLivreur
1. Identification du livreur
2. Choix du document à livrer dans la liste des demande d’impression de documents à l’état
“réalisée”
3. livraison par ordre logique de trajet, dépôt dans boite de réception du demandeur
4. Enregistrement de la date de livraison du document et le nom du livreur
5. modification de l’état d’impression du document à “livrée”

Dossier d’analyse & d’architecture Page 14 / 40

2.4 Entités participantes aux cas d’utilisation

Nom de l’entité Description de l’entité

Demandeur Personne qui saisie une demande
d’impression d’un document
Responsable de l’activité Personne qui valide ou ne valide pas la
demande d’impression du document (chef de
département ou responsable de l’activité)
Chef de département Personne qui valide ou ne valide pas la
demande d’impression du document (chef de
département ou responsable de l’activité)
Imprimeur Personne qui réalise l’impression du
document validé
Livreur Personne qui livre le document réalisé au
demandeur de l’impression du document
Document Fichier à imprimer
Département impression Lieu où sont réalisé les impression
Tableau 2.4 : Définition des entités avec leur nom

Dossier d’analyse & d’architecture Page 15 / 40

Figure 2.4 : Diagramme des entités participantes aux cas d’utiilisation

Dossier d’analyse & d’architecture Page 16 / 40

 Architecture
Fonctionnelle
3.1 îlots fonctionnels
3.2 Dépendance des îlots
fonctionnel
3.3 Données fonctionnelles

Dossier d’analyse & d’architecture Page 17 / 40

3.1 Îlots fonctionnels

Tableau 3.1 - 1 : Entité participante // Atribut // Ilot fonctionnel

Tableau 3.1 - 2 : Relation entre entités participantes // Entités reliées // Ilot fonctionnel

Dossier d’analyse & d’architecture Page 18 / 40

3.2 Dépendance des îlots fonctionnels
La dépendance des îlots fonctionnels répertoriés précédemment est conçue à partir des scéna-
rios spécifiés en analyse fonctionnelle. C’est une approche dynamique de l’architecture fonc-
tionnelle. La traçabilité des scénarios dans les diagrammes de séquences fonctionnelles est
reporté dans le Tableau suivant.

Scéanario Diagramme de séquence fonctionnelles

ScDemandeImpression
ScDemendeValidation
ScImpression
ScLivraison
ScAnnulationImpression
ScAnnulationImpressionAvecLivraison
Tableau 3.2 - 1 : Scénario // Diagramme de séquence fonctionnelles

Figure 3.2 - 1 : Diagramme de séquence fonctionnel // Demande d’impression

Dossier d’analyse & d’architecture Page 19 / 40

Figure 3.2 - 2 : Diagramme de séquence fonctionnel // Demande de Validation

Figure 3.2 - 3 : Diagramme de séquence fonctionnel // Impression

Dossier d’analyse & d’architecture Page 20 / 40

Figure 3.2 - 4 : Diagramme de séquence fonctionnel // Livraison

Figure 3.2 - 5 : Diagramme de séquence fonctionnel // Annulation d’impression

Dossier d’analyse & d’architecture Page 21 / 40

Figure 3.2 - 5 : Diagramme de séquence fonctionnel // Annulation d’impression avec Livraison

Figure 3.2 - 6 : Modèle des ilots fonctionnels

Dossier d’analyse & d’architecture Page 22 / 40

3.3 Données fonctionnelles
Le modèle des données fonctionnelles est repésente par un diagramme de classe UML stéréo-
typées <<donnée fonctionnelle>> dans la Figure 12.
Chaque données et chaque dépendance entre données sont cohérentes avec le modèle des îlots
fonctionnels.

Figure 3.3 : Modèle des données fonctionnelles

Le Tableau 4-4 représente le lien entre les îlots fonctionnels et données fonctionnelle.
un îlot fonctionnel peut fournir un données fonctionnelle ou utiliser une donnée fonctionnelle.
La règle d’urbanisme étant qu’une donnée fonctionnelle ne peut être fournie que par un seul îlot
fonctionnel.

donnée DF Agent DF Autorité DF Document DF Suivi

fonctionnelle Impression

îlot fonctionnel
IF gestion Agent F
IF gestion Autorité U F
IF gestion Document F
IF gestion Suivi U U U F
Impression

Tableau 3.3 - 1 : Données fonctionnelles // Ilots fonctionnelles

Dossier d’analyse & d’architecture Page 23 / 40

La traçabilité des entités participantes aux cas d’utilisation est représentes dans le Tableau 4-5

Tableau 3.3 - 2 : Entités participantes // Attributs // Donnée fonctionnelles

Dossier d’analyse & d’architecture Page 24 / 40

 Analyse
Technique
4.1 Prototypage
4.2 Guide de mise en oeuvre

Dossier d’analyse & d’architecture Page 25 / 40

Les trois techniques critiques sont l’utilisation des framework Hibernate et Spring et la tenue
en charge de l’application Imp.

4.1 Prototypage
Le prototypage fait sur l’application Imp permet de vérifier sa tenue en charge pour l’application
de soumission d’impression de documents. Bilan de ce prototypage:
Afin de chiffre l’utilisation de l’application, pour chaque Demande d’Impression il y a d’après
les cas d’utilisation (cf. §3.3):

* un accès pour la consultation des validateurs potentiels (chef de département et respon

sable d’activité).
* un accès pour la validation.
* un accès pour l’impression.
* un accès pour la livraison.
* un accès potentiel pour l’annulation ou l’arrêt de l’impression.

Pour n soumission d’articles par unité de temps, il y a donc 2n lectures d’agent de l’institu-
tion de rattachement après recherche dans la base de l’application Imp, et jusqu’a 4 accès de
consultation et de mise à jour de la base, plus un potentiel.

4.2 Guide de mise en oeuvre

4.3.1 Framework Hibernate

Cf. TW3S_1_Mapping_objet_relationnel.pptx de Philippe PICOUET et Philippe TANGUY.

4.3.2 Framework Spring

Cf. TW3S_2_injection_dépendances_Spring.pptx de Philippe PICOUET, Laurent BRIS

SON et Philippe TANGUY.

Dossier d’analyse & d’architecture Page 26 / 40

 Architecture
Technique
5.1 Noeud d’execution et lien
de communication
5.2 Architecture en couches

Dossier d’analyse & d’architecture Page 27 / 40

L’architecture technique est reprise de [3] en intégrant un système externe supportant l’applica-
tion Imp.

5.1 Noeud d’exécution et lien de communication

Le modèle des noeuds d’exécution représenté dans la Figure X par les noeuds d’exécution et
les liens de communication entre ces noeuds. Les noeuds matériels associés à chaque noeud
d’exécution et les environnement d’exécution associés à chaque noeud d’exécution ou lien de
communication sont répertoriés respectivement dans le tableau 6-2.

Le “serveur Imp” n’est pas détaillé ici techniquement puisque réutilisé. Il devrait donc être
décrit dans un autre dossier d’analyse et d’architecture.

TCP / IP
Serveur SA Serveur Imp

Figure 5.1 : Modèle de noeuds d’exécution

Noeud d’exécution Noeud matériel Commentaire

Serveur SA PC
Serveur Imp PC
Tableau 5.1 - 1 : Noeud d’exécution // Noeud matériel // Commentaires

Noeud d’exécution / Lien de Environnement d’exécution Commentaire

communication
Serveur SA Windows Système d’exploitation
Serveur SA J2EE Spécification JAVA
Serveur SA Java Langage de POO
Serveur SA JDBC API J2EE de connexion à une
Base de données
Serveur SA HTML Langage de balisage permet-
tant de générer dynamique-
ment des pages WEB
Serveur SA JSP Techno JAVA permettant de
générer des page HTML
Serveur SA SQL Pseudo-langage orienté BD
TCP / IP Java RMI API de communication dis-
tante entre objet Java
Tableau 5.1 - 2 : Noeud d’exécution // Environnement d’execution // Commentaires

Dossier d’analyse & d’architecture Page 28 / 40

5.2 Architecture en couches

Composant

Hibernate
JSP/HTML métier
SGBD

Figure 5.2 - 1 : Modèle d’architecture en couches

SGBD
JSP/HTML Composant

Hibernate
métier

Figure 5.2 - 2 : Middlewares & couches

Couche / Middleware Mécanisme générique Commentaire

Couche Web Test Framework de présentation
développé à TELECOM Bre-
tagne
Couche données Framework Hibernate Framework de mapping objet
/ relationnel. Il permet d’être
indépendant vis-à-vis du
SGBD, ici du langage SQL. Le
code SQL est généré lors de
l’exécution du framework.
Middleware Framework Spring Permet de structurer, d’amé-
liorer et de simplifier l’écriture
d’applications Java (J2EE).
Elle permet dans notre cas
d’injecter des dépendances
entre composants de chaque
couche.
Tableau 5.1 : Couche.Middleware // Mécanisme générique // Commentaire

Dossier d’analyse & d’architecture Page 29 / 40

 Architecture
Applicative
6.1 Composants applicatifs
6.2 Dépendance des
composants applicatifs

Dossier d’analyse & d’architecture Page 30 / 40

6.1 Composant applicatifs

Îlot fonctionel Parcelle fonctionnelle Composant applicatif

getAgent()
validation ()
IF GestionAgent
envoyerDocument()
CA Application RH
livreDocument

IF Gestion Autorité lireAutorié()

IF Document
IF Gestion_Suivi_Impression
demanderDocument()
demanderImpression()
demanderAnnulation Impression() CA Impression Document
demanderLivraison()
demandeArretImpressionMsLivraison()

Tableau 6.1 - 1 : Ilot fonctionnel // Parcelle fonctionnelle // Composant applicatif

Composant applicatif Nœud d’exécution

CA Impression Document Serveur SA

CA Application RH Serveur RH

Tableau 6.1 - 2 : Composant applicatif // Noeud d’execution

Dossier d’analyse & d’architecture Page 31 / 40

 Composant applicatif / Application Couche / Middleware Composant applicatif / Couche
CA IHM
IHM

CA Gestion Doc
CA Gestion_Suivi_Impression
CA Livraison
CA Impression Document
CA Validation
Service
CA Impression
CA Annulation

CA InterrompreRealisation
Données CA Gestion dépendance
CA Gestion Agent
CA Application RH Service
CA Gestion Autorité

Tableau 6.1 - 3 : Composant applicatif. Application // Couche.Middleware // Composant applicatif.

couche

5.2 Dépendance des composants applicatifs

Tableau 6.2 - 1 : Scénario demande d’impression ScDemandeImpression

Tableau 6.2 - 2 : Scénario demande validation ScDemandeValidation

Tableau 6.2 - 3 : Scénario Impression ScImpression

Tableau 6.2 - 4 : Scénario Livraison ScLivraison

Tableau 6.2 - 5 : Scénario annulation d’impression ScAnnulationImpression

Tableau 6.2 - 6 : Scénario Interrompre l’impression ScInterrompreImpression

Dossier d’analyse & d’architecture Page 32 / 40

Tableau 6.2 - 1 : Scénario demande d’impression

Tableau 6.2 - 2 : Scénario demande validation

Dossier d’analyse & d’architecture Page 33 / 40

Tableau 6.2 - 3 : Scénario Impression

Tableau 6.2 - 4 : Scénario Livraison

Dossier d’analyse & d’architecture Page 34 / 40

Tableau 6.2 - 5 : Scénario annulation d’impression

Tableau 6.2 - 6 : Scénario Interrompre l’impression

Dossier d’analyse & d’architecture Page 35 / 40

5.2 Modèle des composants applicatifs

5.2 Modèle de données applicatives

Dossier d’analyse & d’architecture Page 36 / 40

5.2 Tableau données applicatives / Composants
applicatifs

Donnée applicative DA DA DA DA DA
Ecran- EcranAu- EcranIm- EcranLi- AgentSer-
Deman- torisation pression vraison vice
deAutorisa-
Composant applicatif tion
CA Demande Autorisation F
Impression
CA Validation Impression U F
CA Impression F
CA Livraison F
CA Arrêt Impression U F
CA Annulation U U
CA GesionAgent

Dossier d’analyse & d’architecture Page 37 / 40

 Conclusion

Dossier d’analyse & d’architecture Page 38 / 40