Ensimag — 2.5D Cartoon Model Document d`analyse et

Transcription

Ensimag — 2.5D Cartoon Model Document d`analyse et
Ensimag — 2.5D Cartoon Model
Document d’analyse et conception
Léo A LLEMAND -G IORGIS
Élisabeth R OUSSET
juin 2011
1
Amaury J UNG
Pierre TAKLA
2
TABLE DES FIGURES
Table des matières
1
Introduction
3
2
Analyse de fonctionnalités
3
3
Modélisation du domaine
3
4
Architecture logique
4
5
Conception détaillée
5.1 Langage utilisé . . . . .
5.2 Organisation des fichiers
5.2.1 Docs . . . . . . .
5.2.2 Src . . . . . . . .
5.3 Extensions . . . . . . . .
5
5
6
6
6
7
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusion
8
Table des figures
1
2
3
Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modélisation objet du domaine . . . . . . . . . . . . . . . . . . . .
Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . .
4
5
6
3
1
Introduction
Ce document indique les étapes de conception du logiciel 2.5D Cartoon Designer. Dans un premier temps, nous décrirons les fonctionnalités du logiciel
ainsi que son architecture générale. Dans un second temps, nous présenterons
de manière plus détaillée la conception de ce dernier.
2
Analyse de fonctionnalités
Le diagramme de cas d’utilisations du logiciel est présenté à la figure 1. Ce
document a été rédigé au tout début du projet. Il a donc été amené à évoluer.
Actuellement, on peut ajouter à ce diagramme les fonctionnalités suivantes :
– enregistrer / charger / créer un nouveau fichier
– afficher le rendu en 3D
3
Modélisation du domaine
Dans cette partie nous allons modéliser le domaine de l’application. On peut
le décrire de la manière suivante :
– La scene est constituée d’un ensemble de strokes. Cet ensemble peut être
vide, ce qui correspondra à un dessin vide.
– Un stroke représente un élément unitaire du dessin. Par exemple, il peut
s’agir d’un œil, d’un sourire, d’un nez, etc. Cependant, selon le niveau
de détail souhaité, un œil peut par exemple être décomposé en plusieurs
strokes. Un stroke contient un point d’ancrage anchorpoint. Un stroke peut
être simple (simplestroke) ou composé (multistroke).
– Un anchorPoint est un triplet de coordonnées 3D. Il sert à déterminer la
position 3D du stroke associé.
– Un multistroke est un groupement de simplestroke. Il permet de grouper
plusieurs simpleStroke sur un même point d’ancrage.
– Un simpleStroke contient un ensemble de shapes. Chaque shape correspond
à une vue clef particulière. Elle correspond à la forme du stroke dans cette
vue.
– Une shape contient un ensemple de points, qui sont les points de contrôle
de la courbe de la shape. Elle contient aussi des informations sur l’épaisseur de trait (line), ainsi que les couleurs (color) de trait et de remplissage
(fill).
– On appelle drawable les éléments line et fill. Un drawable possède une color.
4
4
ARCHITECTURE LOGIQUE
F IGURE 1 – Cas d’utilisation
– Un simplestroke correspond à une représentation plane des images. On
peut le spécialiser en ellipsimplestroke qui correspond à une représentation
ellipsoïde des images.
Cette modélisation est résumée dans la figure 2.
4
Architecture logique
Nous avons décomposé l’architecture de notre logiciel selon un patron modèlevue-contrôleur.
La vue Elle contient une unique classe correspondant à l’interface graphique
du logiciel. Elle s’intitule CartoonGui.
5
F IGURE 2 – Modélisation objet du domaine
Le modèle
3.
Il correspond à la modélisation objet de domaine faite à la section
Le contrôleur Il est constitué d’une unique classe appelée Viewer.
Relations MVC Les intéractions entre les différentes parties du logiciel sont
représentées à la figure 3 :
– L’interface graphique appelle le controleur lorsqu’elle reçoit un signal.
– Le controleur modifie le modèle en conséquence.
5
5.1
Conception détaillée
Langage utilisé
Le logiciel 2.D-CD est codé en C++. Il utilise pour l’interface graphique les
librairies qt4 ainsi que QGLViewer.
6
5
CONCEPTION DÉTAILLÉE
F IGURE 3 – Architecture logique
5.2
Organisation des fichiers
Les documents du projet sont organisées dans le dossier spe/ de la manière
suivante :
– spe/Docs : Ensemble des fichiers de documentation.
– spe/Obj : Ensemble des fichiers .o générés à la compilation.
– spe/Presentation : Slides de présentation du suivi de SHEME et de la
soutenance finale.
– spe/Src : Ensemble des fichiers sources.
– spe/Test : Fichiers .xml de tests importables dans le logiciel.
5.2.1
Docs
Le dossier Docs/ contient :
– un fichier 2.5D Cartoon Model.mm. Il s’agit d’une carte mentale établie en
début de projet.
– des dossiers bilan/, conception/, et manuel/ qui contiennent chacun les
sources LATEX des documentations correspondantes, ainsi que des fichier
.uml contenant les diagrammes UML du projet.
Les fichiers .mm et .uml s’ouvrent respectivement avec les logiciels libres
freemind et argouml.
5.2.2
Src
Le dossier Src/ contient les dossiers suivants :
5.3
Extensions
7
– icons : ensemble des icones de l’application.
– libspline : librairie utilisée pour la gestion des splines.
Le reste des fichiers sources peut être classé en trois catégories, suivant l’architecture de la section 4 :
– vue
– contrôleur
– modèle
Dans la suite on désignera par src le couple de fichiers src.h et src.cpp.
Vue
–
–
–
Il s’agit des fichiers correspondant à l’interface graphique :
cartoongui : interface principale
duplicateviewgui : boîte de dialogue pour la duplication de vues
qtcolorcombobox : boîte de dialogue pour la selection de couleur
Contrôle Il s’agit des fichiers correspondant à la gestion des signaux reçus par
l’interface graphique :
– viewer : contrôleur principal
– undolist : gestion de l’historique de commandes
– nameshandler : gestion de la sélection des objets
– moodselector : selection des humeurs
– externalviewer : point de vue externe de la scène
Modèle Il s’agit des fichiers correspondant aux structures de données utilisées
par notre logiciel. On retrouve notamment les classes du modèle de la section
4:
– scene
– stroke
– multistroke
– simplestroke : représentation plane des strokes
– ellipsimplestroke : représentation ellipsoïde des strokes
– shape
– point
– tools : classe utilitaire
– guide : guide de dessin affiché en fond dans l’interface
5.3
Extensions
Notre architecture permet l’implémentation du groupement de stroke. On entend par là la possibilité pour l’utilisateur d’associer un unique point d’ancrage
à un ensemble de strokes. Cette implémentation est prévue dans l’architecture
8
6
CONCLUSION
par la classe MultiStroke, mais n’est actuellement pas utilisée. Il faudrait améliorer l’interface graphique en conséquence, ainsi que les méthodes de sélection
et de déplacement de points et de strokes.
6
Conclusion
La conception de notre logiciel est réfléchie : nous avons souhaité coder un
logiciel extensible et facilement maintenable. Les différentes parties du code
suivent toutes la même charte stylistique, afin d’obtenir une bonne lisibilité
(mis à part les librairies dont nous nous servons). Nous avons utilisé le logiciel astyle pour formatter notre code.